Cross-Cloud Project Sync
Stakeholder/
Cern - primary
IBM - interested party
Rackspace - interested party
Aerospace - interestred party
RedHat - interested party
Use case:
As a federated user of a foreign cloud when I add a new project in my local cloud- I would like to get that same project definition allocated across other clouds so that my users are speaking the same project-level semantics with proper authorization across clouds at the time of the federation.
Customer perceived priority:
not a blocker but admin headache as we get wide adoption of image federation
Acceptance criteria:
- project hierarchy synchronization performed across trusted clouds (name at least)
- authorization synchronization (roles/permissions) out of scope as that is out-of-band agreement between clouds on how to handle that.
Solution:
Project in foreign cloud provisioned upon user federation within Keystone. Authorization to that project is based on SAML assertion (as is today). The issue then becomes cleanup -
Should the project be deleted:
CADF message on some agreed-to-bus between 2 clouds is sent showing DELETE on project for a specific IdP/Domain.
Foreign keystone listens to that bus and removes project/
Standard termination of resources attached to that project occurs (based on cloud implementation and out of scope for this).
Should the project be updated:
CADF message on some agreed-to-bus between 2 clouds is sent showing UPDATE on the project for a specific IdP/Domain. Update of projectID should not be allowed - really just description, name and enabled/disabled.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Joe Savak
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
- Steve Martinelli
Related branches
Related bugs
Sprints
Whiteboard
(stevemar 2016-07-31): I haven't seen any updates or useful links for this blueprint. Please submit a specification to the keystone-specs repository instead.
+1 overall, rodrigods pointed me to this today when I realized this wasn't the existing behavior for k2k. -Dolph
Project IDs are already immutable, so that shouldn't be a concern.
agreed-to-bus: Unfortunately, this must be done with HTTP polling of some kind to scale globally.
This spec would be much simpler if we made the assertion that the *only* thing shared across clouds is the project ID -- and perhaps the initial values of project name & description. After that, each project is owned by each separate cloud and they just happen to share an ID. No further syncing necessarily needs to take place. -Dolph