Jump to: navigation, search

Difference between revisions of "Keystone edge architectures"

(Identity Provider (IdP) Master with shadow users)
(Identity Provider (IdP) Master with shadow users)
Line 17: Line 17:
== Identity Provider (IdP) Master with shadow users ==
== Identity Provider (IdP) Master with shadow users ==

Revision as of 09:42, 15 October 2018

This page contains a summary of the Vancouver Forum discussions about the topic. Full notes of the discussion are in here. The features and requirements for edge cloud infrastructure are described in OpenStack_Edge_Discussions_Dublin_PTG.

Concerns to be addressed


  • Some data may be modified locally and must persist when changed


  • There may be significant times with no connectivity and all functions (e.g. autoscaling) must continue to function


  • Some data should NOT be synchornized to some sites, if the site is compromised, it should only hold relevant local data
  • Centralized "view" to synch status of edge clouds would be needed for audit / compliance
  • Centralized Management (of some sort) required.


  • Edge sites may be very limited hardware (eg, may be single-node infrastructure)

Architecture options

Identity Provider (IdP) Master with shadow users

Edge Keystone IdP Master.png

Keystone Fed ext IdP 2.png

Several keystone instances with federation and API synchronsation

Every edge cloud instance runs its own keystone instances. These keystone instances are federated where each keystone node is a "service provider" accepting and validating SAML assertions from a trusted identity provider (this is not the same as k2k federation). Each keystone maintains a mapping to control access depending on who needs what (this is going to be a lot of mappings, since there can be multiple for each deployment).
Basic flow:

  1. A user presents a SAML assertion to prove their idenitty
  2. The mapping processes their attributes, creates a shadow user, etc..
  3. From there the user creates an application credential with their shadow user
  4. A user generates tokens with their application credential to do things with that specific keystone deployment

More info


  • Pros
    • Federation is already supported by Keystone
  • Cons
    • Connectivity loss between the client and the IdP or the client and the edge cloud instance leads to authentication problems
    • Lots of mapping rules need to be maintained, but hey can be static


  • Can a Keystone in VIO act as an Identity provider for K2K federation?
  • Do we need further synchronisation of RBAC data on top of what we have in K2K federation?

Keystone database replication with a distributed database

Every edge cloud instance runs its own keystone instances. The database of these instances are syncronised and the data is syncronised between the edge cloud instances by the standard replication mechanism of the database.

Related materials


  • Pros
  • Cons
    • Distributed databases have limitations, for example Galera is able to synch only 16 DB-s

Keystone database replication with a synch service

Every edge cloud instance runs its own Keystone. There is a synchronisation agent on every edge cloud instance which can read and write the Keystone database. The synchronisation agent reads selected data from the database of a master Keystone and synchronises it to the slaves.


  • Pros
  • Cons
    • The synchronisation agent needs to understand the details of the Keystone databases structure
    • Writing the data and keeping consistency might not be trivial

Distributed LDAP database as Keystone backend

Keystones in the edge cloud instances are using an LDAP database as a backend and the LDAP is configured to synchronize the data. </br> LDAP can be set up only as the auth realm and keystone RDB will provide identity service database. But Keystone can also handle both authentication and identity service which would imply there is no keystone relational database needed in this scenario.

Related materials


  • Pros
  • Cons


  • Is it possible to store and synchronize all Keystone related data in this way?

Isolated Domains Per Edge and Localized Authority to Change data within isolated domain(s)

  • "Spoke/Hub Model"-ish
  • "Local DB for local "data" and pending writes
  • Local data is send up to central hub once connectivity is restored
  • Sites are authoritative for it's domain(s) no other "remote" domains are aurhoritative
  • Central Hub is authoritative to write to any domain
  • "Code/Service" written to handle bundling local changes and ship to central for distribution/synchonization down when/if connictivity is restored
    • This must be allowed to do things that normal Keystone-API work cannot do (create project in the database with a specific UUID)


  • Pros
  • Cons

Keystone API Synchronization & Fernet Key Synchronization

  • Every Edge Cloud instance runs its own keystone instance,
  • Keystone resources are replicated from central site to edge clouds using API-based Synchronization,
    • i.e. projects, users, groups, domains, ...
  • Also supporting Fernet Key synchronization and management across Edge Clouds in order to enable Tokens created at any Edge / Central cloud being able to be used (and authenticated) in any other clouds.
    • Fernet Tokens contain userId and projectId, so these MUST be synchronized across all clouds,
    • Previous attempts to get this upstreamed in Keystone have failed ==> which likely RULES THIS OPTION OUT.


  • Pros
  • Cons

Replicated data

This is the list of data what is syncronised by StarlingX

  • Keystone
    • Users
    • Projects
    • Roles
    • Assignments
    • Groups (not yet implemented)
    • Domains (not yet implemented)
    • Fernet keys (not yet implemented)
  • Nova
    • Flavors
    • Flavor extra specs
    • Keypairs
    • Quotas (should be managed dynamically in edge cloud infrastructure level I.e. a project that has a quota of 10 instances, can only create 10 instances across ALL Edge Clouds; NOT 10 instances per Edge Cloud.)
  • Neutron
    • Security Groups
    • Security Group Rules
  • Cinder
    • Quotas