Jump to: navigation, search

Keystone edge architectures

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:

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.

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.

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