[et-mgmt-tools] Re: Cobbler Authorisation

Dan swissslinky at gmail.com
Mon Nov 12 14:47:38 UTC 2007


> Al Tobey wrote:
> > On Nov 8, 2007 5:00 AM, Dan wrote:
> >   
> >> Hi Al,
> >>
> >> I should introduce myself first. My name is Dan, I'm based at ...,
> >> working on Unix Installation tools. We are currently working on a
> >> project to rewrite our existing install infrastructure and have been
> >> considering, along with others (existing, and off the shelve), cobbler
> >> for our needs.
> >>
> >> Cobbler is giving us a lot of stuff for free, but for it to succeed it
> >> obviously has to fit all our requirements, or be easily extended for our
> >> environment, as well as sustainable in the future.
> >>
> >> I'm aware that you're currently working on authorization, which is one
> >> our first areas to tackle. It's probably best to discuss this now,
> >> before things start to head in one direction.
> >>
> >> In simple, are requirements are as follows:
> >>
> >> [1] Only certain users should be able to add (remove, edit, etc)
> >> distributions.
> >>
> >> [2] Only certain users should be able to add (remove, edit, etc)
> >> profiles.
> >>
> >> [3] Only the correct "owner" of a system should be able to touch a given
> >> system.
> >>
> >>
> >> What we'd ideally like to do is keep aware from administering any user
> >> information. There are plenty of databases around with all the
> >> information we could ever need.
> >>     
> This seems to lend itself to further leveraging "modules" in cobbler.   
> Right now the modules
> system allows for trading out serialization modules, and we could extend 
> this to also allow trading
> out authorization modules.   This allows things to be expanded for 
> various environments that are
> relatively diverse without installing something in core that may not be 
> the best fit for everyone.
> 

I'm keen on a modular approach. It means that when/if a requirement
changes later down the road, chances our we just rewrite/add a module,
rather that touch the core. Not having to touch the core also makes
integrating future releases ten times easier.

> >
> > Hopefully that'll be easy to accomplish with plugins and/or scripts to
> > auto-populate cobbler's users.
> >
> >   
> >> One ideal solution would be to limit who can add a distribution [1] and
> >> profiles [2] based on maybe, the users Kerberos credentials.
> >>     
> >
> > The way I've thought about it, we mostly care about systems, since
> > profiles and distributions should be maintained by superusers.
> > Obviously, I'm wrong ;)  I'd like to hear more about how you see
> > Cobbler working in your shop as a kind of use-case if you have a need
> > for users to administer distros & profiles.
> >   
> 
> An auth module could provide something look like
> 
> verify(user, pass,cobbler_object) -> True | False
> 
> Again, the default auth module (in /etc/cobbler/modules.conf) would be 
> auth_none, which would describe
> the present system.
> 

Distributions/images here don't just come from sysadmins, they're also
internally created by users. Somebody may create a custom image which
they wish to deploy on their cluster of 50 systems which they're solely
responsible for. 

At present, they send us the image, we manually add it to the server,
manually amend configurations for it to be available... This is a time
consuming activity, especially if the provider is sending over several
images a week. We'd like to allow them to upload their own
images/distributions, without taking up the time of our already busy
sysadmins. We want them to take control of provisioning their systems,
from start to finish, all on their own. We simply provide the install
mechanism.

If I need to fill in any gaps here, let me know.

> >   
> >> So there would be a group of people, bob at FOO.COM, john at FOO.COM... listed
> >> somewhere, like .klogin for example. Bob or John would log on to the
> >> install server and have access to distribution management.
> >>
> >> ...or something along those lines...
> >>
> >> With regard to [3], it gets slightly more confused. For example, we have
> >> a network database which details all the devices on the network, and
> >> maps the device to a responsible and/or main user.
> >>     
> >
> > This could be pulled into cobbler via triggers or some kind of backend
> > data adapter.    For instance, the user code I implemented uses
> > Cobbler's serializer which Michael has conveniently made pluggable.
> >   All you'd need to do is write a plugin to pull & map users from your
> > database rather than Cobbler's files.
> >   
> 
> Seems like we are on the same page :)
> 
> > Other users have requested to be able to do this for systems too,
> > specifically against LDAP servers that already have all their system
> > information.
> >
> >   
> >> This checking and auth or denying is easy, but how this can map into
> >> Cobbler is where I'm becoming stuck. Originally my idea was to rely on
> >> the Triggers, to check the database and make a decision, returning 1 for
> >> yes user is ok, so they can do stuff, returning zero if they're a
> >> fraudster.. but in talking this through with Michael a little bit, I'm
> >> beginning to move away from this.
> >>
> >> So, there's a lot to take in there.
> >>
> >> I've read the mailing list about the tags. If I understand them
> >> correctly, if a system has a tag 'Dan', only Dan can do stuff with the
> >> object(s) that have that tag? That right.
> >>     
> >
> > That's pretty close.   If a system or its profile has "Dan" and the
> > user has the tag "Dan", then that user has access to the system.
> >
> > The main problem with my tagging approach is that it requires that you
> > be careful about what tags users/systems/profiles get or you could
> > accidentally grant access to things by accident.     That's true of
> > any system, but especially easy with something as fast and loose as
> > tag-based authorization.
> >   
> 
> The above module approach could leave the permissions infrastructure 
> completely out
> of cobbler... so it could optionally look at tags, or it might just be a 
> yes/no sort of thing
> based on the type of object ... depending on what the site wanted to 
> implement.    The main
> thing we'd want is to not require setup of /anything/ for the core 
> install to work and make
> it easy enough for a complex site install to adapt to their needs.
> 
> >   
> >> The idea that sysadmins give root access to users for certain machines,
> >> although is principle is ok, and I'm sure the protection is there, it
> >> just doesn't "feel" right. It feels like we would have to maintain a
> >> list of sudo users..
> >>     
> >
> > I'm pretty sure just about any system in cobbler will require sudo to
> > get user-based authorization correct.    I'm mainly concentrating on
> > the webui, but noticed that the same code could probably support the
> > CLI via SUDO_USER where the webui would use REMOTE_USER.    Maybe it
> > might be worth looking into having a reduced version of the CLI tool
> > that uses XMLRPC like the webui so it doesn't have to run as root.
> > That would make things a bit more interesting ;)
> >   
> 
> I'd like to leave the complexity out of the command line invocations.
> 
> We should be thinking about web services, for which the command line can 
> be a client.
> 
> 
> >   
> >> So in conclusion, where is Cobbler going with regard to authorisation
> >> now?
> >>     
> >
> > Michael's in requirements gathering phase, AFAIK.   I'm just throwing
> > together prototypes to see what's easy.   Once we figure out an
> > approach that works for most people, it'll probably fall together
> > pretty quickly.
> >
> >   
> Yep... seeing what people want, and how best to do it.
> 
> Ultimately I like the modules approach best, and in general, I intend to 
> expand
> cobbler to be more modular in this regard as well.  For instance, as the 
> command line
> is expanded, each function in the command line might be a module, making 
> it easier
> for folks to custom commands outside the core.
> 
> Modules also the advantage of being able to trade cobbler objects, which 
> the triggers
> don't have.  Triggers aren't going away though, they are simple, and 
> simple can be good.
> For something like an email notification, that's all you need.
> 

Modules ftw!

> >> Michael says he's looking at the IPA stuff, which doesn't seem all that
> >> bad, but how it fits together, I've no idea.
> >>     
> >
> > It looks like a nice suite, but I don't think people would appreciate
> > cobbler being hooked too tightly to any single system, since near 100%
> > of users already have some kind of system in place.   I also don't
> > think they're providing much in the way of API's yet (could be wrong),
> > which is really what we'd want.
> >   
> 
> It's just investigation.   If anything this would be "we can have a 
> module that
> hooks into kerb" at most.   It most certainly would not be required, 
> the standard
> behavior is to keep things working like they work now, and for things to 
> be very
> simple to setup up.   That's incredibly important for a large portion of 
> the cobbler
> install base.

That's fair enough. Just something which can be downloaded and then
plugged into an existing authentication mechanism with as little
fiddling as possible. I just cannot see us going near IPA, because we
already have the infrastructure in place. 

> 
> > The webui is already pretty trivial to put behind kerberos for
> > authentication using any number of Apache modules, as of 0.6.3.
> > Authorization will be trickier, since that's often done using some
> > kind of LDAP or SQL scheme.    Cobbler is trying to stay agnostic
> > towards databases, which is a nice idea, but leaves us on our own for
> > implementing an auth system - we can't just borrow somebody else's
> > wholesale.
> >   
> Seems like where you'd want to hook into kerb to me.
> 
> > I've considered extending the webui's usage of PATH_INFO so that it'll
> > be easier to have apache modules implement authorization behind
> > Cobbler's back, similar to how you can have sudo parse command line
> > options.  For instance, you could do:
> >
> > dan localhost=/usr/bin/cobbler system edit --name=dan_workstation
> > bob localhost=/usr/bin/cobbler system edit --name=bob_workstation
> >
> > This is hacky though and a PITA to administer, though it wouldn't be
> > too bad if you autogenerated it from a database.    Instead I'd like
> > to see:
> > dan localhost=/usr/bin/cobbler
> >
> > And have cobbler check if "dan" has edit access on "dan_workstation".
> >
> > That raises a couple more questions:
> >
> > 1. Do we only care about write access?
> >   
> 
> Yes.
> 
> > 2. Does anybody have a need to grant read access to only parts of cobbler?
> >   
> 
> Assume no.     The permissions on all the files in the kickstart 
> directories are world readable, as needed
> by Anaconda.

Indeed. I originally thought I could place permissions on the images and
kickstarts, but Anaconda wouldn't like this, as Michael says. 


> 
> > 3. Please tell us if you would have use for user-based authorization
> > in the cobbler CLI.    If we only care about the webui, completely
> > different approaches can be taken.
> >   
> 
> Anything we do needs to be done at the services layer, not with just 
> respect for the Web UI or the CLI.  This enables
> remote command lines and integration with other services.  
> >

Yes, we need authorization/authentication at CLI, as well as webUI. 
Not everybody wants to use a webui and not everybody wants to use a CLI,
so we need to provide an interface for both to keep them all sweet.  

>    
> >> Many Thanks
> >> Dan 





More information about the et-mgmt-tools mailing list