2. OpenStack Identity
State of the Project: Keystone
Joe Heck
Project Technical Lead
Tuesday, October 16, 12
3. me...
Joe Heck
choose to live @heckj
here
grew up here
Tuesday, October 16, 12
4. Outline
‣ Why keystone
‣ What is keystone
‣ Basic concepts
‣ High level architecture
‣ Keystone history review
‣ Grizzly plans
Tuesday, October 16, 12
5. Why Keystone
‣ the first “openstack common”
‣ common internal API expressing relevant identity
information to OpenStack projects
‣ need for knowledge of OpenStack service
endpoints
Tuesday, October 16, 12
6. What is Keystone
‣ single source of authentication, authorization
‣ same account and credentials for starting a VM instance
and accessing a container in object storage
‣ enforcement of authorization policies at the service level,
not centralized
‣ means of expressing API endpoints
‣ basic service catalog
Tuesday, October 16, 12
7. What is Keystone - core internal services
‣ identity
‣ policy
‣ token
‣ catalog
Tuesday, October 16, 12
8. Basic Concepts - Identity
‣ Tenant == Project
‣ basic unit of ownership
‣ collection of resources (vm, volume, container, etc)
‣ User
‣ individual or service
‣ identified by basic credentials
‣ Role
‣ name relationship between a user and tenant
Tuesday, October 16, 12
9. Basic Concepts - Policy
‣ Policy file - private/internal in Essex
‣ Nova, Glance, and Keystone
‣ extending to Cinder, Quantum
‣ Simple rule based mechanism for expressing
authorization
‣ Enforcement at the services
Tuesday, October 16, 12
10. Basic Concepts - Token
‣ Token
‣ arbitrary string to be used in HTTP headers
‣ identity associated with token retrievable by other
OpenStack services
‣ token
‣ user, tenant, roles
‣ catalog
Tuesday, October 16, 12
16. Keystone history : Cactus release and earlier
‣ protocols and mechanisms originally disparate in
compute and object storage
‣ called “auth v1”
‣ separate accounts in nova and swift
‣ glance using both, highlighted the issue
Tuesday, October 16, 12
17. Keystone history : Diablo
‣ Aggressively prototyped
‣ OpenStack internal token-based HTTP API
‣ administrative API, separate ports
‣ lots of changes, right up through the release
Tuesday, October 16, 12
18. Keystone history : Essex
‣ Consolidation
‣ re-implemented to simplify and refactor architecture
‣ architecture shift to focus on independent drivers
‣ migrated to administrative CRUD operations
‣ maintained 100% API compatibility
Tuesday, October 16, 12
19. Keystone history : Folsom
‣ PKI and prep for Grizzly+
‣ Enabled PKI based tokens
‣ kept everything rock solid
‣ maintained 100% API compatibility
‣ Resolved bugs, dealt with security issues as they were
uncovered
‣ lessons learned led to a V3 identity API
‣ started implementation on V3 API
Tuesday, October 16, 12
20. Keystone future : Grizzly
‣ Implement V3 API
‣ auth changes effect and impact every project
‣ consolidate code into Oslo (openstack-common)
‣ help drive consolidated policy and roles changes
through all projects
‣ Consolidate policy files
‣ focus on documentation, example configurations
Tuesday, October 16, 12
21. Keystone future : Grizzly
‣ Extend the authorization mechanisms
‣ support delegation/impersonation
‣ ActiveDirectory support
‣ externalizing authentication
‣ Moving default token to PKI
‣ CLI and common authentication
Tuesday, October 16, 12
22. Keystone future : Grizzly (learning)
‣ Federation
‣ Discussion of use cases and setup
‣ Learn what’s needed to fully support trust delegation
Tuesday, October 16, 12
23. Joe Heck
@heckj
heckj@mac.com
fini
Tuesday, October 16, 12