I've updated this to reflect current plans
https://fedorahosted.org/cobbler/wiki/AclFeature
A sample version of the ACL config as documented above is:
(Again, this is a list of fields/methods to deny access to)
--- admin: {} # no denials admins: {} jradmin: copy_distro: * copy_image: * copy_profile: * copy_repo: * modify_distro: * modify_image: * modify_profile: * modify_repo: * new_distro: * new_image: * new_profile: * new_repo: * remove_distro: * remove_image: * remove_profile: * remove_repo: * write_kickstart_templates: * lesstrusted: copy_*: * modify_distro: * modify_image: * modify_profile: * modify_repo: * modify_system: gateway-*: ~ hostname-*: ~ ip-address-*: ~ mac-address-*: ~ subnet-*: ~ new_*: * remove_*: * rename_*: * save_distro: * save_image: * save_profile: * save_repo: * sync: * write_kickstart_templates: * unmatched: {}
Basically that's just denials of various fields. This should be easy to show in the WebUI when someone logs in what they can and can't tweak. Combined with a toggle option in the webapp for "Hide Advanced Fields", and also grey out systems people don't own or fields they can't access this seems to be rather workable and not terrible to implement. Ideally we have a way a toggle on the list view to list things I own or to list all things.
So the question to you is (and I've kind of asked this before), what sort of user restrictions and roles would you want in Cobbler?
Does that kind of denial system seem to make sense?
This doesn't preclude having an ACL editor in the Wiki for admin users, but I don't plan to write one. The goal here is to make things very workable for folks with specific use cases now, which they'll probably set up once and leave alone, rather than building a large overcomplicated web system.
The end goal is to be able to hand your cobbler web app to users who just need to tweak certain things and feel complicated they won't blow something up.... being able to delegate basic installations to users, and allow them to control just certain aspects of the configuration without breaking too much.
In the most extreme use cases (very large sites) you will probably still want to implement your own view into Cobbler's XMLRPC, in which case this feature can still be used to enforce security for those communications.
Anyhow, comments welcome. If you'd rather have something different, now's the time to say that too. If this feature is not for you, don't worry though, as it is optional and not in your way by default -- but I would never much like to hear from people who do want ACL controls and to know if that's the kind of access control they are looking for.
Thanks!
--Michael
Michael DeHaan wrote:
I've updated this to reflect current plans
https://fedorahosted.org/cobbler/wiki/AclFeature
A sample version of the ACL config as documented above is:
(Again, this is a list of fields/methods to deny access to)
admin: {} # no denials admins: {} jradmin: copy_distro: * copy_image: * copy_profile: * copy_repo: * modify_distro: * modify_image: * modify_profile: * modify_repo: * new_distro: * new_image: * new_profile: * new_repo: * remove_distro: * remove_image: * remove_profile: * remove_repo: * write_kickstart_templates: * lesstrusted: copy_*: * modify_distro: * modify_image: * modify_profile: * modify_repo: * modify_system: gateway-*: ~ hostname-*: ~ ip-address-*: ~ mac-address-*: ~ subnet-*: ~ new_*: * remove_*: * rename_*: * save_distro: * save_image: * save_profile: * save_repo: * sync: * write_kickstart_templates: * unmatched: {}
Basically that's just denials of various fields. This should be easy to show in the WebUI when someone logs in what they can and can't tweak. Combined with a toggle option in the webapp for "Hide Advanced Fields", and also grey out systems people don't own or fields they can't access this seems to be rather workable and not terrible to implement. Ideally we have a way a toggle on the list view to list things I own or to list all things.
So the question to you is (and I've kind of asked this before), what sort of user restrictions and roles would you want in Cobbler?
Does that kind of denial system seem to make sense?
This doesn't preclude having an ACL editor in the Wiki for admin users, but I don't plan to write one. The goal here is to make things very workable for folks with specific use cases now, which they'll probably set up once and leave alone, rather than building a large overcomplicated web system.
The end goal is to be able to hand your cobbler web app to users who just need to tweak certain things and feel complicated they won't blow something up.... being able to delegate basic installations to users, and allow them to control just certain aspects of the configuration without breaking too much.
In the most extreme use cases (very large sites) you will probably still want to implement your own view into Cobbler's XMLRPC, in which case this feature can still be used to enforce security for those communications.
Anyhow, comments welcome. If you'd rather have something different, now's the time to say that too. If this feature is not for you, don't worry though, as it is optional and not in your way by default -- but
One typo correction...
I would never much like to hear from people who do want ACL controls and to know if that's the kind of access control they are looking for.
never should read "very" ...
Thanks!
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Michael DeHaan wrote:
Michael DeHaan wrote:
I've updated this to reflect current plans
https://fedorahosted.org/cobbler/wiki/AclFeature
A sample version of the ACL config as documented above is:
(Again, this is a list of fields/methods to deny access to)
admin: {} # no denials admins: {} jradmin: copy_distro: * copy_image: * copy_profile: * copy_repo: * modify_distro: * modify_image: * modify_profile: * modify_repo: * new_distro: * new_image: * new_profile: * new_repo: * remove_distro: * remove_image: * remove_profile: * remove_repo: * write_kickstart_templates: * lesstrusted: copy_*: * modify_distro: * modify_image: * modify_profile: * modify_repo: * modify_system: gateway-*: ~ hostname-*: ~ ip-address-*: ~ mac-address-*: ~ subnet-*: ~ new_*: * remove_*: * rename_*: * save_distro: * save_image: * save_profile: * save_repo: * sync: * write_kickstart_templates: * unmatched: {}
Basically that's just denials of various fields. This should be easy to show in the WebUI when someone logs in what they can and can't tweak. Combined with a toggle option in the webapp for "Hide Advanced Fields", and also grey out systems people don't own or fields they can't access this seems to be rather workable and not terrible to implement. Ideally we have a way a toggle on the list view to list things I own or to list all things.
So the question to you is (and I've kind of asked this before), what sort of user restrictions and roles would you want in Cobbler?
Does that kind of denial system seem to make sense?
This doesn't preclude having an ACL editor in the Wiki for admin users, but I don't plan to write one. The goal here is to make things very workable for folks with specific use cases now, which they'll probably set up once and leave alone, rather than building a large overcomplicated web system.
The end goal is to be able to hand your cobbler web app to users who just need to tweak certain things and feel complicated they won't blow something up.... being able to delegate basic installations to users, and allow them to control just certain aspects of the configuration without breaking too much.
In the most extreme use cases (very large sites) you will probably still want to implement your own view into Cobbler's XMLRPC, in which case this feature can still be used to enforce security for those communications.
Anyhow, comments welcome. If you'd rather have something different, now's the time to say that too. If this feature is not for you, don't worry though, as it is optional and not in your way by default -- but
One typo correction...
I would never much like to hear from people who do want ACL controls and to know if that's the kind of access control they are looking for.
never should read "very" ...
Thanks!
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Apologies on talking to myself here. I have this working pretty well now.
I have a user "testing" in the jradmin group. He cannot edit distros or profiles, and can also not edit systems he does not own. This is enforced via the ACLs file, not the more complicated route you had to go before which was writing your own module by tweaking the ownership code. Pretty cool.
The next step is testing to see if the "lesstrusted" type role works, for denying access to specific field editing. I will look into that after we do the 1.2 release tomorrow, as well as look at remaining patches on the list at that time.
Comments on this still welcome.
--Michael
Michael DeHaan wrote:
Michael DeHaan wrote:
Michael DeHaan wrote:
I've updated this to reflect current plans
https://fedorahosted.org/cobbler/wiki/AclFeature
A sample version of the ACL config as documented above is:
(Again, this is a list of fields/methods to deny access to)
admin: {} # no denials admins: {} jradmin: copy_distro: * copy_image: * copy_profile: * copy_repo: * modify_distro: * modify_image: * modify_profile: * modify_repo: * new_distro: * new_image: * new_profile: * new_repo: * remove_distro: * remove_image: * remove_profile: * remove_repo: * write_kickstart_templates: * lesstrusted: copy_*: * modify_distro: * modify_image: * modify_profile: * modify_repo: * modify_system: gateway-*: ~ hostname-*: ~ ip-address-*: ~ mac-address-*: ~ subnet-*: ~ new_*: * remove_*: * rename_*: * save_distro: * save_image: * save_profile: * save_repo: * sync: * write_kickstart_templates: * unmatched: {}
Basically that's just denials of various fields. This should be easy to show in the WebUI when someone logs in what they can and can't tweak. Combined with a toggle option in the webapp for "Hide Advanced Fields", and also grey out systems people don't own or fields they can't access this seems to be rather workable and not terrible to implement. Ideally we have a way a toggle on the list view to list things I own or to list all things.
So the question to you is (and I've kind of asked this before), what sort of user restrictions and roles would you want in Cobbler?
Does that kind of denial system seem to make sense?
This doesn't preclude having an ACL editor in the Wiki for admin users, but I don't plan to write one. The goal here is to make things very workable for folks with specific use cases now, which they'll probably set up once and leave alone, rather than building a large overcomplicated web system.
The end goal is to be able to hand your cobbler web app to users who just need to tweak certain things and feel complicated they won't blow something up.... being able to delegate basic installations to users, and allow them to control just certain aspects of the configuration without breaking too much.
In the most extreme use cases (very large sites) you will probably still want to implement your own view into Cobbler's XMLRPC, in which case this feature can still be used to enforce security for those communications.
Anyhow, comments welcome. If you'd rather have something different, now's the time to say that too. If this feature is not for you, don't worry though, as it is optional and not in your way by default -- but
One typo correction...
I would never much like to hear from people who do want ACL controls and to know if that's the kind of access control they are looking for.
never should read "very" ...
Thanks!
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Apologies on talking to myself here. I have this working pretty well now.
I have a user "testing" in the jradmin group. He cannot edit distros or profiles, and can also not edit systems he does not own. This is enforced via the ACLs file, not the more complicated route you had to go before which was writing your own module by tweaking the ownership code. Pretty cool.
The next step is testing to see if the "lesstrusted" type role works, for denying access to specific field editing. I will look into that after we do the 1.2 release tomorrow, as well as look at remaining patches on the list at that time.
Comments on this still welcome.
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Further, I added some info on choosing the best security options if you have a lot of different users going at the cobbler server.
May prove useful in addition to the above docs and wiki reorg. Also touches on SELinux and firewall rules a bit, contributions welcome.
https://fedorahosted.org/cobbler/wiki/LockDown
--Michael
cobbler@lists.fedorahosted.org