Hi Charles, please accept the following as quoted properly, as I am not allowed to use an email client to handle my email ;)
> We have kerberos everywhere, and use it for access to NFS home directories. > > So what do we do about cron jobs? We have a solution, but it involves custom > code that impersonates the KDC. I’d like to do someone more standard. > Constained delegation seems like a possibility. But I’d need to be able to > say “allow cron to get credentials for NFS for a specific group of users.” > Since all of our systems run cron, I don’t want to allow any system to be > able to get an NFS credential for any user. That would let root on any > system see anyone’s files. So the user has to authorize it. Presumably > if the user runs his own desktop, he’s willing to allow it to get > credentials for himself. But I wouldn’t trust his machine to be able to get > mine. Considering the following: [nfs share machines] <=> [cron running machines] You may store keytab files on the cron machines to be able to auth as the user and use NFS. The keytabs may be stored to the cron host for the specific, if you have cron hosts this is complicated. > The constrained delegation mechanism seems to handle this, except that > I don’t see a way to constrain it to specific users. Am I missing something? You may think of a shadow user for each user( like a evil twin - taking nfs into account ;) ), which share the same groups, but can be restricted in terms of how to use it's rights via privileges in the ipa. So it's able to use the scope you need for the cron scripts. With a keytab of this bad boy it would be possible to mount the same resource without having the risk that this creds are use to abuse other parts of your infrastrucure. There also would be the alternative to use certificates for that exact purpose. You may think of representing the NFS stored data differently. For example as a http(s) using nginx or apache. There you have a wide range of options to auth a request and may can mal this accordingly and more precise. > allow cron to get credentials for NFS for a specific group of users. You also can go with what sun did, ages ago. You mount it with host credentials and then use the std unix user permissions in the file system to grant for block access to parts of the mounted tree. Problematic is that your services or hosts may get stuck, because the nfs server dies. Another idea would be to use sshfs (fuse) and ssh public keys. Cron would be able to mount the environment, if you can provide wrapper script for your user base. With that this would be flawless. Positive would be that ssh keys could be limited to allow configured and by that allowed interactions (like sftp only or such). Generally I would recommend to not have cron running under user control. It's a quest and challenge to find them back, when an user disappears forever. But back to topic... The problem is as you already stated, that you can impersonate without limitations when using the users keytab or similar, which may lead into a bigger problem. Regards, Sven _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
