Long-running jobs with renewal of krb5 tickets and AFS tokens
Jason Edgecombe
AFS during the run.
I've read the k5start and k5renew man pages, but I don't see how I can
have users type in their password when they start a job and have the
tickets and tokens keep being renewed.
How can I do this?
Thanks,
Jason
Thomas Kula
Give them a keytab, but not one for their normal identity (this
breaks things). Create, rather, an instance for them that can
be put in a keytab, give that instance permission to do whatever
it needs to do in AFS, and use the option to k5start that has it
use a keytab instead of asking for a password.
For example, here's what I do for cronjobs that need to access
AFS:
- create a principal user/cron (e.g. kula/cron)
- extract that into a keytab
- put the keytab somewhere on local disk where only the
user can get to it
- Do what you need to do to give user/cron access to
files in AFS (create the PTS identity user.cron, put
that on the appropriate ACLs)
- Teach the user how to give the proper incantation to
k5start to get credentials from they keytab and keep
renewing them until the job finishes.
This presumes, of course, that it works in your setup to put
that keytab somewhere on local disk and that the user will
start the job from a machine that has the keytab on local
disk. Also, remember off course, that access to the keytab
gives access to the files, so protect it accordingly.
I've also had good luck starting a screen session inside of
it's own pag and with it's own credentials cache, and in one
window have something that runs the job and in another window
something renewing the user's credentials. That could be
something as simple as "user must remember to attach the screen
session every N hours and renew their credentails" to using
k5start with the keytab idea above. I don't think k5start has
an option that prompts you for a password *and* remembers it
to keep renewing credentials on your behalf, but since I always
just use the keytab option I'm not as familiar with that use
of k5start. If there is such an option, remember to treat the
environment it runs in as securely as you would treat the user's
credentials cache, since, well, that process has the user's
password.
There are probably several other ways of doing this, but these
are a couple that have worked well for me, and at work we've
helped a couple users do the screen option, so at least someone
other than me can understand the process well enough to use
it (your users, of course, may vary).
--
Thomas L. Kula | ku...@tproa.net | http://kula.tproa.net/
Russ Allbery
> We have users who need to run long-running jobs and store their files in
> AFS during the run.
>
> I've read the k5start and k5renew man pages, but I don't see how I can
> have users type in their password when they start a job and have the
> tickets and tokens keep being renewed.
>
> How can I do this?
If you're not dealing with a batch environment, where the execution
happens some time after the user authenticates, then krenew is what you
want. It just doesn't do the initial ticket acquisition.
You configure your PAM module and krb5.conf to get renewable tickets by
default, so that the user already has renewable tickets when they start
the job. Then run the job under krenew. It will make a private copy of
the existing ticket cache and then keep renewing tickets and tokens until
either it can't any more or the job ends.
If you *are* dealing with a batch environment, you want Kula's approach.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery
> I don't think k5start has an option that prompts you for a password
> *and* remembers it to keep renewing credentials on your behalf, but
> since I always just use the keytab option I'm not as familiar with that
> use of k5start.
k5start intentionally doesn't support this because I think it undermines
the Kerberos security model.
Jason Edgecombe
I guess setting things for renewable tickets longer than 7 days or
running the jobs in local disk will be easiest.
We have a 7 day normal/renewable lifetime. What length do other sites have?
I might need use the job scheduler approach, but that's a pain. I would
guess 10-20 people would want that ability. I ether need to modify our
account maintenance processes or do it all manually.
Has anyone automated the management of user.cron principals?
unfortunately, I have had to tell people that they can't have an
infinite ticket lifetime. :P
Thanks for the help!
Thanks,
Jason
Russ Allbery
> I guess setting things for renewable tickets longer than 7 days or
> running the jobs in local disk will be easiest.
>
> We have a 7 day normal/renewable lifetime. What length do other sites
> have?
Seven days here as well. That's also our limit on how long we let compute
jobs run on our normal timeshare systems. We're working on a batch
queuing system that will use separate cron instances.
> I might need use the job scheduler approach, but that's a pain. I would
> guess 10-20 people would want that ability. I ether need to modify our
> account maintenance processes or do it all manually.
>
> Has anyone automated the management of user.cron principals?
> unfortunately, I have had to tell people that they can't have an
> infinite ticket lifetime. :P
We've automated similar things here and there's some support for it in the
kadmin-remctl package. I'm hoping to clean that up substantially at some
point, but haven't had the time (and it's not in the top hundred on my
priority list at the moment).
Jason Edgecombe
Besides, it's not on my top 100 todo list either. I'll deal with it if
needed and just tell people to use local disk for storage or use screen
with weekly kinit's.
Thanks to everyone for their help!
Sincerely,
Jason
Hugo Meiland
> We have users who need to run long-running jobs and store their files in
> AFS during the run.
>
> I've read the k5start and k5renew man pages, but I don't see how I can
> have users type in their password when they start a job and have the
> tickets and tokens keep being renewed.
>
>
Hi John,
I'm forcing an 'at' job in the .cshrc script to 'k5renew' and 'afs5log'
every 8 hours or so for the max lifetime of a week. This works only for
interactively started jobs of course; jobs running through a scheduler
such as pbs or condor need some other tricks...
Hugo
Nicolas Williams
> I guess setting things for renewable tickets longer than 7 days or
> running the jobs in local disk will be easiest.
>
> We have a 7 day normal/renewable lifetime. What length do other sites have?
I have seen sites use on the order of months for the renewable ticket
lifetime, but still hours for normal ticket lifetime. If you already
use seven days for renew life you might as well double it -- whatever
your threat model is, if you can accept seven days then chances are you
can accept fourteen.
Nico
--
Jason Edgecombe
order of a month. If I were to change the renewable lifetime, I need to
change all principals, the client krb5.conf and the server kdc.conf. Is
that correct?
Thanks,
Jason
Nicolas Williams
> Nicolas Williams wrote:
> >I have seen sites use on the order of months for the renewable ticket
> >lifetime, but still hours for normal ticket lifetime. If you already
> >use seven days for renew life you might as well double it -- whatever
> >your threat model is, if you can accept seven days then chances are you
> >can accept fourteen.
> >
> Doubling it wouldn't really help. It would probably need to be on the
> order of a month. If I were to change the renewable lifetime, I need to
> change all principals, the client krb5.conf and the server kdc.conf. Is
> that correct?
Hmmm, not sure. The client ought to ask for infinity, but I don't think
that's the default, sadly. The kdc.conf parameters in question are best
not used -- you can use kadmin policies instead. Also, IIRC the TGS
principal's renew life puts a bound on all, IIRC, so generally you might
want to set principals' renewable ticket life to be very long, and use
the TGS principal as a big hammer.
Nico
--
Simon Wilkinson
On 28 Feb 2009, at 23:04, Thomas Kula wrote:
> On Sat, Feb 28, 2009 at 05:42:58PM -0500, Jason Edgecombe wrote:
>> We have users who need to run long-running jobs and store their
>> files in
>> AFS during the run.
>>
>> I've read the k5start and k5renew man pages, but I don't see how I
>> can
>> have users type in their password when they start a job and have the
>> tickets and tokens keep being renewed.
>>
>> How can I do this?
>
> Give them a keytab, but not one for their normal identity (this
> breaks things). Create, rather, an instance for them that can
> be put in a keytab
We (Informatics @ Edinburgh) are developing an identity management
system which provides a user-friendly interface both to allow a user
to create a new instance from their primary one, and to allow them to
assign access control entitlements from their primary instance to the
one they've just created. I'll be talking about, and demoing it, at
this years AFS & Kerberos Best Practices Workshop.
Cheers,
Simon.
Rainer Laatsch
on job submission the user has an AFS token. Just that. This gets
transferred as a special encrypted comment within the job.
The SGE is AFS aware. On job start and every refresh period (say some
hours) the job shephard, running in the same PAG as the users job,
transmits the token to a VlServer (needs the KeyFile) for refresh. Instead
of the former (obsolete?) arc/arcd we use SSH (with a forced command) as
the transport medium on a separate SSHD port with special sshd_config &
authorized_keys files.
The token may be valid or not and will stay so; just the time validity is
refreshed. If that was the *only* disturbation the batch will get a good
token back.
The user job effectively needs an AFS token. The above method is
straight forward. Fiddling with interim Krb5 tickets is no help. Keytabs
are a bad idea.
Best regards
Rainer
-------------------------------------------------------------------------------
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>