Dolph: Thanks, this was tremendously helpful in understanding how things work. Putting this information into the docs is on my todo list.
Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On May 10, 2012, at 10:25 AM, Dolph Mathews wrote: > > > On Thu, May 10, 2012 at 9:00 AM, Lorin Hochstein <lo...@nimbisservices.com> > wrote: > Are there any documented examples out there of how to use roles? I still have > a hard time building a mental model of how the system works. In particular: > > Do I need to create a new role for every user-tenant pair? Or can I reuse > the same role? > > You can recycle roles. Role names are also unique. A "member" role is > frequently used in the docs, where you can grant membership to a user on a > specific tenant. > > Creating and granting this role to two users on different tenants using > keystoneclient looks something like: > > # create two tenants > $ keystone tenant-create --name="Tenant A" > <tenant-id-a> > $ keystone tenant-create --name="Tenant B" > <tenant-id-b> > > # create two users > $ keystone user-create --name="User A" > <user-id-a> > $ keystone user-create --name="User B" > <user-id-b> > > # create a membership role > $ keystone role-create --name=member > <role-id> > > # (Neither user can access either tenant at this point.) > > # grant User A membership on Tenant A > $ keystone user-role-add --role_id=<role-id> --tenant_id=<tenant-id-a> > --user_id=<user-id-a> > # User A is now a "member" of Tenant A. > # (User B still has access to nothing at this point.) > > # grant User B membership on Tenant B > $ keystone user-role-add --role_id=<role-id> --tenant_id=<tenant-id-b> > --user_id=<user-id-b> > # User B is now a "member" of Tenant B, but not Tenant A. > # (and User A is still a "member" of Tenant A, but not Tenant B.) > > > Where are the semantics of roles specified? What I mean is, what determines > what a role allows a user to do with a specific service? > > Right now, that's entirely managed by each service's policy.json -- keystone > does nothing but provide the role names to each OpenStack service. > > This will change a bit during folsom, with the introduction of RBAC (bp > https://blueprints.launchpad.net/keystone/+spec/rbac-keystone). The contents > of each service's policy.json will be centrally managed in keystone, and the > "meaning" of the roles a user has (the user's set of capabilities in the > current authentication context) will be provided to OpenStack services -- so > service's will no longer need to "understand" role names. > > The examples I see always create a magical "admin" role, but how does, say, > nova, know that this role is associated with admin privileges? Is it because > the label is "admin"? > > Today, this is configurable via Nova's policy.json: > https://github.com/openstack/nova/blob/master/etc/nova/policy.json > > What if I want to create a role that allows users in a tenant to have regular > access to nova, but not to swift? How do I do that? Do I need to create a > "novaUser" role? Where do I describe what a "novaUser" role means? In nova? > In keystone? How? > > See above; not sure about swift's status, though. > > > Pointer to an example here would be really helpful, would love to add this to > the docs. > > Let me know if you find the above useful; or feel free to revise and submit :) > > > > Take care, > > Lorin > -- > Lorin Hochstein > Lead Architect - Cloud Services > Nimbis Services, Inc. > www.nimbisservices.com > > > > > > On May 10, 2012, at 3:50 AM, Dolph Mathews wrote: > >> +1 >> >> The second "way to accomplish this" is exactly what keystone currently >> supports (explicit role grants), which didn't change between diablo and >> essex at all. >> >> The first method (using global unscopedness) was dropped because its just as >> confusing as you describe it. >> >> -Dolph Mathews >> >> On May 10, 2012, at 2:35 AM, Joseph Heck <he...@mac.com> wrote: >> >>> Guang, >>> >>> I think you need to re-read the code. The association between a user and >>> tenant is what the role represents, and its inaccurate to assert that a >>> user is aligned only with a single tenant ever, that is not the case. >>> >>> A role is no longer global, specifically to avoid the tremendous confusion >>> and inaccuracy of implementation about how to apply a role that relates a >>> tenant and user along with a potential "global" role concept that was in >>> the earliest implementations of Keystone. The current implementation is >>> simpler and far more specific and clear in it's implementation. >>> >>> -joe >>> >>> On May 9, 2012, at 10:22 PM, Yee, Guang wrote: >>>> I think this use case underscores one of the key differences between the >>>> fat Keystone (Diablo - E3) and KSL (Essex final). In fat Keystone, users >>>> and tenants are loosely coupled. They are bind together by role >>>> assignments. In KSL, users and tenants are tightly coupled, and IMHO very >>>> inflexible. Maybe the following example would further clarify this … >>>> >>>> Suppose you have tenants Dodgers, Giants, and Brewers, user Bud Selid, >>>> roles Commissioner and Minority Owner, and service MLB. And you want Bud >>>> Selid to have the Commissioner role for Dodgers, Giants, and Brewers, but >>>> Minority Owner role for Brewers only. >>>> >>>> In fat Keystone, there a couple of ways you can accomplish this. >>>> >>>> 1) Make Commissioner a “global role” (unscoped) and assign it to user >>>> Bud Selid. Assign the Minority Owner role to Bud Selid for tenant Brewers >>>> by creating a role reference. When Bud Selid tries to access MLB with his >>>> unscoped token, MLB will get his Commissioner role back from Keystone. >>>> When Bud Selid tries to access MLB with his token scoped to Brewers, MLB >>>> will get both his Commissioner and Minority Owner roles back from >>>> Keystone. When Bud Selid tries to acess MLB with his token scoped to >>>> Giants or Dodgers, MLB will only get his Commissioner role back from >>>> Keystone. >>>> 2) Assign the Commissioner role to Bud Selid to tenants Giants, >>>> Dodgers, and Brewers individually by creating the respective role >>>> references. Assign the Minority Owner role to Bud Selid for tenant Brewers >>>> by creating another role reference. In this scenario, Bud Selid will >>>> always need a scoped token to access MLB. >>>> >>>> In KSL, there really aren’t any effective ways to accomplish the same >>>> thing. Global roles are no longer supported. A given user must assign to >>>> exactly one tenant. I suppose you can have Bud Selid under the “Default >>>> Tenant”, and assign both Commissioner and Minority Owner roles to him. But >>>> there are two major side effects. >>>> >>>> 1) Bud Selid must access MLB with the token scoped to the “Default >>>> Tenant” in order for MLB to recognize him as Commissioner. Which means he >>>> IS ALSO the Minority Owner for Dodgers, Giants, and Brewers. J >>>> 2) If Bud Selid tries to access MLB with the token scoped to either >>>> Giants, Dodgers, or Brewers, his a NOBODY. J >>>> >>>> The upcoming Domains blueprint (to be implemented for Folsom), which >>>> offers true multitenancy, should support these types of use cases. >>>> >>>> https://blueprints.launchpad.net/keystone/+spec/keystone-domains >>>> >>>> With Domains, you can create a MLB domain with tenants Dodgers, Giants, >>>> and Brewers. And have Bud Selid under the MLB domain. Notice that users >>>> will no longer be assigned to tenants. They will be under a domain. Create >>>> roles Commissioner and Minority Owner in the MLB domain. Assign the >>>> Commissioner role to Bud Selid, and the Minority Owner role scoped to >>>> Brewers. Suppose you have another domain NFL, Bud Selid will not be able >>>> to access any tenants in the NFL domain, unless the NFL domain >>>> administrator explicitly assign NFL roles to Bud Selid. >>>> >>>> >>>> Guang >>>> >>>> >>>> >>>> >>>> From: openstack-bounces+guang.yee=hp....@lists.launchpad.net >>>> [mailto:openstack-bounces+guang.yee=hp....@lists.launchpad.net] On Behalf >>>> Of Dolph Mathews >>>> Sent: Wednesday, May 09, 2012 4:34 PM >>>> To: Joshua Harlow >>>> Cc: openstack >>>> Subject: Re: [Openstack] Keystone client, user belongs to many tenants? >>>> >>>> The user create command is actually creating discrete users, each with a >>>> "default tenant" reference. >>>> >>>> While that's fine for a lot of simple use cases, it doesn't directly >>>> support a user accessing multiple tenants at all. >>>> >>>> Instead, create a role, and grant that role to a user-tenant pair, >>>> creating an explicit relationship between the two. Using default tenants >>>> is optional with this method, but will affect how users must auth. >>>> >>>> -Dolph Mathews >>>> >>>> On May 9, 2012, at 3:46 PM, Joshua Harlow <harlo...@yahoo-inc.com> wrote: >>>> >>>> A question, >>>> >>>> I am using anvil to setup the keystone roles/users/tenants. >>>> >>>> It seems like the python keystone client has the following command: >>>> >>>> client.users.create >>>> >>>> Which seems to take in the following: >>>> >>>> create(self, name, password, email, tenant_id=None, enabled=True): >>>> >>>> I would assume a user name can be used in multiple tenants but when I am >>>> trying to create a user that spans tenants and it seems like it borks. >>>> >>>> ClientException: Conflict occurred attempting to store user. >>>> (IntegrityError) (1062, "Duplicate entry 'admin' for key 'name'") 'INSERT >>>> INTO user (id, name, extra) VALUES (%s, %s, %s)' >>>> ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin', '{"password": >>>> "$6$rounds=40000$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/", >>>> "enabled": true, "email": "ad...@example.com", "tenantId": >>>> "d1506184877a449a91fc6adcb553ad97"}') (HTTP 409) >>>> >>>> Is this supposed to happen? Is the client supposed to send back this much >>>> info also (hashed password??) :-P >>>> >>>> Any ideas? >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
