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
