[et-mgmt-tools] Re: Cobbler Authorisation

[Michael DeHaan]

Al Tobey wrote:
> On Nov 8, 2007 5:00 AM, Dan Dengate 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.

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

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

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

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

> 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.  
>   
>> Many Thanks
>> Dan Dengate
>>     
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>