[et-mgmt-tools] Re: Cobbler Authorisation

Fri Nov 9 04:39:55 UTC 2007

Michael DeHaan wrote:
> 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. 
>>  

One other aspect to authorization that I would add is logging and reporting - 
who did what and when.  This could be achieved by wrappers in the actions and 
pluggable modules to some cobbler/syslog facilities.

I can think of all the sarbox audits that clients go thru on the patching 
side, don't see how this would be any different.

-regards
Subhendu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sghosh.vcf
Type: text/x-vcard
Size: 266 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20071108/850ce2a9/attachment.vcf>