Image permissions, round 2

Mark McLoughlin markmc at redhat.com
Thu Jun 2 13:48:34 UTC 2011


(cc-ing iwhd-devel; I don't like cross-posting, but so much of this is
about IWHD, I think it's probably warranted)

Hey,

We had a follow-on discussion on the phone about image permissions where
we concentrated on the first two items:

  1) Access control on IWHD objects

  2) Conductor's environment based instance launch policy

The original thread is here:

  https://fedorahosted.org/pipermail/aeolus-devel/2011-May/thread.html#1741

What follows is my attempt to summarize a way forward. I can't say that
it was the consensus from the discussion, but hopefully it's not too
from that.

Apologies for the length of this, but it's hard to capture the details
and still stay brief.

Cheers,
Mark.

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

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

  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.

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

= 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

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.

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.

   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.

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




More information about the iwhd-devel mailing list