Open Stack

On 10/10/2012 10:11 AM, Eoghan Glynn wrote:
>
>> On 10/10/2012 06:26 AM, Eoghan Glynn wrote:
>>> Folks,
>>>
>>> One to think about in advance of any keystone roadmap discussions
>>> at the summit ...
>>>
>>> As we build out the infrastructure, it's likely there will be more
>>> and more cases where applications running on instances will need
>>> to access openstack services securely (for example to use a
>>> notification, or queueing, or metrics service).
>> So this was along the lines of what I discussed with the Heat team.
>> When
>> heat runs, it is going to run as a specific user, and, more
>> importantly, in a constrained project (tenant).
>> I could see using the project as the analogue for the end-point, and
>> then the "constrained user" is a user with a constrained role within
>> a
>> project.
>>
>> I could see a setup where, for High Availability (HA),  there is a
>> project for the set of resources assigned to the HA grouping.  Then,
>> a worker user account has limited abilities within that project:
>> migrate VM from one machine to another.  In addition, that same worker user
>> account is granted some minimal role inside the project that owns the
>> virtual machine.  Lets call that user account WORKER and the real
>> person originator REAL.    REAL then would create a pre-auth  for WORKER.
>> If some action needs to be done by WORKER as REAL,  WORKER makes a call
>> to Keystone to get a token associated with the pre-auth.
> Thanks for the response Adam,
>
> 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.


>
> (excuse the possibly wrong syntax there) and then role that change out
> across the fleet of nova-api hosts. Unless we pre-annotate the policy.json
> with lots of fine-grained roles, one per action or small group of related
> actions.
>
> Also I'm not sure how we could recover the original identity (REAL) from
> the on-behalf-of proxy (WORKER).
>
> Cheers,
> Eoghan
>
>>> It would be great if keystone provided support for provisioning
>>> some form of proxy identity to instances that would allow the apps
>>> running in-instance to make API calls on behalf of the instance
>>> owner, within some constraints (on the services that may be invoked
>>> on).
>>>
>>> Similar, basically, to the flexibility that AWS IAM roles provide
>>> currently.
>>>
>>> I don't know if this is even feasible within the current set of
>>> keystone capabilities and the fairly static policy.json setup.
>>> However, if it is do-able, it might be a good feature to discuss
>>> for future roadmap consideration.
>>>
>>> Cheers,
>>> Eoghan
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev