[Edge-computing] Keystone Edge Architectures
Waines, Greg
Greg.Waines at windriver.com
Tue Jul 10 10:59:44 UTC 2018
For the API-based Synchronization approach,
- the users could live locally in SQL, and
- the idea would be to have a centralized API Synchronization Framework that would automatically synchronize User’s UUID, name and password across all edge deployments. ( ... provided that UUID could be specified on the POST of the USER ...)
o ... which would indirectly result in revocation events being generated on the edge clouds
But agree that your comment on PCI-DSS features, is yet another example of side-affect changes in the keystone DB ... which, in this case, would not get indirectly replicated thru an API-based Synchronization Framework.
Thanks for your input,
Greg.
On 2018-07-09, 3:25 PM, "Lance Bragstad" <lbragstad at gmail.com> wrote:
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 a little more information in order to answer the question. Do users live in SQL or are they centrally located somewhere
else? If they live in 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 be able to manually create revocation events by changing the user'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 issue I 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 attacker attempts to brute force the same account in deployment B (which doesn't know the same user just tried authenticating
and 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 >
More information about the Edge-computing
mailing list