Building IAM for OpenStack

Steve MartinelliSoftware Developer, IBMKeystone Core

Agenda

● OpenStack and Keystone Overview

● Identity Sources

● Authentication

● Identity Federation

● Access Management Model in OpenStack

● Future Plans

OpenStack and Keystone: The Quick Overview!

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

Lots of different companies using OpenStackA lot of individuals and companies have contributed to making Keystone awesome (just to name a few…)

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

Scale of Keystone DeploymentsSmall

● 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

Identity Sources

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

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

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

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 IdentityProvider and the other application as the Service Provider

Use Case:- Leverage new Federated Identity

- An IdP already exists

- Non-LDAP identity source

Authentication

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

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!

Access Management Model in OpenStack

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 VM2. 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

3. 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>"

4. Depending on the policy set for the API, the user’s request will be rejected or successful

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

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

Identity Federation

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

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

Federated Identity Flow

Federated Identity Flow

Federated Identity Flow

Federated Identity Flow

Federated Identity Flow

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

● When the user loads Horizon, they can select the protocol desired, or use the old service accounts

Single Sign-On GUI Flow

● Once a federated protocol is selected, the branded login page will appear

Single Sign-On GUI Flow

● When authenticated with their Identity Provider, the user will be logged into Horizon

Single Sign-On GUI Flow

Single Sign-On Flow

Single Sign-On Flow

Single Sign-On Flow

Single Sign-On Flow

Single Sign-On Flow

Single Sign-On Flow

Single Sign-On Flow

Keystone 2 Keystone Federation● Federating Identities from one deployment to another

○ Works almost identically to the normal Federated Identity FlowExcept 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!

Keystone 2 Keystone Architecture

Keystone

Nova

Glance

Keystone

Nova

Glance

Local Cloud

RemoteCloud

A. Add Remote Cloud as a Service Provider

B. Add Local Cloud as an Identity Provider

1. Ask for SAML

assertion

2. Return SAML assertion

3. Present SAML

assertion

4. Return a Keystone

Token that can be used

on the Remote Cloud

One time setup performed by cloud admins

LocalCloudUser

Future Plans

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

Questions?

Backup Slides

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.

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

Keystone Auth Token Middleware● A common authentication protocol used between OpenStack projects● Added to the paste pipeline of other projects

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!

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