Open Stack

On Oct 10, 2012, at 7:11 AM, Eoghan Glynn <eglynn at redhat.com> 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"]],
> 
> (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).

Hey Eoghan, 

you're absolutely right - we don't have a nailed down mechanism to support this 
sort of thing, but I've been leaning towards using the PKI mechanisms to evolve 
into supporting signing a token so that we can write a policy rule that says "yeah, 
this request came from the user, and it was also approved/looked over by Service X
 (Heat, glance, whatever).

That policy mechanism extension would then be an "AND" around an 
"auth_token_signed_by" kind of thing.


> 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