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

[Marian Marinov]

On Wednesday 13 August 2008 16:10:18 Prentice Bisbal wrote:
> 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?

When using SSH keys you can have an agent which will keep all of your keys and 
you are not required to have them on the machine. But again the Information 
Security Officer would most likely drop the idea on first sight.

>
> > 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.