Jump to: navigation, search

Difference between revisions of "Keystone edge architectures"

(Related materials)
(Related materials)
Line 39: Line 39:
 
* StarlingX DRAFT Design Doc for Distributed DB-Sync'd Keystone Edge Architecture - DRAFT - open to any comments
 
* StarlingX DRAFT Design Doc for Distributed DB-Sync'd Keystone Edge Architecture - DRAFT - open to any comments
 
** https://www.dropbox.com/s/653tjwnyvl3q544/dc_keystone_fernet_key_sync_and_db_sync_Jul24_2018.pptx?dl=0
 
** https://www.dropbox.com/s/653tjwnyvl3q544/dc_keystone_fernet_key_sync_and_db_sync_Jul24_2018.pptx?dl=0
 +
* Galera/cockRoach DB evaluation (performed within the FEMDC SiG)
 +
** http://beyondtheclouds.github.io/blog/openstack/cockroachdb/2018/06/04/evaluation-of-openstack-multi-region-keystone-deployments.html
  
 
== Distributed LDAP database as Keystone backend ==
 
== Distributed LDAP database as Keystone backend ==

Revision as of 14:23, 28 August 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

Usability

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

Functionality

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

Security

  • 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.

Scalability

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

Architecture options

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

Questions

  • 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

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

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

Questions

  • 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)

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.
  • ( NOTE THIS OPTION IS ONLY POSSIBLE IF KEYSTONE API CAN BE CHANGED TO SYNCH USERID AND PROJECT ID )
    • 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.

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