openstack team mailing list archive

[Duncan McGreggor <duncan@xxxxxxxxxxxxx>]

Hey guys,

Just wanted to say that I'm deep, deep into some Keystone right now
(auth'ing against DreamHost's existing infrastructure and granting
access to  tenants, etc.) and this email just saved me about a week of
work :-)

Thanks!

d

On Thu, May 10, 2012 at 10:25 AM, Dolph Mathews <dolph.mathews@xxxxxxxxx> wrote:
>
>
> On Thu, May 10, 2012 at 9:00 AM, Lorin Hochstein <lorin@xxxxxxxxxxxxxxxxxx>
> 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 <heckj@xxxxxxx> 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.com@xxxxxxxxxxxxxxxxxxx
>> [mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] 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 <harlowja@xxxxxxxxxxxxx> 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": "admin@xxxxxxxxxxx", "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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>