openstack team mailing list archive

[Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>]

Hi Joe - Here are some additional responses and comments inlineŠ


On 10/25/11 3:48 PM, "Joseph Heck" <heckj@xxxxxx> wrote:

>
>On Oct 25, 2011, at 12:54 PM, Jesse Andrews wrote:
>
>> I'm not an expert ... adding some comments
>> 
>> On Tue, Oct 25, 2011 at 12:05 PM, Joseph Heck <heckj@xxxxxx> wrote:
>>> I've just dropped in place a bunch of developer documentation (RST) for
>>> Keystone - one in, one pending
>>>(https://review.openstack.org/#change,1089).
>>> Making these docs  brought up a number of questions that I wasn't able
>>>to
>>> answer. I want to put more context around the commands and concepts
>>>for the
>>> reader prior to updating the docbook documentaiton. Joe Savak
>>>suggested on
>>> IRC that I just drop them out here to the list, so here goes:
>>> If any of these are "just bugs", let me know and I'll file them.
>>> 
>>> Q: Why is an administrative service token bound to a tenant?
>>> Right now, keystone-manage to create an administrative service token,
>>>the
>>> token which in turn is configured into nova, swift, glance, and
>>>dashboard,
>>> requires a tenant - but as I understand tenant that doesn't make sense
>>>- as
>>> the various services all serve more than one tenant.
>> 
>> we create a tenant for services and then create the long lived
>>validation for
>
>missed some of this.... create long lived validation for what?

The use case is to provide long-lived tokens (or credentials) for services
to use when they call the privileged admin API calls (like Validate
Token). There are two ways this is done today:
1. We put a long lived token in Keystone directly using keystone-manage
and then place that token in the config file for the middleware. The
middleware then uses that to make the calls.
2. You can use certificates based on the work Liem and HO did in the
2-way-ssl blueprint.

ButŠ this does not answer your original question! You actually shouldn't
need a tenant for the admin service token. One side effect of not putting
in a tenant might be what Sandy Walsh has been raising that you don't get
endpoints. And nova client uses the endpoints to discover the URLs for
nova. We'll be working on this and I filed a bug:
https://bugs.launchpad.net/keystone/+bug/887877


>
>>> Q: How do you remove a service?
>> 
>> You can invalidate the token - which means the service can no longer
>> validate user tokens
>> You can remove the service from the catalog
>
>Is there an API for removing the service from the catalog? There isn't a
>keystone-manage command for it (that I found)

It would be implemented also under DELETE /v2.0/OS-KSADM/services call. We
intentionally left this one out for now until we have time to build the
right safeguards in place. Deleting a service could be huge, and
catastrophic.

>
>>> Q: How do you remove an EndpointTemplate?
>> 
>> not sure through the api, but can you via keystone-manage?  If not you
>> can remove via the database.
>
>I think that's direct database manipulation then. Ziad/Dolph/Yogi - can
>you confirm? Should be a bug?

Same as deleting a service. We avoided solving the data consistency
implications in the focus on getting Diablo out. We'll need to go back and
fill it in. For now, it's a direct database operation (the good thing
about that is that hopefully someone who knows the system intimately will
be doing thatŠ)

>
>>> Q: What's the purpose of a "role" prior to RBAC
>>> Is it really just relevant for the Keystone administrative API, but
>>>more
>>> coming online later with the RBAC work? Does any role based link
>>>between a
>>> user and a tenant allow that user to get a scoped token for that
>>>tenant?
>> 
>> Currently as specified a token validation can return roles, which then
>> can allow services to implement rbac.  The session on "can haz" was
>> talking about how nova can do that without any changes in keystone.
>
>Ziad/Yogi/Dolph - is there anything that role does *today* (i.e. Diablo
>release) other than authorizing access to the Keystone Admin API?

Roles can be used for RBAC today. Using Keystone for simple RBAC can be
done with roles today (it would support the model that existed in Nova).
The list of capabilities a role has would be stored in Nova.

The RBAC work for Essex will expand on that and allow Keystone to store
and manage capabilities and dashboard to manage them through a REST API.


>
>>> Q: How do you remove a role?
>> 
>> Not sure how to - I think this should be another extension since in an
>> enterprise deployment the roles would be set by mapping ldap/ad groups
>> into roles
>
>Missing? Should be a bug?

Yes. Should be there. Not left out intentionallyŠ bug


>
>>> Q: What's the keystone-manage command for "credential add" do? There's
>>>also
>>> no corresponding delete or disable - is this password update for the
>>> passwords that are set on "keystone-manage user add"? If not, how are
>>>those
>>> passwords updated?
>>> Q: What are "type" and "key" as related to "credential add" command,
>>>and
>>> what are they intended to do?
>>> Q: Why isn't there a "user delete" and a "tenant delete"? Is this a
>>>"just
>>> haven't gotten to it yet" bug?
>> 
>> Those should probably be in the user/tenant extension.  Not sure if
>> they are there or not.


Did Vish cover this well enough? His answers were spot on and accurate.
Also consider the use case where users can use certificates as credentials
(and there may be more than one per user).


>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp