• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Spring 2012 state of project keystone
 

Spring 2012 state of project keystone

on

  • 1,223 views

 

Statistics

Views

Total Views
1,223
Views on SlideShare
1,220
Embed Views
3

Actions

Likes
1
Downloads
58
Comments
0

2 Embeds 3

http://coderwall.com 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Spring 2012 state of project keystone Spring 2012 state of project keystone Presentation Transcript

    • Friday, April 20, 12
    • OpenStack Identity State of the Project: Keystone Joe Heck Project Technical LeadFriday, April 20, 12
    • Who Am I Joe Heck choose to live @heckj here grew up hereFriday, April 20, 12
    • Outline ‣ Why keystone ‣ What is keystone ‣ Basic concepts ‣ High level architecture ‣ Essex release ‣ Folsom plansFriday, April 20, 12
    • Why Keystone ‣ the first “openstack common” ‣ common internal API expressing relevant identity information to OpenStack projects ‣ need for knowledge of OpenStack service endpointsFriday, April 20, 12
    • Keystone history ‣ protocols and mechanisms originally disparate in compute and object storage ‣ aggressively prototyped in Diablo release ‣ OpenStack internal token-based HTTP API ‣ administrative API ‣ consolidated in Essex release ‣ architecture shift to focus on independent drivers ‣ migrated to administrative CRUD operationsFriday, April 20, 12
    • What is Keystone ‣ single source of authentication, authorization ‣ same account and credentials for starting a VM instance and accessing a container in object storage ‣ means of expressing API endpoints ‣ basic service catalogFriday, April 20, 12
    • What is Keystone - core internal services ‣ identity ‣ policy ‣ token ‣ catalogFriday, April 20, 12
    • Basic Concepts - Identity ‣ Tenant == Project ‣ basic unit of ownership ‣ collection of resources (vm, volume, container, etc) ‣ User ‣ individual or service ‣ identified by basic credentials ‣ Role ‣ name relationship between a user and tenantFriday, April 20, 12
    • Basic Concepts - Policy ‣ Policy file - private/internal in Essex ‣ Nova, Glance, and Keystone ‣ Simple rule based mechanism for expressing authorization ‣ Enforcement at the servicesFriday, April 20, 12
    • Basic Concepts - Token ‣ Token ‣ arbitrary string to be used in HTTP headers ‣ identity associated with token retrievable by other OpenStack services ‣ token ‣ user, tenant, roles ‣ catalogFriday, April 20, 12
    • Basic Concepts - Catalog ‣ service --> endpoint ‣ OpenStack Services ‣ identity ‣ compute ‣ volume ‣ image ‣ ec2 ‣ object-storeFriday, April 20, 12
    • HTTP_X_AUTH_TOKEN: 87d45c4c6e9b445997da68f399b49704 ‣ {uaccess: {userviceCatalog: [{uendpoints: [{uadminURL: uhttp://vol:8776/v1/c566cb3adfab4f4a859250f4f7d4f56c, uinternalURL: uhttp://vol:8776/v1/c566cb3adfab4f4a859250f4f7d4f56c, upublicURL: uhttp://vol:8776/v1/c566cb3adfab4f4a859250f4f7d4f56c, uregion: uRegionOne}], uendpoints_links: [], uname: uVolume Service, utype: uvolume}, {uendpoints: [{uadminURL: uhttp://image:9292/v1, uinternalURL: uhttp://image:9292/v1, upublicURL: uhttp://image:9292/v1, uregion: uRegionOne}], uendpoints_links: [], uname: uImage Service, utype: uimage}, ... ... ... {uendpoints: [{uadminURL: uhttp://ident:35357/v2.0, uinternalURL: uhttp://ident:5000/v2.0, upublicURL: uhttp://ident:5000/v2.0, uregion: uRegionOne}], uendpoints_links: [], uname: uIdentity Service, utype: uidentity}], utoken: {uexpires: u2012-04-19T00:06:53Z, uid: u87d45c4c6e9b445997da68f399b49704, utenant: {udescription: None, uenabled: True, uid: uc566cb3adfab4f4a859250f4f7d4f56c, uname: udemo}}, uuser: {uid: u30e5d97149cf4621b9dbeb7681917aed, uname: ufrank, uroles: [{uid: u089c23c4f82f4c9d8882f6919dd51103, uname: uAdmin}, {uid: uda104b278a2b463e89dd5e072740702e, uname: uMember}], uroles_links: [], uusername: ufrank}}}Friday, April 20, 12
    • High Level Architecture ‣ Typical OpenStack Pattern ‣ WSGI Application, configured with Paste ‣ URI routes mapped to configurable backends ‣ Configurable backends per internal service: ‣ SQL ‣ LDAP ‣ key-value store ‣ ...yours...Friday, April 20, 12
    • High Level Architecture ‣ operational facade to existing systems ‣ identity ‣ token ‣ policy ‣ catalogFriday, April 20, 12
    • Essex Backends ‣ Identity ‣ SQL, LDAP, PAM, KeyValue ‣ Catalog ‣ SQL, Template, KeyValue ‣ Token ‣ SQL, Memcache, KeyValue ‣ Policy ‣ RulesFriday, April 20, 12
    • Essex Release ‣ API Stability ‣ architecture reset - maintained Diablo API compatibility ‣ functional test driven ‣ “auth_token” middleware - rewritten ‣ Operational Focus ‣ Additional logging ‣ Basic RBAC “policy” (nova, glance, keystone)Friday, April 20, 12
    • Folsom Plans ‣ theme: steady, stable, tested ‣ careful, thoughtful improvement ‣ keep core simple, stable ‣ continued focus on integration tests and stabilityFriday, April 20, 12
    • Folsom Plans ‣ iterate forward on API ‣ Identity ‣ domain (collections of tenants) ‣ additional backends (ldap to Active Directory) ‣ authentication enhancements ‣ PKI support ‣ multi-factor supportFriday, April 20, 12
    • finiFriday, April 20, 12