[Edge-computing] Keystone Edge Architectures
Greg.Waines at windriver.com
Tue Jul 3 12:01:35 UTC 2018
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 ?
< 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 . 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.
< SNIP >
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Edge-computing