Building IAM for OpenStack
Download as PPTX, PDF14 likes6,054 views
The document provides an overview of Keystone, OpenStack's identity and access management service, detailing its features, deployment scales, identity sources, authentication methods, and future plans. It explores the integration of Keystone with various identity providers, the use of federated identities, and the access management model based on role-based access control. Keystone is positioned to handle diverse deployment scales from small developer environments to large enterprise setups, with ongoing enhancements planned for multi-factor authentication and authorization methods.
![What does a Keystone token look like?
{
"token": {
"issued_at": "201406-10T20:55:16.806027Z",
"expires_at": "2014-06-10T2:55:16.806001Z",
"roles": [{
"id": "c703057be878458588961ce9a0ce686b",
"name": "admin"}
],
"project": {
"domain": { "id": "default",
"name": "Default" },
"id": "8538a3f13f9541b28c2620eb19065e45",
"name": "admin"
},
"user": {
"domain": { "id": "default",
"name": "Default" },
"id": "3ec3164f750146be97f21559ee4d9c51",
"name": "admin"
},
"catalog": [
{
"endpoints": [...],
"type": "identity",
"id": "bd73972c0e14fb69bae8ff76e112a90",
"name": "keystone"
}
]
}
}
<< 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
<< User represents the user that was issued the
token
<< Catalog describes the different services a
user may access, and their various endpoints
Services may be: compute, identity, image,
orchestration, etc](https://image.slidesharecdn.com/cloudidentitysummit-buildingiamforopenstack-150609205715-lva1-app6891/85/Building-IAM-for-OpenStack-18-320.jpg)
Building IAM for OpenStack
- 1. Building IAM for OpenStack Steve Martinelli Software Developer, IBM Keystone Core
- 2. Agenda ● OpenStack and Keystone Overview ● Identity Sources ● Authentication ● Identity Federation ● Access Management Model in OpenStack ● Future Plans
- 3. OpenStack and Keystone: The Quick Overview!
- 4. OpenStack Overview ● OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a rich set of APIs and a dashboard that gives administrators control while empowering their users to provision resources through a web interface ● OpenStack’s goals are to support interoperability between cloud services and allow businesses to build AWS-like cloud services in their own data centers ● Available as Free and Open Source under the Apache 2.0 license Keystone - provides authentication and authorization for all the services. Nova - provides virtual machines (VMs) Swift - supports object storage. Cinder - persistent block storage to VMs. Glance - catalog and repository for virtual disk images. Horizon - Web-based interface for services. Neutron - networking-as-a-service between interface devices
- 5. Lots of different companies using OpenStack A lot of individuals and companies have contributed to making Keystone awesome (just to name a few…)
- 6. Keystone Overview ● OpenStack’s Identity and Access Management (IAM) Service ○ Authentication ○ Authorization ○ Audit ○ Identity ○ OpenStack Service Discovery ● Supports integration with a variety of Identity Providers ● Pluggable authentication architecture ● Supports multiple API Authorization Token formats ● New enhancements include support for standard federation protocols ● Access management for all OpenStack services
- 7. Scale of Keystone Deployments Small ● Developer environments have OpenStack “all-in-one” deployments ● Devstack is used by most developers to spin up a deployment with compute/storage/networking/identity Medium ● Single datacenter ● Multiple Keystone instances using HAProxy for load balancing Large ● Several OpenStack deployments spread over many geographically disperse areas ● Multiple Keystone instances using HAProxy for load balancing and SQL/LDAP replication to keep data in synchronized Very Large / Multiple Organizations (Hybrid/Composite) ● Many OpenStack deployments spread over many geographically disperse areas ● Uses Federated Identity to allow near-seamless access to all deployments ● Some deployments will provide specific services / features
- 9. SQL ● Users, groups, and credentials 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: ○ Easy to setup ○ Management of users and groups through OpenStack APIs ● Cons: ○ Keystone shouldn’t be an Identity Provider ○ Weak password support No password rotation No password recovery No password enforcement No failed login attempt lockout support ○ Most enterprises have an LDAP server that they want to use ○ Identity silo - Yet another username and password users must remember Use Case: - Testing or developing with OpenStack - Saving OpenStack service accounts
- 10. LDAP ● Keystone accessing LDAP should 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 Use Case: - It’s already in place in your enterprise - Able to create the necessary service accounts
- 11. Multiple Backends ● As of the Juno release, Keystone supports multiple backends ● One domain per backend ● The default domain must be the SQL backend, it is used to host service accounts ○ Ideally, the default domain should be normal users (LDAP), but this requires service accounts to know how to use the v3 API ○ Support for services accounts outside the default domain will be available in a future release ● Any additional LDAP backends should be managed by their own domain Use Case: - Preferred approach for most enterprises
- 12. Identity Provider (IdP) ● A source for identities (Internal IdP, Google, Facebook, Twitter) ● Handles authentication and provides identity information ● Usually backed by LDAP, but could be something else, like AD (Active Directory) ● Essentially, software that abstracts out the actual backend and translates user attributes to a standard protocol format (SAML, OpenID Connect, etc.) ● If you’ve ever used your Gmail account to sign into another online application… then you’ve used Google as the Identity Provider and the other application as the Service Provider Use Case: - Leverage new Federated Identity - An IdP already exists - Non-LDAP identity source
- 13. Authentication
- 14. Password ● User provides their username and password ● Keystone returns a token that the user may use at other OpenStack services ● The token will eventually expire (configured in Keystone) ● Used for initially logging into Keystone or setting up service accounts for other OpenStack services Token Token Password
- 15. Token ● Users can exchange their existing (valid) token for a newer token ● Also satisfies the case where a user can receive an unscoped token (initially), and exchange that for a scoped token ● Used by federation client code Token Token Token Supports Kerberos too!
- 16. Access Management Model in OpenStack
- 17. Access Management Model in OpenStack ● Access is controlled by RBAC and endpoint validation Use Case: If a user wants to start a VM, what is the full flow? 1. Authenticate with Keystone, specifies their user name, password, and project associated with the VM 2. The user gets back a token that is scoped to that project, it carries authorization data within it (a set of roles the user has on that project) NOTE: The role could have been granted at the user level or group level 1. The user makes a requests to the start server API (/v2/{tenant_id}/servers/{server_id}/action) with the header "X-Auth-Token: <new_token>" 2. Depending on the policy set for the API, the user’s request will be rejected or successful
- 18. What does a Keystone token look like? { "token": { "issued_at": "201406-10T20:55:16.806027Z", "expires_at": "2014-06-10T2:55:16.806001Z", "roles": [{ "id": "c703057be878458588961ce9a0ce686b", "name": "admin"} ], "project": { "domain": { "id": "default", "name": "Default" }, "id": "8538a3f13f9541b28c2620eb19065e45", "name": "admin" }, "user": { "domain": { "id": "default", "name": "Default" }, "id": "3ec3164f750146be97f21559ee4d9c51", "name": "admin" }, "catalog": [ { "endpoints": [...], "type": "identity", "id": "bd73972c0e14fb69bae8ff76e112a90", "name": "keystone" } ] } } << 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 << User represents the user that was issued the token << Catalog describes the different services a user may access, and their various endpoints Services may be: compute, identity, image, orchestration, etc
- 19. Access Management Model in OpenStack How to determine if a user can perform an action? ● All APIs are documented in a policy.json file ● A policy file is broken up into Targets and Rules ● Targets map to a specific API ● Rules are a set of simple or complex checks (RoleCheck, RuleCheck, OrCheck, AndCheck) ● For example… compute:start maps to /v2/{tenant_id}/servers/{server_id}/action definitions targets rules
- 21. Federated Identity ● Users can exist in an identity store that is not accessible by Keystone, or is owned by a different entity ● Keystone federation allows for users identity to be provided as a part of the authentication request ○ Identity info is provided as environment variables ● Keystone is protocol agnostic, all federation protocol details are handled by Apache HTTPD modules ○ SAML - mod_shib, mod_auth_mellon ○ OpenID Connect - mod_auth_openidc ● Terminology ○ 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 ■ If using SAML, the assertion represents identity attributes ■ If using OpenID Connect, the assertion is a set of claims
- 22. Mapping Engine ● 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
- 28. Single Sign-On ● The most demanded Federation feature in OpenStack is finally here! ● Cross project work item between Keystone and Horizon. ○ Work items in three different projects: Keystone, Horizon and django_openstack_auth ● Classic Web Single Sign-On experience in Horizon ○ Protocol agnostic (supports SAML, OpenID Connect, Kerberos, etc.) ○ Keystone still acts as a Service Provider ○ Provides users with familiar branding ○ One less password for Keystone and Horizon to see
- 29. ● When the user loads Horizon, they can select the protocol desired, or use the old service accounts Single Sign-On GUI Flow
- 30. ● Once a federated protocol is selected, the branded login page will appear Single Sign-On GUI Flow
- 31. ● When authenticated with their Identity Provider, the user will be logged into Horizon Single Sign-On GUI Flow
- 39. Keystone 2 Keystone Federation ● Federating Identities from one deployment to another ○ Works almost identically to the normal Federated Identity Flow Except the originating SAML IdP is another Keystone ○ Trust relationship between each deployment must be explicitly setup ○ Leverages Identity Provider Initiated SAML Flow: ● User authenticates with their own cloud ● Exchanges token for an assertion ● Forwards the assertion to another cloud ● User now has a token for the remote cloud Highlighted at the Keynote of the last OpenStack summit!
- 40. Keystone 2 Keystone Architecture Keystone Nova Glance Keystone Nova Glance Local Cloud Remote Cloud A. Add Remote Cloud as a Service Provider B. Add Local Cloud as an Identity Provider One time setup performed by cloud admins Local Cloud User
- 41. Future Plans
- 42. Future Plans ● MFA - Rackspace has proposed an MFA specification that is in progress ○ Would be pluggable so vendors can implement their own MFA ● Federated Identity Enhancements (polish off rough edges from Federated Identity Keynote) ○ Better client experience ○ Easier mapping rules ● Authorization Enforcement (Tokenless Auth) ○ Use X509 instead of passwords ○ No token needed (with X509) for interacting with Keystone CRUD interfaces ● Dynamic Policy ○ Rather than relying on the policy files themselves, this data should be stored in a database and cached
- 43. Questions?
- 44. Backup Slides
- 45. Title and Abstract Title: Building IAM for OpenStack Abstract: Keystone is the IAM project for OpenStack, and as such has to handle many different methods of deployment – On-Prem, Hybrid, Hosted – at many differing levels of scale. Some deployments are no more than a VM used for development purposes, while others are 100,000s of cores across multiple data centers and continents. This session will cover details of Keystone, what can be accomplished with it today, how OpenStack integrates with your enterprise identity solution, federated identity across OpenStack deployments, the OpenStack model of access management today, and our plans for the future.
- 46. not so pretty agenda to keep for slide titling (ICK!) ● Keystone in two minutes or less! ○ Keystone Overview ○ Identity API vs Keystone ○ Scale of Keystone Deployments (1 vm to 1000s of physical machines) ● Identity Sources ○ Direct Connect (SQL, LDAP, Multiple Backends, SSSD) ○ Identity Provider (IdP) ○ Use Cases ● Authentication ○ Password ○ Token ○ External (Kerberos, x509, etc) ○ Multi-Factor ● Identity Federation ○ Federation (SAML, OpenID Connect, ABFAB, etc) ○ Keystone2Keystone Identity Federation ○ Web Single Sign-On ● Access Management Model in OpenStack ○ RBAC ○ Authorization ○ Endpoint Validation of AuthZ ● Future Plans ○ Enhancements to Direct Identity Sources ○ Federated Identity ○ Authorization Enforcement ● Closing statements
- 47. Keystone Auth Token Middleware ● A common authentication protocol used between OpenStack projects ● Added to the paste pipeline of other projects
- 48. SSSD ● Available in a future release of OpenStack as an Identity Source ● Identity information lookup can be offloaded to the underlying platform using SSSD ● Eliminates the complexity of LDAP handling within Keystone ● SSSD - System Security Services Daemon ○ Provides access to remove authentication and identity sources (FreeIPA, Active Directory, LDAP) ○ Support caching for high performance and fault tolerance ○ Supports failover for fault tolerance ○ Integrates via PAM, NSS, and DBUS ● mod_lookup_identity ○ Performs lookup of identity attributes from SSSD via DBUS ○ Provides identity attributes as environment variables to web applications ● mod_auth_* + mod_lookup_identity looks exactly the same as federation from the perspective of Keystone!
- 49. Multi-Factor Authentication ● When knowing a password is not enough ● These factors could be: ○ knowledge based (questions) ○ possession based (security tokens, text messages) ○ inherence based (biometrics) ● FreeIPA has support for (One Time Password) OTP ○ Keystone can work with it via it’s LDAP identity driver or via SSSD (federated LDAP) ○ HOTP/TOTP tokens (Yubikey, FreeOTP, Google Authenticator) ● Rackspace has proposed an MFA specification that is in progress ○ Would be pluggable so vendors can implement their own MFA