Open Stack

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