[openstack-dev] [keystone] on-behalf-of proxy identities for applications running in-instance

Adam Young ayoung at redhat.com
Wed Oct 10 19:58:24 UTC 2012


On 10/10/2012 03:01 PM, Eoghan Glynn wrote:
>>> So the piece I'm missing is how the capabilities of WORKER can be
>>> constrained to be a small subset of REAL's capabilities, without
>>> lots of admin intervention.
>>>
>>> In the example above, if we want WORKER to be allowed to do live
>>> migration, but not any other admin actions, then we'd need to
>>> extend nova's policy.json file changing:
>>>
>>>     "compute_extension:admin_actions:migrateLive":
>>>     [["rule:admin_api"]]
>>>
>>> to something like:
>>>
>>>     "compute_extension:admin_actions:migrateLive":
>>>     [["rule:admin_api"],
>>>                                                     ["role:WORKER_ROLE"]],
>> I'm still thinking this through, but I think it would be more correct
>> for this to be done as REAL.
>>
>>
>> Heat's WORKER does a request to Keystone to get a token for REAL.
>> This
>> token would be preauthenticated by REAL.  Then the calls to nova
>> would
>> be done using REAL's token.
>>
>> It would be up to REAL to limit the exposure.  She might make two
>> accounts.  REAL and REAL_LIMITED,  where the REAL-LIMITED account
>> would
>> have the appropriate Role.  That way,  Heat could only perform those
>> actions available to the REAL_LIMITED account, and not the whole REAL
>> account.  WORKER might need to do some general purpose actions that
>> don't have to be tracked to any particular user, and only those would
>> be
>> done using a WORKER token.
> I'm not sure I get why it would be better to have both WORKER *and*
> REAL_LIMITED as proxy identities, could the one not subsume the other?
>
> Cheers,
> Eoghan
>

WORKER is a user account owned by the Heat service.
REAL_LIMITED is owned by REAL.

WORKER does the work for HEAT.  It impersonates REAL_LIMITED when it 
needs to do work for REAL.  It impersonates eglynn_limited when it needs 
to do work for you.






More information about the OpenStack-dev mailing list