OpenStack Toronto Meetup - Keystone 101
Download as PPTX, PDF3 likes1,331 views
The document outlines a presentation on OpenStack Keystone 101 led by Steve Martinelli, introducing Keystone's identity management capabilities, core concepts of the identity APIs, and IBM's contributions to OpenStack. It covers various aspects of Keystone, including API versions, token formats, identity backends like SQL and LDAP, and details about the authentication flow. Additionally, it discusses Keystone's middleware and client libraries, along with examples and use-cases related to managing users and federated identity systems.
![{
"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:35357/v2.0",
"region": "RegionOne",
"internalURL": " http: //cdn.admin-nets.local:5000/v2.0 ",
"publicURL": " http: //cdn.admin-nets.local:5000/v2.0 "
}
],
"type": “identity",
"name": “keystone"
}
]
}
Sample Service Catalog](https://image.slidesharecdn.com/openstack-toronto-meetup-keystone101-150609210354-lva1-app6891/85/OpenStack-Toronto-Meetup-Keystone-101-6-320.jpg)
![● /v3/auth/tokens
○ POST – authenticate to get a token
○ GET – validate a token
○ HEAD – validate a token (no data)
○ DELETE – invalidate a token
Request endpoint and HTTP method: POST http://localhost:5000/v3/auth/tokens
Request body:
{ "auth": {
"identity": {
"methods": ["password"],
"password": {
"user": {
"name": "admin",
"domain": { "id": "default" },
"password": "adminpassword"
}
}
},
"scope": {
"project": {
"name": "demo",
"domain": { "id": "default" }
}
}
}
}
Token APIs and Request
<< Methods describes the authentication plugin that is
being used. Aside from password, other valid options are
`token`, `external`, and a few other experimental ones.
<< Scope describes the what the user wants the returned
token to be valid on. Scopes can be a project or domain.
Scope can be one of the following:
1) Project ID
2) Domain ID
3) Project Name + Domain ID
4) Project Name + Domain Name](https://image.slidesharecdn.com/openstack-toronto-meetup-keystone101-150609210354-lva1-app6891/85/OpenStack-Toronto-Meetup-Keystone-101-13-320.jpg)
![{
"token": {
"methods": [
"password"
],
"roles": [{
"id": "c703057be878458588961ce9a0ce686b",
"name": "admin"}
],
"expires_at": "2014-06-10T2:55:16.806001Z",
"project": {
"domain": {
"id": "default",
"name": "Default"
},
"id": "8538a3f13f9541b28c2620eb19065e45",
"name": "admin"
},
"catalog": [
{
"endpoints": [{
"url": "http://localhost:5000/v2.0",
"region": "RegionOne",
"interface": "public",
"id": "ef303187fc8d41668f25199c298396a5"}
],
"type": "identity",
"id": "bd73972c0e14fb69bae8ff76e112a90",
"name": "keystone"
}
],
"user": {
"domain": {
"id": "default",
"name": "Default"
},
"id": "3ec3164f750146be97f21559ee4d9c51",
"name": "admin"
},
"issued_at": "201406-10T20:55:16.806027Z"
}
}
Analyzing the token response
Keystone returns the ID of the Token in the
X-Subject-Token header, and the token
content in the body.
<< Roles represents the roles that the user
has on the resource.
<< Project represents the resource the user
has a role on. From the scope in the
request.
<< Catalog describes the different services
a user may access, and their various
endpoints.
Services may be: compute, identity, image,
orchestration, etc.
<< User represents the user that was
issued the token.](https://image.slidesharecdn.com/openstack-toronto-meetup-keystone101-150609210354-lva1-app6891/85/OpenStack-Toronto-Meetup-Keystone-101-14-320.jpg)
OpenStack Toronto Meetup - Keystone 101
- 1. OpenStack Toronto Meetup - February Keystone 101 Steve Martinelli Software Developer, IBM Keystone Core Twitter: @stevebot
- 2. Agenda ● Who is this guy and what does he do? ● Keystone 101 o Main uses of Keystone o Identity API v2 vs Identity API v3 o Token formats o Token APIs o Identity Backends o Keystone Middleware o Keystone Clients ● IBM’s involvement in OpenStack ● Q & (possibly) A
- 3. ● Joined what is now the IBM Open Technologies team in December 2012. Primarily focused on contributing code to upstream projects and being good members of the OpenStack community. ● I’m primarily focused in Keystone (Identity program) and OpenStackClient (Command Line). Core reviewer in four projects: keystone, python-openstackclient, oslo.policy, pycadf. ● I’ve also contributed to a few other projects: devstack, infra, ceilometer, oslo.*, and most of the *-specs repositories. If you see something in need of fixing, push up a patch. My typical day… ● TODO: open source, code review/gerrit, tests required, mailing list / IRC, blueprint/spec process, gate status, bug fixes/dev Who is this guy and what does he do?
- 4. ● Get a token o Token required to access other resources/services o Contains the user's roles on the project ● Get the service catalog o URL to the other service ● Returned by POST /v3/auth/tokens Uses of Identity API – As a user Uses of Identity API – As an admin ● Define ○ Users, Groups ○ Projects ○ Roles ○ Roles for users on projects ○ Services, endpoints for services
- 5. ● Validate a token ○ auth_token middleware ✓ Works with V2 and V3 tokens ✓ Works with PKI and UUID tokens ✓ Revocation list ✓ Extracts roles, other info from token ○ Supplied by keystonemiddleware package ● Discover other service endpoints ● Get a trust to impersonate user Uses of Identity API – As a service Keystone APIs are hosted here: http://specs.openstack.org/openstack/keystone-specs/
- 6. { "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:35357/v2.0", "region": "RegionOne", "internalURL": " http: //cdn.admin-nets.local:5000/v2.0 ", "publicURL": " http: //cdn.admin-nets.local:5000/v2.0 " } ], "type": “identity", "name": “keystone" } ] } Sample Service Catalog
- 7. Identity API ● Identity API is a standard, it now has v2 and v3 ● Anyone could implement the Identity API, Keystone is one example ● There is no Keystone V2 or Keystone V3 or a way to upgrade from one to the other! Identity API v2 ● Public API ○ Port 5000 (http://localhost:5000/v2.0) ○ Get tokens, List tenants, very limited ● Admin API, most other Keystone operations, they are admin only ○ (http://localhost:35357/v2.0) Identity API v3 ● Full support for Identity API v2 ● Renamed “tenants” to “projects” ● Token IDs are not in the URL for security, they are in X-Subject-Token header Keystone ● Both “admin” 35357 and “public” 5000 ports ● Protected by RBAC (policy.json) ● Grizzly supports Identity API V3.0, Havana has V3.1, IceHouse is V3.2 Identity API v2 vs Identity API v3 vs Keystone
- 8. ● Users exist in a backend (SQL/LDAP/Other). ● AuthN: The user authenticates by providing user id and password. ● AuthZ: The user should have a role on a project. ● Keystone returns a token with that is scoped to the role and project. ● The user will pass this token around to the other OpenStack services. Keystone Classic AuthN/AuthZ flow Nova Swift Keystone Auth Plugins: https://github.com/openstack/keystone/tree/master/keystone/auth/plugins Auth Controller: https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py
- 9. ● UUID ○ Looks like a 32 character string: 468da447bd1c4821bbc5def0498fd441 ○ Pros: ✓ Better user experience ✓ No problem with token length ○ Cons: ✓ Goes back to Keystone server for validation ○ How the Provider creates an ID: Token Formats Common Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py UUID Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/uuid.py Token Model: https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py
- 10. ● PKI ○ Looks like: MIIDsAYJKoZIhvcNAQcCoIIDoTCCA50CAQExCTAHBgUrDgMCGjCCAokGCSqGSIb3DQEHAaCCAnoEggJ2ew0KICAgICJhY2Q ogICAgICAgI...EBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVVuc2V0MQ4wDAYDVQQHEwVVbnNldDEOMAwGA1UEChM 7r0iosFscpnfCuc8jGMobyfApz/dZqJnsk4lt1ahlNTpXQeVFxNK/ydKL+tzEjg ○ Pros: ✓ Does not go back to Keystone for validation ○ Cons: ✓ Complex to setup ✓ Several problems with length - had caused issues with swift and horizon ○ How the Provider creates an ID: Token Formats Common Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py PKI Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/pki.py Token Model: https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py
- 11. ● PKIz ○ Compressed version of PKI ○ Looks similar to PKI, but slightly shorter ○ How the Provider creates an ID: Token Formats Common Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py PKIz Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/pkiz.py Token Model: https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py
- 12. ● KLWT (Keystone Lightweight Token) ○ New in Kilo!! The code isn’t even merged yet, but it should be by feature freeze. ○ Doesn’t actually store tokens in any database! ○ The token consists of a bunch of data that is signed and hashed: Data is: (user_id, scope_id, issued_at, *expires_at*, audit_ids) ○ Token Format prefix: KLWT00 for regular token, KLWT01 for trusts, etc. ○ Keystone middleware must be updated to provide the ability to decrypt the token To be implemented Token Formats Common Provider: https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py Token Model: https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py
- 13. ● /v3/auth/tokens ○ POST – authenticate to get a token ○ GET – validate a token ○ HEAD – validate a token (no data) ○ DELETE – invalidate a token Request endpoint and HTTP method: POST http://localhost:5000/v3/auth/tokens Request body: { "auth": { "identity": { "methods": ["password"], "password": { "user": { "name": "admin", "domain": { "id": "default" }, "password": "adminpassword" } } }, "scope": { "project": { "name": "demo", "domain": { "id": "default" } } } } } Token APIs and Request << Methods describes the authentication plugin that is being used. Aside from password, other valid options are `token`, `external`, and a few other experimental ones. << Scope describes the what the user wants the returned token to be valid on. Scopes can be a project or domain. Scope can be one of the following: 1) Project ID 2) Domain ID 3) Project Name + Domain ID 4) Project Name + Domain Name
- 14. { "token": { "methods": [ "password" ], "roles": [{ "id": "c703057be878458588961ce9a0ce686b", "name": "admin"} ], "expires_at": "2014-06-10T2:55:16.806001Z", "project": { "domain": { "id": "default", "name": "Default" }, "id": "8538a3f13f9541b28c2620eb19065e45", "name": "admin" }, "catalog": [ { "endpoints": [{ "url": "http://localhost:5000/v2.0", "region": "RegionOne", "interface": "public", "id": "ef303187fc8d41668f25199c298396a5"} ], "type": "identity", "id": "bd73972c0e14fb69bae8ff76e112a90", "name": "keystone" } ], "user": { "domain": { "id": "default", "name": "Default" }, "id": "3ec3164f750146be97f21559ee4d9c51", "name": "admin" }, "issued_at": "201406-10T20:55:16.806027Z" } } Analyzing the token response Keystone returns the ID of the Token in the X-Subject-Token header, and the token content in the body. << Roles represents the roles that the user has on the resource. << Project represents the resource the user has a role on. From the scope in the request. << Catalog describes the different services a user may access, and their various endpoints. Services may be: compute, identity, image, orchestration, etc. << User represents the user that was issued the token.
- 15. ● Users are managed by Keystone ● Settings for connecting to a database are handled in Keystone’s config file ● Essentially, Keystone is acting as an Identity Provider ● Pros: o Easy to setup o Easier management of users and groups ● Cons: o Keystone shouldn’t be an Identity Provider o Weak password support ✓ No password rotation ✓ No password recovery o Most enterprises have an LDAP they want to use o Yet another username and password users must remember Identity Backends - SQL SQL Backend: https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py
- 16. ● Keystone accessing LDAP should be act just like any other application ● Keystone operations performed on LDAP ○ User/Group lookup (search) ○ Authentication of users (bind) ● What rights does Keystone need in LDAP? ○ Read access to user/group attributes defined in keystone.conf ○ Unprivileged account or anonymous is preferable ○ Access to password hashes is not needed Identity Backends - LDAP - Basics * awesome diagrams provided by nkinder LDAP Backend: https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap.py
- 17. Configured Keystone to use our Internal LDAP, and I was able to authenticating with username stevemar@ca.ibm.com and my own intranet password. Listing users in a group: steve:keystone$ openstack user list --group openstackers +-----------+--------------------------------+ | ID | Name | +-----------+--------------------------------+ | 111111111 | user1111@us.ibm.com | | 222222222 | user2222@us.ibm.com | | 333333333 | user3333@us.ibm.com | | 123456789 | stevemar@ca.ibm.com | Listing groups a user belongs to: steve:keystone$ openstack group list --user 123456789 +-----------+--------------------------------+ | ID | Name | +-----------+--------------------------------+ | 444444444 | vpn-users | | 555555555 | openstackers | | 666666666 | softwaregroup_canada | *Slight changes made to names/emails/ids Identity Backends - LDAP - Example
- 18. ● A common authentication protocol in use between the OpenStack projects. o Added to the paste pipeline of other projects Keystone Auth Token Middleware Middleware example config: http://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html#configuration Middleware __call__: https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L783 Middleware validate: https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L929
- 19. ● KeystoneClient (python-keystoneclient) ○ Essentially two parts: a library, and a command line ○ The library supports V2 & V3 API Modules can be imported and used like any other python library. ○ KeystoneClient’s CLI supports only Identity V2 ● OpenStackClient (python-openstackclient) ○ Strictly a command line, supports Identity V2 and V3 ○ Leverages the libraries that KeystoneClient supports ○ Also supports Nova/Glance/Cinder/Swift/etc… ○ Community direction is to create a common CLI. Keystone Clients OpenStackClient: http://docs.openstack.org/developer/python-openstackclient/ KeystonClient vs OpenStackClient: https://github.com/openstack/keystone/blob/master/doc/source/cli_examples.rst
- 20. Questions? … and hopefully some answers
- 21. Backup slides
- 22. ● Users ○ id, name, description, enabled, mail ○ Enabled attribute can be emulated via group membership ● Groups ○ id, name, description, member ○ id and name are both considered to be unique ● inetOrgPerson (User) example ○ dn: uid=someuser,cn=users,dc=example,dc=com ○ objectclass: inetorgperson ○ uid: someuser (<---- id, name) ○ cn: Some User ○ mail: someuser@example.com (<---- mail) ● Group example ○ dn: cn=Some Group,cn=users,dc=example,dc=com ○ objectclass: group ○ cn: Some User (<---- id, name) ○ description: Some Group (<---- description) ○ member: <user DN> (<---- member) Identity Backends - LDAP - Attributes LDAP Seach function: https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L916-L943
- 23. ● Domains are a grouping of users, groups, and project ● Now able to configure more than one LDAP backend ● Configure one LDAP per domains ○ Set domain_specific_drivers_enabled = true ○ Domain specific partial config files are placed in: /etc/keystone/domains/keystone.<domain>.conf Identity Backends - LDAP - Enhancements * awesome diagrams provided by nkinder LDAP Mapping: https://github.com/openstack/keystone/blob/master/keystone/identity/mapping_backends/sql.py#L23-L25
- 24. ● Keystone has generic federation capabilities, which allows for external users to be recognized ● Users are not persisted in Keystone, but are created on the fly from external user information provided by a trusted identity provider ● Use-cases ○ Existing internal IdP, Single Sign On ○ Inaccessible LDAP identity source ○ Non-LDAP identity source ● Currently support the following federation protocols: o SAML 2.0 o OpenID Connect Federation OS-FEDERATION API: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html
- 25. ● Identity Provider (IdP) ○ Trusted provider of identity information ● Service Provider (SP) ○ Service that consumes identity information (Keystone) ● Assertion ○ Trusted representation of identity attributes issued by IdP for consumption by SP ● Using the SAML protocol an Assertion represents identity attributes, whereas the OpenID Connect protocol has Claims. Federation - Concepts * awesome diagrams provided by nkinder Docs for configuring federation: http://docs.openstack.org/developer/keystone/configure_federation.html
- 26. ● Groups are created in Keystone's identity backend for the purpose of role assignment ○ Mapping establishes group membership ● Federation specific auth URL is used to obtain an unscoped token ○ Simply identifies user and groups ● Unscoped federation token is used to obtain a scoped token ○ Contains group assigned roles Federation * awesome diagrams provided by nkinder Mapping function: https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/utils.py#L145-L230