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 Seago<sseago(a)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