[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,

On 2018-07-09, 3:25 PM, "Lance Bragstad" <lbragstad at gmail.com> wrote:
     On 07/03/2018 07:01 AM, Waines, Greg

               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
              < SNIP >
                  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