Using a keytab file to automate cron jobs needing kerberos credentials

  Cron jobs on systems with kerberized storage, like DartFS and AFS, present challenges.  The problem is that the cron daemon, even running as root, has no privilege to "become you" as far as the filesystem is concerned.   If the command to run lives in your home directory, cron cannot get to it, and if the command is local, but it needs to read or write files in DartFS storage, it will fail at that point.

 Cron must be provided with some form of "saved password".  The mechanism for this is called a keytab file, which contains an encrypted password, and can be used to obtain and renew a credential for the storage.  It is usually used with a service account which has the minimum permissions needed to run the cron job.  This is to avoid putting your personal NetID password at risk by storing it (encrypted) in a keytab. 

Create a keytab file (see Related Articles), then use the k5start tool to gain and keep (as long as needed) the credential, until the specified program has completed.

e.g. hourly run "myscript", as service account "d123abc"

 0 * * * * /usr/bin/k5start -f /usr/local/private/d123abc/key -- d123abc@KIEWIT.DARTMOUTH.EDU sh -c '/dartfs-hpc/rc/home/..../myscript args'

The path to the keytab (e.g. /usr/local/private/d123abc/key) must be accessible to the account running the cron job, not in kerberized storage, and should be readable only by that account.   Everything passed in quotes to "sh -c" is the script to run, which can live in kerberized space and reference files in kerberized space.

Cron must switch identities and change directories to the account running the job, before it has a chance to authenticate with the keytab.  This generally means the service account must be defined as a valid account on the system.  The password may be locked and the home directory can be /tmp, but this permits cron to use the account.  The script to be run, and all auxiliary files, must be readable by the service account once authenticated, and any output file locations must be writable.

To give the owner of the service account control over the cron job, local sudo privileges can be given to the owner.

e.g. if the real owner is d000123, in sudo config.

d000123  ALL=(d123abc)                        /bin/crontab -e
d000123  ALL=(d123abc)  NOPASSWD: /bin/crontab -l

Then user d000123 runs e.g. sudo -u f004jk4 crontab -e




Article ID: 94843
Fri 12/20/19 3:19 PM
Mon 10/5/20 2:33 PM