Open Stack

On Thu, May 10, 2012 at 9:00 AM, Lorin Hochstein
<lorin at 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 <heckj at 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.com at lists.launchpad.net [mailto:
> openstack-bounces+guang.yee=hp.com at 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 <harlowja at 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": "admin at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp****
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120510/2f3a340e/attachment.html>