Open Stack

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

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
>