Open Stack

On 07/03/2018 07:01 AM, Waines, Greg wrote:
>
> Hey Lance,
>
> Just following up again on the info below you provided on previous
> discussions on issues with API-based Synchronization of Keystone
> between clouds.
>
>  
>
> In your example below, wouldn’t the API-based Synchronization of the
> user password change @ A (assuming A is the central site), result in
> the user password change @ B “and” the corresponding revocation event
> being created @ B ?  
>

I guess I need alittle more information in order to answer the question.
Do users live in SQL or are they centrally located somewhere else? If
they livein SQL, does that mean you're replicating users manually to
have the same ID, name, and password across every edge deployment?

If so, then you'd beable to manually create revocation events by
changing theuser's password at every edge deployment. So if you have 100
deployments, you'll have to change a user's password in 100 places in
order to get around the issueI described in the previous note.

This leads me to another question. If users are in SQL, are you planning
on relying on any PCI-DSS features[0]? If so, this might be another
attack surface to consider since:

  - an attacker could attempt to brute force a password in deployment A
  - the attacker is locked out due to hitting maximum failed
authentication attempts
  - the attackerattempts to brute force the same account in deployment B
(which doesn't know the same user just tried authenticatingand failed X
times in deployment A)

[0]
https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html

>  
>
> Greg.
>
>  
>
>  
>
>     < SNIP >
>
>
> The concept of replicating data over the API was also brought up
> towards the end of the call as a possible solution. The TL;DR is that
> each deployment would be independent, but data would be kept in sync
> by making API requests that forcibly create entities with the same IDs
> (manual replication if you will). This idea has been discussed at
> length over the last couple years [0]. We most recently discussed it
> during the summit in Sydney.
>
> Where we really tripped was replication of revocation events. For
> example, assume you have the ability in keystone to forcibly create
> things with specific IDs, allowing you to manually replicate data
> across your edge deployments. At the same time you're keeping the
> fernet keys in sync, so a user can actually generate tokens in one
> deployment and use them in other (since each keystone node has the
> same IDs for projects, domains, users, etc..), even though replication
> isn't happening at the database. Revocation events are records used
> internally by keystone to track events that affect token validity
> (e.g. a user changing their password or deleting a specific token),
> and they are not exposed via keystone's API. The concern is that
> without replicating this table, it would be possible for a user to:
>
>  - generate a token in deployment A
>  - use the token in deployment B to do something
>  - change their password in deployment A, which creates a revocation
> event invalidating the token from step one in deployment A
>  - the user attempts to use the token from step one in deployment A
> but it is considered invalid (due to the revocation event)
>  - the user successfully executes API calls with the token from step
> one in deployment B because deployment B has no knowledge of the
> revocation event in deployment A
>
> We didn't get into that much detail in the call, but wanted to share
> where the conversation ended up the last time we had it.
>
> [0] https://review.openstack.org/#/c/323499/
>
>
> *< SNIP >*
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180709/2752f1d8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20180709/2752f1d8/attachment.sig>