[Edge-computing] Keystone Edge Architectures
Greg.Waines at windriver.com
Fri Jun 29 01:29:57 UTC 2018
Thanks for the info below
So seems like from previous discussions there is a little hesitation about “use of fernet issued from one keystone in another”, unless if “replicated/in-sync keystones” are used.
( is that correct interpretation ? ... or is it a total ‘-2’ on fernet tokens from one keystone used in another ? )
Does “replicated/in-sync keystones” refer to keytsones whose DBs are sync’d at the DB-level ?
( e.g. one read/write DB and many read replicas ? )
If yes, .... how does one handle Software Upgrade across a Distributed Cloud in this “replicated keystone” environment,
where the Central Cloud Keystone could have a different DB schema than the Edge Subcloud ?
< 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