On 07/28/2011 04:58 PM, Dmitri Pal wrote:
On 07/27/2011 05:32 PM, Pete Zaitcev wrote:
On Wed, 27 Jul 2011 01:42:49 -0400 Scott Seagosseago@redhat.com wrote:
3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
Where can I find the specification for the "underlying permissions model"?
At this point, I rolled out an IWHD Authorization API design, based largely on what John transmitted verbally from various design meetings. When Dmitry saw my spec, he sent me a document that defined a "context" in such a way that is impossible to implement securely.
The context are essential IMO. You can't just discard it. Contexts/enviroments are a part of the real use cases (see Scott's original writeup) As I mentioned in the last section of the document (attached for reference) there is an option to make Conductor a front end to IWHD and not let direct user access to it. In this case IWHD should be counted as an internal component of the conductor IMO. The connection between the Conductor and IWHD can be based on server-to-server trust (SSL, GSSAPI, OAth - does not matter) This way the permissions would be stored as properties (tags) of the objects in the IWHD but controlled by the Conductor as it knows about environments and contexts. I was proposing it all along.
The alternative (if we insist to preserve the direct CLI to IWHD) is for IWHD to call back to Conductor on any operation to see if the user is allowed to perform an operation against the image that is currently tagged for a specific environment. Yes user would then provide the environment as a parameter but conductor would say if the user can do something or not via that call back.
John. We need to talk 2F2 about it. I am in the office on Tuesday. Would this work for you?
At the same time, the environment/context is not a part of the current conductor permissions model, as for the resources that we're currently managing, the combination of (user, resource, set of allowable actions) is sufficient. In areas where environment itself makes a difference in terms of of what actions are allowable, in some cases this means that the environment itself _is_ the resource/object that we're setting permissions on. In other cases, the effect of environment is not one of permissions but one of metadata/object associations.
For example, the 'dev' environment has a pool called "Aeolus development" and this environment is mapped to ec2 but not RHEV. That a user cannot launch an instance from Aeolus Development and deploy in RHEV isn't a permissions restriction, it's a data mapping restriction. It's not that the user doesn't have permission to launch dev instances in RHEV, it's that RHEV isn't mapped to dev at all -- even the site-wide admin can't launch an Aeolus development instance in RHEV, since it's not an allowable match. That the admin can't do it either indicates that it's not a permissions-driven restriction but based on something else.
I still haven't understood how images are so much different that they can't be handled with the same (user/resource/role) model as everyone else. I know we've had a long discussion thread in the past on this very subject, but from what I recall, it was inconclusive.
At the very least, I'd suggest that if IWHD permissions are going to be managed or enforced in any way by conductor directly (rather than simply passing requests along and letting IWHD handle it all, leaving conductor ignorant of how IWHD permissions work internally) we'd better keep the models consistent -- and only if we can reach a consensus on both the IWHD and Conductor sides to change our permissions model to add this fourth dimension should we do so here.
If IWHD is managing its own permissions and not relying on conductor to set or manage them, then I guess Conductor has less reason to worry about consistency here.
Scott
This has to be resolved before I set out to implement Auth/Auth in IWHD. E.g. declare "context" void and rejected, or plan to modify Kerberos to have identities that span realms and write a GSSAPI library that permits it, or other.
-- Pete