Before We Get Started: Enjoy OpenStack’s Amazing Growth!

1. OpenStack Keystone:Overview and Future DirectionsBrad Topol, Ph.D.IBM Distinguished Engineer, OpenStackSWG Standards & Open SourceOpenStack ATC

2. Before We Get Started: Enjoy OpenStack’s Amazing Growth! COMPANIES Exponential growth in 1+ YR 269 APR 2012 Dec 2013 Members: 24 TotalSponsors: 47 Total Supporters: 189 Total 2013 OCT 17 Release: Havana 1,729,137 lines of code 2013 OCT 17 Release: Havana 1,729,137 lines of code 1410 Contributors 13,800+ Individuals 150 Contributors 2600 Individuals Platinum Sponsors 2013 APR 4 Release: Grizzly 1,323,479 lines of code 2013 APR 4 Release: Grizzly 1,323,479 lines of code 2012 SEP 27 Release: Folsom 667,895 lines of code 2012 SEP 27 Release: Folsom 667,895 lines of code 2012 APR 5 Release: Essex 558,368 lines of code 2012 APR 5 Release: Essex 558,368 lines of code 2011 APR 15 Release: Cactus 117,887 lines of code 2011 APR 15 Release: Cactus 117,887 lines of code 2011 SEP 22 Release: Diablo 478,671 lines of code 2011 SEP 22 Release: Diablo 478,671 lines of code 2011 FEB 3 Release: Bexar 85,425 lines of code 2011 FEB 3 Release: Bexar 85,425 lines of code 2010 OCT 21 Release: Austin 52,796 lines of code 2010 OCT 21 Release: Austin 52,796 lines of code COMMITS 39k for Grizzly + Havana (2x the previous 12 mos) Gold Sponsors Because an open interoperable Cloud is critical for flexible cloud deployment and customer success… Source: http://www.ohloh.net/p/openstack

3. OpenStack Architecture Including Keystone

4. Keystone is an OpenStack project that provides Identity, Token, Catalog and Policy services for use specifically by projects in the OpenStack family. It implements OpenStack’s Identity API What is OpenStack Keystone? • Core Use Cases: • Installation-wide authentication and authorization to OpenStack services Key Capabilities: • Authenticate user / password requests against multiple backends (SQL, LDAP, etc) (Identity Service) • Validate / manage tokens used after initial username/password verification (Token Service) • Endpoint registry of available services (Service Catalog) • Authorize API requests (Policy Service) • Domain / Project / User model with RBAC for access to compute, storage, networking • Policy service provides a rule-based authorization engine and the associated rule management interface. Image Source: http://www.solinea.com/2013/04/17/openstack-summit-intro-to-openstack-architecture-grizzly-edition/

5. Keystone Use Case: Launch a Server

6. Keystone Basics (V2) • Service Catalog • Create Projects (formerly known as Tenants) • Create Users • Create Roles • Map Users to Projects via Roles • Other OpenStack components (Nova, Glance, etc) look at the roles users have for a particular project and then perform their own policy based authorization based on the role information

7. Keystone Basics (V2) – Service Catalog • Keystone acts as a service catalog to let other OpenStack systems know where relevant API endpoints exist for OpenStack Services. • Also used by the OpenStack Dashboard • Keystone supports two means of defining the services • Catalog template whereby everything is detailed in the template. • SQL backend for the catalog service in which services are added dynamically once Keystone is running keystone service-create --name=swift --type=object-store --description="Swift Service" keystone endpoint-create --region RegionOne --service-id $SWIFT_SERVICE --publicurl “http://swift.publicinternets.com/v1/AUTH_1” --adminurl “http://swift.admin-nets.local:8080/” --internalurl “http://127.0.0.1:8080/v1/AUTH_1”

8. Keystone Basics (V2) – Service Catalog "serviceCatalog":[ { "endpoints":[ { "adminURL":"http://swift.admin-nets.local:8080/", "region":"RegionOne", "internalURL":"http://127.0.0.1:8080/v1/AUTH_1", "publicURL":"http://swift.publicinternets.com/v1/AUTH_1" } ], "type":"object-store", "name":"swift" }, { "endpoints":[ { "adminURL":"http://cdn.admin-nets.local/v1.1/1", "region":"RegionOne", "internalURL":"http://127.0.0.1:7777/v1.1/1", "publicURL":"http://cdn.publicinternets.com/v1.1/1" } ], "type":"object-store", "name":"cdn" } ]

9. Keystone Basics (V2) – Add User ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ user-create --name brad --pass brad ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ user-list

10. Keystone Basics (V2) – Add Role ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ role-create --name=admin ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ role-list

11. Keystone Basics (V2) – Add Project (AKA Tenant) ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ tenant-create --name=demo ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ tenant-list

12. Keystone Basics (V2) – Associate User to Project via Role ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ user-role-add --user ${BRAD_ID} --role ${ADMIN_ROLE} --tenant_id ${PROJECT_DEMO} ./with_venv.sh keystone --os-token ADMIN --os-endpoint http://127.0.0.1:35357/v2.0/ user-role-list --user ${BRAD_ID} --tenant_id ${PROJECT_DEMO}

13. Keystone Basics (V2) – Authenticate User and Get Token Back • Note: Keystone provides an easy to use python client for doing tasks such as authenticating users • But for fun let’s do it the “hard way” using curl to see the Keystone RESTful APIs in action curl -d '{"auth":{"passwordCredentials":{"username": "brad", "password": "brad"}}}' -H "Content-type: application/json" http://localhost:35357/v2.0/tokens Why are the roles empty?

14. Keystone Basics (V2) – Authenticate User and Get Token Back curl -d '{"auth":{"passwordCredentials":{"username": "brad", "password": "brad"}, "tenantName": "demo"}}' -H "Content-type: application/json" http://localhost:35357/v2.0/tokens Now that we specified a project (tenant) in the auth request, we have some roles. This is because user’s don’t have roles, they have roles on specific projects!

15. Keystone Basics (V3) • In addition to Projects, Users, and Roles, V3 has • Domains • Define the administrative boundaries for management of Keystone entities. • A domain can represent an individual, company, or operator owned space. • Groups • Represent a collection of users and are owned by a specific domain. • Roles explicitly associate groups with projects or domains. • A group role grant onto a project/domain is the equivalent of granting each individual member of the group the role on that project/domain. • The addition or removal of a user to such a group will result in the automatic granting/revoking of that role to the user.

16. Keystone Basics (V3) – Authenticate User and Get Token Back curl -si -d @./token-request.json -H "Content-type:application/json" http://127.0.0.1:35357/v3/auth/tokens token-request.json: "auth": { "identity": { "methods": [ "password" ], "password": { "user": { "domain": { "name": "Default" }, "name": "brad", "password": "brad" } } }, "scope": { "project": { "domain": { "name": "Default" }, "name": "demo" } } }

17. Keystone Basics (V3) – List Domains export TOKEN=`curl -si -d @./token-request.json -H "Content-type:application/json" http://127.0.0.1:35357/v3/auth/tokens | awk '/X-Subject-Token/{print $2}'` curl -si -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://localhost:35357/v3/domains

18. Keystone Basics (V3) – Create Domains curl -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" -d '{"domain": {"description": "new domain for my children", "enabled": true, "name": "new_children_domain"}}' http://localhost:35357/v3/domains curl -si -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://localhost:35357/v3/domains

19. Keystone Token Options • Old Style: UUID • Token is small but very inefficient • OpenStack projects have to go back to keystone for everything • Example: c062df7c808a4af98a57e967cbffa512 • New Style: PKI • Token is larger but contains role information • Token contains catalog, project, and role information • Token is digitally signed • Token can be cached • Revocation lists used to revoke tokens when they expire • Example: MIIDigYJKoZIhvcNAQcCoIIDezCCA3cCAQExCTAHBgUrDgMCGjCCAeAGCSqGSIb3DQEHAaCCAdEEggHNeyJ0b2tlbiI6IHsibWV0aG9kcyI6IFsicGFzc3dvcmQiXSwgInJvbGVzIjogW3siaWQiOiAiZmEyNTc2OTQyMjZjNDQ3ZjgzM2QzM2Y0ZmVlYjg3MjEiLCAibmFtZSI6ICJhZG1pbiJ9XSwgImV4cGlyZXNfYXQiOiAiMjAxNC0wMi0xNVQxNDowNDo0Mi4zNDE0OTNaIiwgInByb2plY3QiOiB7ImRvbWFpbiI6IHsiaWQiOiAiZGVmYXVsdCIsICJuYW1lIjogIkRlZmF1bHQifSwgImlkIjogImVhOGY5OWI5NzEyZjRlOTI5ZDg3N2IzNDUwNjAwMmExIiwgIm5hbWUiOiAiZGVtbyJ9LCAiY2F0YWxvZyI6IFtdLCAiZXh0cmFzIjoge30sICJ1c2VyIjogeyJkb21haW4iOiB7ImlkIjogImRlZmF1bHQiLCAibmFtZSI6ICJEZWZhdWx0In0sICJpZCI6ICI2ZTUyOGNiYzg0YTg0ODJmYmI3MzU3ODhmM2Q4Y2ZlNiIsICJuYW1lIjogImJyYWQifSwgImlzc3VlZF9hdCI6ICIyMDE0LTAyLTE1VDEzOjA0OjQyLjM0MTUyNVoifX0xggGBMIIBfQIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIDAVVbnNldDEOMAwGA1UEBwwFVW5zZXQxDjAMBgNVBAoMBVVuc2V0MRgwFgYDVQQDDA93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEAmV96iMNX4bGM-Uh7bfU1q2A8bUZ53FpZtNE9Osob+QgqyUTv0r7QC9WhjeiwLBF0ZVMK4p7F7KIUqJGUnJs9SY2gZuVmKFLiHFTLsXP30ySe1Hq-NrWg18WXGggjGEWDahiYyRv3nEB-+3REe7HfgsYMAjpWle4hn50jFJDsbs4eN3hCbJt+hw-6Za8yas9zOxJmseN6gL+91NO8l47jIbJ8o1H5XJugBLty2Qemt+g4Cr6j6rJOUtEmbp8a3y2ocDsQ9TEkdbyBBDtzny9iAgSslAVGeI7TscXQTnjywv4uwLYbR-hOYds7SyDAVAIWzTatqUXDbt0qlK97Pqp8tw==

20. Keystone Internal Policy File – etc/policy.json • Keystone provides lots of operations. How do we know who has authority to perform each operation? • Keystone has an internal policy engine for this • The policy is loaded from etc/policy.json { "admin_required": "role:admin or is_admin:1", "service_role": "role:service", "service_or_admin": "rule:admin_required or rule:service_role", "owner" : "user_id:%(user_id)s", "admin_or_owner": "rule:admin_required or rule:owner", "default": "rule:admin_required", "identity:get_project": "rule:admin_required", "identity:list_projects": "rule:admin_required", "identity:list_user_projects": "rule:admin_or_owner", "identity:create_project": "rule:admin_required", "identity:update_project": "rule:admin_required", "identity:delete_project": "rule:admin_required", "identity:validate_token": "rule:service_or_admin", "identity:get_user": "rule:admin_required", "identity:list_users": "rule:admin_required", "identity:create_user": "rule:admin_required", "identity:update_user": "rule:admin_required", "identity:delete_user": "rule:admin_required", "identity:change_password": "rule:admin_or_owner", …. }

21. Havana GA Occurred on 10/17/2013 Keystone Havana Improvements • Cacheable PKI based tokens for improved performance • ActiveDirectory, LDAP enablement • TLS Support for ActiveDirectory, LDAP • Separation of authentication and authorization to enable easier integration with read-only LDAPs and ActiveDirectories • Keystone provides excellent support for enterprises to reuse their existing directories • User identities and groups pulled from LDAP/AD • Role assignments, Projects, and Domains stored locally in Keystone’s database • Trusts for delegation of authorization • Used by the Heat OpenStack project • OAuth Support • Pluggable Token Providers • First-class support for deployment behind Apache httpd

22. Keystone Icehouse Improvements Icehouse GA Scheduled May 2014 • Identity Federation • Allow federating to an external identity provider without dependency on a particular protocol, but producing a reference implementation based on SAML v2.0, POST profiles, sender vouches • Manage remote identity providers including their required level of assurance, public keys, supported protocols, authorized attributes • Manage attribute mapping configurations per protocol that can be shared across identity providers including "attribute type mappings", "attribute type and value mappings", and "object mappings" • Token Revocation • Produce ephemeral tokens (thereby eliminating the need for the token backend) and reduce network load caused by authentication validation • Token revocation events emitted as notifications • Distributed auth middleware needs to listen for revocation notifications

23. Icehouse GA Scheduled May 2014 Keystone Icehouse Improvements • Password Rotation • Allow deployers to configure the grace period used by the SQL identity backend during which passwords remain valid after a new password has been set • On self-service password changes with a zero second (default) grace period, a token revocation event should be emitted (this maintains the current behavior) • On self-service password changes with a non-zero grace period, the old password remains in effect for the duration of the grace period and no token revocation event is ever emitted • On administrative password resets, a token revocation event should be immediately emitted, the new password should immediately take effect, and all old passwords should be immediately expired (this basically maintains the current behavior) • Delegation • Both the trusts and OAuth 1.0a implementations have discrete advantages and serve slightly different use cases; neither will be deprecated or replaced anytime soon • Add OAuth 1.0a support to client library • Allow trust to delegation to user groups • Auditing • Leverage CADF auditing notifications from oslo for authentication decisions to be consumed by Ceilometer

24. Cloud Auditing: Customer Importance: Self-Managing Auditing Data on Clouds CloudProvider A SaaS Application SaaS Application Customer Company Auditor and Admins. Customer’s Compliance & Monitoring Tools Hybrid Application Hybrid Application Customers will not trust clouds to host their workloads & data without the ability to self-audit and monitor the provider’s platform and infrastructure Problem • DMTF CADF Standard’s model and format enables: • Key event data can be NormalizedandCategorizedfor federation and aggregation • Assuring consistent mappings across cloud components and cloud providers • CorrelatingEvent data from all Cloud layers(App, Platform, Infrastructure) • without exposing architecture or details of the underlying provider infrastructure • Creating Customized Views for different compliance needs • Track regional, industry or corporate policy and SLA compliance … • using standardized APIS / Reports CloudProvider B • Customer Benefits • Reusable, standards-based Auditing & Monitoring Tools • Opportunities to leverage open source tooling • Aggregate Audit Data from Different Clouds / Partners • Analyze information from different Cloud Providers • APIs to self-manage event and log contents CloudProvider C 24

25. “CSI for Clouds” : How the CADF answers the 7 “W”s of Audit(OpenStack Nova API request example) 25

26. Keystone CADF Authentication Example {'typeURI': 'http://schemas.dmtf.org/cloud/audit/1.0/event', 'initiator': {'typeURI': 'service/security/account/user', 'host': {'agent': 'curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3', 'address': '127.0.0.1'}, 'id': 'openstack:5ee22124-6f41-4d23-a9f7-862c13a53a66', 'name': u'joeuser'}, 'target': {'typeURI': 'service/security/account/user', 'id': 'openstack:1c2fc591-facb-4479-a327-520dade1ea15'}, 'observer': {'typeURI': 'service/security', 'id': 'openstack:3d4a50a9-2b59-438b-bf19-c231f9c7625a'}, 'eventType': 'activity', 'eventTime': '2014-02-14T01:20:47.932842+0000', 'action': 'authenticate', 'outcome': 'failure', 'id': 'openstack:f5352d7b-bee6-4c22-8213-450e7b646e9f'}

27. Questions?