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

Adam Young ayoung at redhat.com
Wed Oct 10 12:37:44 UTC 2012


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.

>
> 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




More information about the OpenStack-dev mailing list