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@xxxxxxx, john@xxxxxxxxxx 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.
