[Beowulf] Re: Linux cluster authenticating against multiple Active Directory domains

[Prentice Bisbal]

Perry E. Metzger wrote:
> Dave Love <d.love at liverpool.ac.uk> writes:
>>> We'd prefer to steer clear of Kerberos, it introduces
>>> arbitrary job limitations through ticket lives that
>>> are not tolerable for HPC work.
> 
> Which of course isn't true. If Wall Street firms, which really cannot
> afford to have their trading systems go down even for a second, can
> happily use kerberos in servers, so can anyone.
> 
>>> Say you submit a job that is in the queue for a week
>>> and then will run for 3 months - we don't know if the
>>> AD admins will permit the creation of a 4 month ticket
>>> "just in case"..
>> Why do you need to re-authenticate, and if you do, surely you need to
>> stash a credential somewhere however you do it?
> 
> Indeed, and if you have stashed your key appropriately you can just
> have a cron job kinit as often as you like. The kinit man page
> gives the command line flag for requesting credentials using a key
> taken from a file, ans also lists the flag for setting your ticket
> expiry time. All you do is put one line in a crontab with kinit and
> those two options, say every 24 hours.

Isn't stashing a bunch of user keys on a single system a major security
risk? One could argue that the cluster should be on a private, secured
network so it's okay, but then I'll argue that the node storing the keys
will most likely be the master node, which is often on a "public"
network so users can access it to submit jobs.

I can't imagine an arrangement like this passing the scrutiny of the
local information security officer. And if you're going to use a key
stored on a disk, why not just use SSH keys?

> 
> I keep seeing these messages go by over and over making it sound like
> this is difficult. It is not difficult. I've seen people say "I have
> seen no document with a recipe for how to do it", perhaps because a
> single kinit command in a cron job is too simple for a HOWTO.

Isn't stashing a bunch of user keys on a single system a major security
risk? One could argue that the cluster should be on a private, secured
network so it's okay, but then I'll argue that the node storing the keys
will most likely be the master node, which is often on a "public"
network so users can access it to submit jobs.

I can't imagine an arrangement like this passing the scrutiny of the
local information security officer. And if you're going to use a key
stored on a disk, why not just use SSH keys?

> 
> Maybe some sort of strange myth has been going by so long on this that
> people refuse to believe that the ticket refresh is a single easy
> command?

Maybe you're not reading the questions correctly. In my original
question about how to do this, I asked how to do this using the queuing
system to refresh the keys -- I was asking for an integrated solution.
Above, you describe doing it with a cron job, which does not answer my
question.

-- 
Prentice Bisbal
Linux Software Support Specialist/System Administrator
School of Natural Sciences
Institute for Advanced Study
Princeton, NJ