[et-mgmt-tools] Re: Cobbler Authorisation

[Al Tobey]

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.

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.

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

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 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 ;)

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

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

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.

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?

2. Does anybody have a need to grant read access to only parts of cobbler?

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.

> Many Thanks
> Dan Dengate