Image permissions, round 2

Mark McLoughlin markmc at redhat.com
Tue Jun 7 09:08:20 UTC 2011


On Thu, 2011-06-02 at 10:47 -0400, Scott Seago wrote:
> On 06/02/2011 09:48 AM, Mark McLoughlin wrote:
> > = 1. Access Control =
> >
> > There was general consensus that we need something akin to posix
> > filesystem permissions on IWHD objects. The use cases driving this are:
> >
> >   a) I build an image that contains sensitive data - e.g. private keys,
> >      DB passwords in config files etc. - and I want to limit who can read
> >      that data from IWHD.
> >
> >   b) I want to prevent others from deleting or overwriting my image data,
> >      or even just the metadata on objects that I created.
> >
> > This implies that we need read and write/delete permission on all
> > objects in the warehouse. Read permissions apply only the object
> > contents, but write permissions apply both to the contents and the
> > metadata.
> >
> Ideally we'd want read permissions enforced on metadata too -- so that a 
> call to "return all images" only returns those images on which the user 
> has permission to see.

Yeah, probably.

> > We obviously need the concept of permissions that apply to individual
> > users, as well as a 'world' permission that applies to everyone. For
> > large organizations, group permissions will also be needed.
> >
> > In order to enforce user permissions, we clearly need to authenticate
> > users. We probably need to support three different authentication modes:
> >
> >    i) For standalone usage of IWHD, a simple user/password database.
> >       Perhaps just keep this in Mongo.
> >
> >   ii) When use with Conductor, IWHD should be able to authenticate using
> >       Conductor's REST API - i.e. in IWHD config, allow an "HTTP
> >       authentication URL" to be specified which IWHD will do Basic HTTP
> >       authentication against.
> >
> > iii) For use with Conductor where Conducor isn't using its own DB as its
> >       user store (perhaps it is using IPA, LDAP or even just the
> >       local /etc/passwd), IWHD should be able to authenticate using PAM.
> >
> > Permissions will be represented by metadata tags on object, each of
> > which can either contain "rw" or "r":
> >
> What about "x", where "x" grants a user the right to launch an instance 
> from it? i.e. Someone may have permission to view an image but not to 
> launch an instance using it?
> Clearly in this case IWHD's enforcement is only indirect, since once the 
> calling client has the ID for the provider image, a deltacloud call will 
> launch it, but it might be useful for query purposes. i.e. having an API 
> call to return a list of those images that the user has permission to 
> launch (as opposed to merely the permission to read).

Right, having the launch permission on an image will be useful to
conductor ... but this would be a metadata tag which is opaque to IWHD.

It doesn't make to include the launch permission in the set of
permissions understood by IWHD ... because it doesn't understand the
permission.

> >    user-permission:<user-id>
> >    group-permission:<group-id>
> >    world-permission
> >
> > The aeolus-image CLI will be responsible for managing the permissions
> > tags:
> >
> >    $>  aeolus-image build -t ec2 -e my.tmpl
> >    ...
> >    Built image: 2d134860-9762-4cc3-8e63-4fab7d31ad1b
> >    $>  aeolus-image info -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b
> >    ...
> >    user-permission-markmc: rw
> >    ...
> >    $>  aeolus-image user-permission -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b jrd rw
> >    $>  aeolus-image group-permission -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b dev rw
> >    $>  aeolus-image world-permission -i  2d134860-9762-4cc3-8e63-4fab7d31ad1b r
> >    $>  aeolus-image user-permission -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b --delete jrd
> >
> > Open questions:
> >
> >   - Should read permissions apply to object metadata? This probably makes
> >     sense, but we need to think about whether we can implement that
> >     without massively slowing down queries.
> >
> Conductor already has to filter all queries based on user permissions. 
> Will it be any worse for IWHD to do the same?

Fair point.

> >   - Permissions on buckets - I don't think we need these. We are storing
> >     all our objects in single buckets, so it's hard to see what we would
> >     use these for. In any case, if we want to limit the ability of users
> >     to create objects, then bucket permissions are probably the way to
> >     go.
> >
> >   - Does Conductor authenticate as the Conductor user when talking to
> >     IWHD?
> >
> >   - No need for a "w" permission, right? i.e. granting the permission to
> >     write without the permission to read?
> >
> >   - The "rw" permission grants the user permission to delete the object.
> >
> - Are permissions only stored on images? i.e. we don't track separate 
> permissions on a per-build, per-provider image, etc basis? I'd think 
> we'd want to manage permissions only on top-level image objects unless 
> we have a clear use case  that requires more granular control.

IWHD would have permissions on all objects. It doesn't differentiate
between objects

> - What about 'create' permissions? i.e. who has permission to create and 
> build images? Or will this be handled exclusively via the 'quota' 
> mechanism (rather than permissions) -- i.e. if your quota is '0' you 
> can't create/build.

The only create permission that makes much sense to me for IWHD is a
write permission on buckets

> > = 2. Environment Policy =
> >
> > Images are assumed to undergo a lifecycle where one version of the image
> > may be in production, another in staging and another in development.
> >
> > These lifecycle phases are exposed to the user as environments in
> > Conductor. Some images may only be available in development or you may
> > may only have specific builds of an image available in each of the
> > environments.
> >
> > The image administrator defines this policy - i.e. which environments
> > the image is allowed in, and which version of an image is appropriate
> > for each environment - using the aeolus-image CLI which, in turn, sets
> > metadata tags on IWHD objects to represent the policy.
> >
> > When a user launches a deployable, or explicitly chooses an image to
> > launch, Conductor enforces the policy by comparing the environment the
> > user is launching the deployable/instance in to the the metadata tags.
> >
> > The metadata tags defining this policy are place on "image" objects in
> > iwhd and are simply:
> >
> >    latest_build:<environment>  = build UUID
> >    latest_build = build UUID
> >
> Do we need an explicit latest_build tag, or can the API just grab the 
> most recent build for an image (optionally filtered by tag)?

Which API do you mean?

Remember, these tags are opaque to IWHD

> > The policy is enforced as follows:
> >
> >    - When launching a deployable in an environment, Conductor resolves an
> >      image reference to a set of provider images by first looking at the
> >      environment specific latest_build tag. If this doesn't exist, it
> >      looks at the global latest_build tag. If this doesn't exist, the
> >      deployable can't be launched
> >
> >    - When listing images available to be launched in a given environment,
> >      Conductor searches for all images with either an environment
> >      specific or global latest_build.
> >
> So I had envisioned something slightly different. The problem with 
> managing environment-specific builds with only the 'latest_build' tag is 
> that you don't have a way of limiting usage per environment when the 
> deployable specifies a particular build.

Well, there are a couple of things to consider here:

  1) Do we want to a) make it impossible for users to run an unapproved
     build in an environment, or do we want to b) just make the default 
     workflow such that they run approved builds but they can force an
     unapproved choice if they wish

  2) Even if we want 1.a), do we make this an administrator policy 
     decision (i.e. don't allow versioned image references) or do we 
     want to make 1.b) impossible no matter what the configuration

IMHO, 1.a) is plausible enterprise deployment policy, but 1.b) is useful
for less locked down environments

Summary: I think we just need a "don't allow versioned image references"
policy for administrators to configure

>  Would it make more sense to, 
> instead of using latest_build tags, tag each build with the list of 
> allowable environments? If the build has no env tags, then it's 
> available for all environments. Then "latest build for $foo_environment" 
> is determined by filtering the build list for an image, omitting any 
> builds which:
> 1) have at least one environment tag
> 2) do _not_ have a tag for $foo_environment

A few problems:

  1) IWHD doesn't (yet? easily?) do lists as metadata values

  2) It becomes harder to resolve a versionless image reference to a 
     specific build - you get the list of builds and you have to decide 
     which one is the latest build for the environment

  3) You can no longer restrict the ability to add a build to an 
     environment by restricting the permissions on the image object

> > The image building CLI for this might look like:
> >
> >    $>  aeolus-image build -t ec2 -e my.tmpl -i -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b
> >    ...
> >    Rebuilding image: -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b
> >    New build: 54848312-2d3e-405e-ac34-0c67bba22ee8
> >    $>  aeolus-image add-env -i 2d134860-9762-4cc3-8e63-4fab7d31ad1b --env prod -b 54848312-2d3e-405e-ac34-0c67bba22ee8
> >    Set latest_build:prod = 54848312-2d3e-405e-ac34-0c67bba22ee8 on image 2d134860-9762-4cc3-8e63-4fab7d31ad1b
> >
> > Note that these commands could be run by two users with different roles.
> > The first user may only have permission to rebuild images, whereas the
> > second user would be the only one that could update the latest_build tag
> > on the image object.
> >
> > Open questions:
> >
> >   - There was discussion about whether the environment a user is in
> >     should translate to access control permissions in IWHD - i.e. unless
> >     I have been added to the development environment, not only should I
> >     not be able to launch an instance using development images, but I
> >     also should automatically not be able to see them using the CLI.
> >
> Yeah I don't think we need to explicitly add users to environments here. 
> This is handled by permissions/policy on conductor already. In 
> conductor, each pool belongs to a single environment. If we do not 
> intend to allow a user to access the development environment, then we 
> simply do not add this user to any of the development pools. So the 
> user-environment permissions are handled by granting users explicit 
> permissions to launch deployments in (environment-specific) pools

Yeah, but this still means that which environments the user has been
added to (by adding her to pools) does not influence her read/write
permissions at an IWHD level.

But again, I'm not sure what the important use case is here.

> >     The implication here is that there would be a group visible to IWHD
> >     for each environment which represents all the users added to the
> >     environment. In the case of a shared identity store like IPA, this is
> >     doable by having Conductor manage the group membership of the
> >     environment groups. In the absence of a shared identity store,
> >     perhaps we leave it up to the admin to set up these groups if they
> >     so wish.
> >
> >     All that being said, I'm really struggling to convince myself that
> >     this is terribly important. Given that so much of the discussion got
> >     wedged on how to do this, I'd suggest punting on it for now if it's
> >     not critical.
> >
> And, as I mentioned above, conductor already provides another way to do 
> this.

Right, at the Conductor level. If the user goes to IWHD directly or
through the CLI, the "users' environments" is no longer considered.

> >   - The CLI commands for managing environment tags clearly require more
> >     thought.
> >
> >   - If the user doesn't have write permissions to the image object, they
> >     may be able to create a new build of the image, but they can't e.g.
> >     update the description of the image which is stored in the image
> >     object's body.
> >
> This sounds like we need another permission bit on the image. 'c' -- 
> meaning they can create new builds under this image.
> So (combining w/ the 'x' bit suggestion above) the valid permission 
> combinations are:
> 1) 'r'
> 2) 'rw' (although in practice 'w' without 'c' may not make sense
> 3) 'rc'
> 4) 'rwc'
> 5) 'rx'
> 6) 'rcx'
> 7) 'rwcx' (omitting 'rwx' on similar grounds to not needing 2) )

In order for IWHD to enforce this, it would need to understand the
relationship between images and builds. It doesn't.

I'm suggesting using the write permission on the image object to limit
the ability to create new builds (or more precisely, tag a build as the
latest build globally or for an environment).

Cheers,
Mark.



More information about the iwhd-devel mailing list