CIS 2015- Building IAM for OpenStack- Steve Martinelli

Building IAM for OpenStack

Steve Martinelli Software Developer, IBM Keystone Core

Agenda ●  OpenStack and Keystone Overview ●  Iden6ty Sources ●  Authen6ca6on ●  Iden6ty Federa6on ●  Access Management Model in OpenStack ●  Future Plans

OpenStack and Keystone: The Quick Overview!

OpenStack Overview ●  OpenStack is a cloud opera6ng 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 OpenStack A lot of individuals and companies have contributed to making Keystone awesome (just to name a few…)

Keystone Overview ●  OpenStack’s Iden6ty and Access Management (IAM) Service

○  Authen6ca6on ○  Authoriza6on ○  Audit ○  Iden6ty ○  OpenStack Service Discovery

●  Supports integra6on with a variety of Iden6ty Providers ●  Pluggable authen6ca6on architecture ●  Supports mul6ple API Authoriza6on Token formats ●  New enhancements include support for standard federa6on protocols ●  Access management for all OpenStack services

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/iden6ty

Medium ●  Single datacenter ●  Mul6ple Keystone instances using HAProxy for load balancing

Large ●  Several OpenStack deployments spread over many geographically disperse areas ●  Mul6ple Keystone instances using HAProxy for load balancing and SQL/LDAP replica6on to keep data in

synchronized Very Large / Mul6ple Organiza6ons (Hybrid/Composite) ●  Many OpenStack deployments spread over many geographically disperse areas ●  Uses Federated Iden6ty to allow near-‐seamless access to all deployments ●  Some deployments will provide specific services / features

Identity Sources

SQL ●  Users, groups, and creden6als are managed by Keystone ●  Se]ngs for connec6ng to a database are handled in Keystone’s config file ●  Essen6ally, Keystone is ac6ng as an Iden6ty Provider ●  Pros:

○  Easy to setup ○  Management of users and groups through OpenStack APIs

●  Cons: ○  Keystone shouldn’t be an Iden6ty Provider ○  Weak password support

§  No password rota6on §  No password recovery §  No password enforcement §  No failed login aèmpt lockout support

○  Most enterprises have an LDAP server that they want to use ○  Iden6ty silo -‐ Yet another username and password users must remember

Use Case: -‐ Tes6ng or developing with OpenStack -‐ Saving OpenStack service accounts

LDAP ●  Keystone accessing LDAP should act just like any other applica6on ●  Keystone opera6ons performed on LDAP

○  User/Group lookup (search) ○  Authen6ca6on of users (bind)

●  What rights does Keystone need in LDAP? ○  Read access to user/group a`ributes 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 mul6ple 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 addi6onal LDAP backends should be managed by their own domain

Use Case: -‐ Preferred approach for most enterprises

Identity Provider (IdP) ●  A source for iden66es (Internal IdP, Google, Facebook, Twièr) ●  Handles authen6ca6on and provides iden6ty informa6on ●  Usually backed by LDAP, but could be something else, like AD (Ac6ve Directory) ●  Essen6ally, sohware that abstracts out the actual backend and translates user a`ributes to a standard

protocol format (SAML, OpenID Connect, etc.) ●  If you’ve ever used your Gmail account to sign into another

online applica6on… then you’ve used Google as the Iden6ty Provider and the other applica6on as the Service Provider

Use Case: -‐ Leverage new Federated Iden6ty -‐ An IdP already exists -‐ Non-‐LDAP iden6ty 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 ini6ally logging into Keystone or se]ng up service accounts for other OpenStack services

Token

Token

Password

Token ●  Users can exchange their exis6ng (valid) token for a newer token ●  Also sa6sfies the case where a user can receive an unscoped token (ini6ally), and exchange that for a

scoped token ●  Used by federa6on 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 valida6on

Use Case: If a user wants to start a VM, what is the full flow? 1.  Authen6cate 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 authoriza6on 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}�/ac;on) 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

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, iden6ty, image, orchestra6on, etc

Access Management Model in OpenStack How to determine if a user can perform an ac6on? ●  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}�/ac;on

definitions

targets rules

Identity Federation

Federated Identity ●  Users can exist in an iden6ty store that is not accessible by Keystone, or is owned by a different en6ty ●  Keystone federa6on allows for users iden6ty to be provided as a part of the authen6ca6on request

○  Iden6ty info is provided as environment variables ●  Keystone is protocol agnos6c, all federa6on protocol details are handled by Apache HTTPD modules

○  SAML -‐ mod_shib, mod_auth_mellon ○  OpenID Connect -‐ mod_auth_openidc

●  Terminology ○  Iden6ty Provider (IdP)

■  Trusted provider of iden6ty informa6on ○  Service Provider (SP)

■  Service that consumes iden6ty informa6on (Keystone) ○  Asser6on

■  Trusted representa6on of iden6ty a`ributes issued by IdP for consump6on by SP ■  If using SAML, the asser6on represents iden6ty a`ributes ■  If using OpenID Connect, the asser6on is a set of claims

Mapping Engine ●  Groups are created in Keystone's iden6ty backend for the purpose of role assignment

○  Mapping establishes group membership ●  Federa6on specific auth URL is used to obtain an unscoped token

○  Simply iden6fies user and groups ●  Unscoped federa6on token is used to obtain a scoped token

○  Contains group assigned roles

Federated Identity Flow





Single Sign-On ●  The most demanded Federa6on 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 agnos6c (supports SAML, OpenID Connect, Kerberos, etc.)

○  Keystone s6ll 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


●  When authen6cated with their Iden6ty Provider, the user will be logged into Horizon


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 ●  Federa6ng Iden66es from one deployment to another

○  Works almost iden6cally to the normal Federated Iden6ty Flow Except the origina;ng SAML IdP is another Keystone

○  Trust rela6onship between each deployment must be explicitly setup ○  Leverages Iden6ty Provider Ini6ated SAML

Flow: ●  User authen6cates with their own cloud ●  Exchanges token for an asser6on ●  Forwards the asser6on 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

Remote Cloud

A. Add Remote Cloud as a Service Provider

B. Add Local Cloud as an IdenJty Provider

One time setup performed by cloud admins

Local Cloud User

Future Plans

Future Plans ●  MFA -‐ Rackspace has proposed an MFA specifica6on that is in progress

○  Would be pluggable so vendors can implement their own MFA ●  Federated Iden6ty Enhancements (polish off rough edges from Federated Iden6ty Keynote)

○  Beèr client experience ○  Easier mapping rules

●  Authoriza6on Enforcement (Tokenless Auth)

○  Use X509 instead of passwords ○  No token needed (with X509) for interac6ng 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 mul6ple data centers and con6nents. This session will cover details of Keystone, what can be accomplished with it today, how OpenStack integrates with your enterprise iden6ty solu6on, federated iden6ty 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 ○  Iden6ty API vs Keystone ○  Scale of Keystone Deployments (1 vm to 1000s of physical machines)

●  Iden6ty Sources ○  Direct Connect (SQL, LDAP, Mul6ple Backends, SSSD) ○  Iden6ty Provider (IdP) ○  Use Cases

●  Authen6ca6on ○  Password ○  Token ○  External (Kerberos, x509, etc) ○  Mul6-‐Factor

●  Iden6ty Federa6on ○  Federa6on (SAML, OpenID Connect, ABFAB, etc) ○  Keystone2Keystone Iden6ty Federa6on ○  Web Single Sign-‐On

●  Access Management Model in OpenStack ○  RBAC ○  Authoriza6on ○  Endpoint Valida6on of AuthZ

●  Future Plans ○  Enhancements to Direct Iden6ty Sources ○  Federated Iden6ty ○  Authoriza6on Enforcement

●  Closing statements

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

SSSD ●  Available in a future release of OpenStack as an Iden6ty Source ●  Iden6ty informa6on lookup can be offloaded to the underlying plaxorm using SSSD ●  Eliminates the complexity of LDAP handling within Keystone ●  SSSD -‐ System Security Services Daemon

○  Provides access to remove authen6ca6on and iden6ty sources (FreeIPA, Ac6ve Directory, LDAP)

○  Support caching for high performance and fault tolerance ○  Supports failover for fault tolerance ○  Integrates via PAM, NSS, and DBUS

●  mod_lookup_iden6ty ○  Performs lookup of iden6ty a`ributes from SSSD via DBUS ○  Provides iden6ty a`ributes as environment variables to web applica6ons

●  mod_auth_* + mod_lookup_iden6ty looks exactly the same as federa6on from the perspec6ve of Keystone!

Multi-Factor Authentication ●  When knowing a password is not enough ●  These factors could be:

○  knowledge based (ques6ons) ○  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 iden6ty driver or via SSSD (federated LDAP) ○  HOTP/TOTP tokens (Yubikey, FreeOTP, Google Authen6cator)

●  Rackspace has proposed an MFA specifica6on that is in progress

○  Would be pluggable so vendors can implement their own MFA

Technology

CIS 2015- Building IAM for OpenStack- Steve Martinelli