Keystone at Openstack discussed multi-site deployment models for Openstack and the problems with using a shared Keystone database across sites. It introduced Keystone to Keystone (K2K) as a solution that allows federated authentication between Keystone instances. K2K enables each Keystone to act independently while still providing cross-cloud authentication. The presentation covered K2K's authentication flow, configuration, and benefits like independent upgrades and high availability of local users even if the Identity Provider is unavailable. Future work may include high availability and disaster recovery support for the Keystone Identity Provider site.

1. Keystone at Openstack
Multi Sites
Sa Pham @ VCCloud

2. Who I am?
Sa Pham Dang /
sapd@vccloud.vn
- System Engineer at VCCLoud /
VCCorp
Organizer

3. Agenda
1. Multi Regions/Sites typical deployment models.
2. Problem with Shared Keystone.
3. How does K2K solve these problem ?
4. Authentication flow with K2K.
5. Demo
6. Future works

4. 1. Multi Regions/Sites deployment models
Some concepts needed to know:
- Availability Zone
- Cells
- Region
- Site

5. - Shared Keystone
- Federated Keystone
1. Multi Regions/Sites deployment models

6. How about Multi Cells ?

7. How about Multi Cells ?
Idea:
- One Cell each Region
Problem:
- Only nova has cell. neutron does not
- When Controller node down ?

8. Shared Keystone
-

9. 2. Problem with shared Keystone
Keystone Deployment
- Centralized: a single Keystone service installed
in some locations, either in “master” region or
totally external as a service to Openstack region
- Distributed: a Keystone service is deployed in
each region.

10. When deploy Keystone distributed We have to concern
about database deployments
Database replicates:
- Master/Slave Synchronous
- Multi master Synchronous
Database server sharing:
- All database in one site replicated
- Only Keystone database can replicated to other site.
2. Problem with shared Keystone

11. Keystone Token Type:
- Fernet: distributed, key rotation
- UUID: large Database
- PKI/ PKIZ: Not good for many sites
2. Problem with shared Keystone

12. Upgrade??
One site upgrade, other sites have to.

13. Federated Keystone
- Federation is a powerful technology that essentially
allows one cloud to trust the users of another.
- Keystone works as Identity Provider and Service
Provider is known as Keystone to Keystone
- Identity Provider: a system entity that creates,
maintains and manages ID information
- Service Provider: is an entity that provides services

14. 3. How K2K solve these problem?
K2K enables the ability to federate identities between
Keystone instances, with Keystone acting on behalf of
the user to deliver cross-cloud authorized and
homogeneous cross-cloud service list

15. - Keystone to Keystone is shared nothing, so we can
have more sites than other model.
- K2K use concept Identity Provider and Service Provider
- Upgrade one site does not effect other sites.
- If Keystone Identity Provider not active , local users still
can interactive with their resources
3. How K2K solve these problem?

16. - Do not concern about sync fernet key between
regions/sites
- Number of Endpoint in Keystone database not large
- Deploy new sites easier
- Does not concern about Database Synchronous
between sites/ regions
3. How K2K solve these problem?

17. Issues with K2k ?
- Currently K2K does not support
HA

18. K2K Deploy model
- One Keystone work as Identity
Provider and Service Provider
- Many Keystone work as
Service Provider

19. K2K Configure
- Identity Provider:
- Config saml section with cert, key and
metadata file
- Add Service Provider

20. - Service Provider
- Enable “mapped” authentication method
- Install apache Shibboleth plugin and config mapping
- Add Identity Provider
- Add Mapping for Identity Provider
K2K Configure

21. 4. Authentication Flow with K2K

22. 4. Authentication Flow with K2K

23. Step 1: Authen with Identity Provider to get all Service
Provider
4. Authentication Flow with K2K

24. Step 2: Request SAML2 Assertion from Identity Provider
4. Authentication Flow with K2K

25. Step 3: Send Assertion to Service Provider URL
➔ curl -X POST -d "@assertion.xml" -c cookie.txt -H "Content-Type: application/vnd.paos+xml"
http://10.5.8.194:5000/Shibboleth.sso/SAML2/ECP
4. Authentication Flow with K2K

26. Step 4: Request unscoped Token from Service Provider
use SP Auth URL
➔ curl -s -X GET -H "Content-Type: application/vnd.paos+xml" -b cookie.txt http://10.5.8.194:5000/v3/OS-FEDERATION/identity_providers/keystone_sapd/pr
otocols/mapped/auth
4. Authentication Flow with K2K

27. Step 5: Get Domains and Projects
➔ curl -X GET -H "X-Auth-Token: $TOKEN" http://10.5.8.194:5000/v3/OS-FEDERATION/projects
4. Authentication Flow with K2K

28. Step 6: Change from unscoped to scoped token
4. Authentication Flow with K2K

29. - One Identity Provider per Domain
- Auto create Projects and Users on this domain
4. Authentication Flow with K2K

30. Bonus: Horizon Support K2K

31. 5. Demo

32. 6. Future Works
- High Available for Keystone Identity Provider Site
- DR for Keystone Identity Provider

33. Discuss Time

34. Thank you