Open Stack

On 5/3/13 12:02 PM, "Nate Reller" <rellerreller at yahoo.com> wrote:


>> >How are the tenant IDs populated in the database?
>> 
>> Our current plan is to silently create the tenant_id once the user's
>>first
>> call has validated against keystone. E.g. If you have our endpoint in
>> keystone, we'll create the tenant. The tenant_id is going to just be a
>> varchar with the data from keystone since, IIRC, the OpenStack provider
>> can use any values for tenant_ids so we can't rely on any particular
>> format.
>
>I was wondering how you were going to do that. The tenant ID is going to
>initially be used to validate who can use a key? For volume encryption I
>will 
>need to make sure I can use the same tenant ID for both. Ideally I would
>use
>the user's tenant ID, but this could be a problem if I cannot get access
>to it
>for both the creation and retrieval of the key.

Yeah, this is still something we need to vet. The idea would be that the
key would reside under the customer's tenant. This would mean that cinder
and nova would have to:

(a) Auth with keystone with service credentials and pass the tenant to us
during the create / retrieve calls. This is not ideal as it means that
Barbican has to extend a lot of trust to nova and cinder.

(b) Pass the user's token as part of the create / retrieve calls. I don't
think this is possible right now as these calls are async, at least on the
nova side.

(c) Auth with service credentials to impersonate the user. This would be
the best option IMO.

Initially, we'll only use the tenant id to validate key access. Later,
we're going to use some delegation logic (e.g. Only these services, not
these, etc).

>Thanks for clearing up the content-types questions. That makes sense to
>me. Do
>you know if it will be a list or a map?

I think the current plan is a map.




Jarret