Open Stack

On Fri, Feb 24, 2017 at 9:09 PM, joehuang <joehuang at huawei.com> wrote:

> Hello, Matt,
>
> Thank you for your reply, just as what you mentioned, for the slow changed
> data, aync. replication should work. My concerns is that the impact of
> replication delay, for example (though it's quite low chance to happen):
>
> 1) Add new user/group/role in RegionOne, before the new user/group/role
> are replicated to RegionTwo, the new user begin to access RegionTwo
> service, then because the data has not arrived yet, the user's request to
> RegionTwo may be rejected for the token vaildation failed in local
> KeyStone.
>
> 2)In token revoke case. If we remove the user'role in RegionOne, the token
> in RegionOne will be invalid immediately, but before the remove operation
> replicated to the RegionTwo, the user can still use the token to access the
> services in RegionTwo. Although it may last in very short interval.
>
> Is there someone can evaluate the security risk is affordable or not.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
>

We actually had this happen for services like neutron even within a region,
where a network was created on one node and then immediately used on a
second node. We solved it by forcing haproxy to do transactions on one node
(with the others as backups). I only mention this because the scenario you
propose is possible to occur. If you are not dealing with a bunch of data
you could look into enabling causal reads (assuming you are using mysql
galera), but this will probably cause a perf hit (I did not test the
impact).

For scenario 2: I suppose you need to ask yourself, if I remove a user or
role, can I live with 2-5 seconds for that token to be revoked in all
regions? In our case it was not a major concern, but I worked on private
cloud.

For scenario 1: If I were you I think you should figure out whether or not
it's ever likely to really happen before you invest a bunch of time into
solving it. That will depend a lot on your sync time. We only had 2 regions
and we owned the pipes so it was not a major concern.

Sorry I don't have more definite answers for you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170224/573e0ece/attachment.html>