Open Stack

On Wed, Oct 10, 2012 at 03:58:24PM -0400, Adam Young wrote:
> 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.

Just to clarify - there's no mechanism in keystone (currently) which
supports this "impersonates" concept, this is theoretical right?

So the way heat works at the moment is:
- USER creates a heat stack, template can define that keystone ec2
  credentials should be deployed on the instance
- heat creates a new keystone user INSTANCE_USER (whose name is defined in
  the template, this could be per-instance or per-stack depending on your
  template), in the same tenant as USER
- heat asks keystone for an ec2-credentials keypair for INSTANCE_USER
- ec2-credentials deployed to the instance (via cloud-init)
- API requests from inside the instance send the ec2 access key, and
  signature (signed using the ec2 private key)
- The heat API authenticates with keystone ec2tokens API, keystone returns a
  token if successful, in which case we process the request

The problem, which I'm still not 100% clear on, is how do we lock down
INSTANCE_USER such that it can access only specific services/endpoints?

Ideally we need to lock down the access such that INSTANCE_USER can only
perform a subset of API actions on a subset of the keystone authenticated
APIs, is there any method for doing this with the policy.json?  

If not then we can track the "instance users" inside heat and reject API
requests for non-whitelisted API actions (e.g we want ability to send
Cloudwatch metrics, but not to query them or manipulate alarms)

Adam - previously you mentioned putting the "instance users" in a separate
tenant (managed by heat), do you still see this as a good solution, or do
you think there is a viable way to lock down INSTANCE_USER inside the same
tenant as USER?

If possible, it would be much better (at least for the heat use-case) to
avoid putting all the INSTANCE_USERs into a separate tenant, since we divide
ownership of stacks (and instances, and cloudwatch metrics, etc, etc) on a
per-tenant basis, therefore it makes sense to group the "real" users and the
"instance" users in the same tenant.

-- 
Steve Hardy
Red Hat Engineering, Cloud