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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...