CIS13: OpenStack API Security

© 2012 IBM Corporation

OpenStack Security Update for CIS 2013 Henry Nash OpenStack Keystone Core Committer IBM (CSI) OpenStack Tech Lead [email protected]

© 2012 IBM Corporation 2

Agenda

•  What is OpenStack and who is adopting it? •  Introduction to OpenStack and its API flow •  API protection in Openstack •  What’s coming next in OpenStack


Agenda



The OpenStack Goal

“Our goal is to produce the ubiquitous Open Source cloud computing platform that will meet the needs of public and

private cloud providers regardless of size, by being simple to implement and massively scalable.”

•  Open Source (Apache 2.0 license) •  “Linux of the datacentre”, avoid vendor lock-in, maintain

workload portability •  Build a great engine, packagers will build a great car (think

Linux vs RHEL/SUSW)


History and Releases

•  Founded in 2010 as an opensource project by Rackspace and NASA •  Now managed by an open foundation •  7 releases so far, bi-yearly

• Most common release in production: Folsom (09/2012) •  Latest release: Grizzly (04/2013) • Next release: Havana (09/2013)

•  Each release à new version of the existing core projects à new core projects are released à overall architectural picture might change


OpenStack is a global collaboration of developers & cloud computing technologists working to produce an ubiquitous Infrastructure as a Service (IaaS) open source cloud computing platform for public & private clouds.

Community with exponential growth EC

OSY

STEM

SIZ

E

CUMULATIVE CONTRIBUTORS

AVG MONTHLYCONTRIBUTORS PATCHES MERGED IN Q4 2012

859 238 3,241

165Companies

8,204 Individual Members

INDI

VIDU

ALS


Who’s using OpenStack?

7


PayPal Uses OpenStack

•  Processed more than $26,000 in mobile payments every minute in 2012

•  OpenStack runs thousands of VMs to support their self-service developer model

•  Internal team manages deployment and operations, using OpenStack Compute, Storage & Shared Services

“We needed agility without sacrificing availability. By leveraging the collective

innovation of the OpenStack community, we can develop and grow our private cloud

much quicker without having to reinvent anything.”

Saran Mandair, senior director of PayPal infrastructure engineering


CERN Uses OpenStack

•  Large Hardron Collider tracks 4 million collisions/sec, out of which it selects 200 complex images to store/sec

•  Building out a 50,000 core OpenStack farm to handle

“We record 40 Mbytes per second each 6 months,

adding to the currently store of around 140 PB today”

Randall Sonie, research scientist, University of Victoria


Why are IBM involved? It’s the right model: •  For companies to truly bet their business on

cloud, it has to be open •  Hypervisor agnosticism allows best choice

of virtualization technology for the task (and likely more than one choice needed) •  An IaaS that enables the hypervisor owners

to maintain the currency of support for their hypervisor

It enables easier delivery of the higher

value components and services: •  Deployment and lifecycle management of

middleware and application patterns •  Image lifecycle management •  Orchestration

•  IBM Products where you can see this in action already: •  SmartCloud Orchestrator

Orchestration Services

Platform Level Services

Ope

ratio

nal E

xten

sion

s (A

PIs

) Infrastructure Level Services

Dev

elop

men

t Ext

ensi

ons

(Too

ling)

(Image Lifecycle Mgmt) (Pattern Services)

(Provisioning, configuration, resource allocation, security, metering, etc.)

Cloud Resources

Storage Compute Network

http://www-03.ibm.com/software/products/us/en/smartcloud-orchestrator/


Agenda



OpenStack Cloud Platform

Code available under Apache 2.0 license. Design tenets – scale & elasticity, share nothing & distribute everything


Openstack projects – conceptual architecture

nova Compute

swift Object Store

glance Image Library

cinder Block Storage

keystone Identity

horizon Dashboard

quantum Network

use authentication service via API

• Provides sample UI • Reference implementation of API usage

use API to store image

files

use API to manage images

use API for volumes for instances

use API for network connectivity for instances

IaaS

New with Folsom release


Agenda



OpenStack API Protection – Summary View


OpenStack Tokens

§  These are “bearer” tokens §  i.e. “if you have one, I won’t ask how you got it and will honor it”

§  Obtained by asking keystone for a certain “scope” § e.g. “Get me a token for working with project X”

§  Expiration set by system (default 24 hours) § …making this a small number (e.g. minutes) doesn’t work well

§  Can be revoked if things change § e.g. user is disabled, roles are unassigned

§  Can be encrypted (pki) and stored client side to save server round trips for token validation §  Recommended for performance


OpenStack Roles & Assignments

§  “Roles” are simply names that are globally unique (within a keystone instance) § They are the “shared secret” between a role-assignment in keystone

and a rule in the policy files owned by each of the projects

§  “Role assignments” (use to be called “grants”) are what gives a user a role on a target object § e.g. Give “Henry” the role “Tea-maker” on project “Test” § Only two object types supported – domains and projects § Role assignments always have a target object

§ i.e. you can’t just say: Give “Henry” the role “Tea-maker” § The is no generic “super user” role that you can give a user

§ …although individual projects have their own way of providing some kind of by-pass to API protection


OpenStack Domains and Projects

§  “Projects” encapsulate a set of infrastructure resources § e.g. images, storage, VMs etc. §  In earlier versions of OpenStack users were (sort of) members of

projects

§  “Domains” are an administrative encapsulation §  i.e. users, groups and projects § Often mapped to a customer in a public or shared private cloud § Only Keystone is really domain-aware

§ …although this might change in the future (e.g. images that are domain-wide)

§ Domains only supported from Grizzly release onwards


API Protection - Guidelines

§  Two classes of APIs to protect § Regular projects (nova, glance, cinder etc.) § Keystone identity administration § Both use roles and policy files

§ One policy file per project (including keystone)

§  Two types of cloud operational models § Central control – where all admin is done by cloud provider § Delegated control – where you want to delegate some of the

management § E.g. the owner of a domain can manage their own users and groups


API Protection – Guidelines – Policy File is Key

"admin_required": [["role:admin"], ["is_admin:1"]], "owner" : [["user_id:%(user_id)s"]], ”member" : [[”project_id:%(project_id)s"]], "admin_or_owner": [["rule:admin_required"], ["rule:owner"]], "admin_or_member": [["rule:admin_required"], ["rule:member"]], "identity:get_domain": [["rule:admin_required"]], "identity:list_domains": [["rule:admin_required"]], "identity:create_domain": [["rule:admin_required"]], "identity:update_domain": [["rule:admin_required"]], "identity:delete_domain": [["rule:admin_required"]], "identity:get_project": [["rule:admin_or_membe"]], "identity:list_projects": [["rule:admin_required"]], "identity:list_user_projects": [["rule:admin_or_owner"]], …… …..

Example extract from a simple, central control, keystone policy file


API Protection – Guidelines – Policy Files

§  Delegated Control involves more complex planning and subsequent rules in the policy file § Most delegated rules center around use of domain_id, e.g. "identity:create_project": [["rule:admin_required"],[“domain_id”%(project.domain_id)],

§  However, reality is that Grizzly has a number of holes in its ability to easily delegate management § Policy checking can only compare what’s in the token with what’s in the

API call § Works well for creating object § Doesn’t work for, say, deleting an object – since there is no domain_id referenced in the API call § Improvements coming in Havana….


Agenda



What’s coming in Havana (no guarantees…)

§  Token Provider Interface § Let’s companies use their own token generators, although within the

same keystone API constructs

§  OAuth2 Delegation Extension § Use OAuth2 to allow a consumer delegation of particular roles on

behalf of a user

§  Keystone identity backend split § Store your users & groups in a corporate LDAP, but your role-

assignments somewhere else (e.g. Keystone SQL)

§  Projects can inherit roles from domain (Extension) § Designed to better support the management split between cloud

provide administrator (who sets up domains) and customer administrator (who manages within a domain)


What’s coming in Havana (no guarantees…)

§  Enhanced policy file capabilities for keystone § Allows check on target of operation (e.g. useful for update/delete

operations) § Enables true separation of management between cloud provider and a

domain administrator

© 2012 IBM Corporation

OpenStack Security Update for CIS 2013 Henry Nash OpenStack Keystone Core Committer IBM (CSI) OpenStack Tech Lead [email protected]

CIS13: OpenStack API Security

Technology

Transcript of CIS13: OpenStack API Security