Re: [HTCondor-users] dirty AFS hook stuff?

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

On Nov 11, 2013, at 12:10 PM, Rich Pieri <ratinox@xxxxxxx> wrote:

> Zachary Miller wrote:
>> Even if HTCondor did this delegation for you (and I have investigated
>> adding support for just that), my recommendation would be that you do
>> not use your regular AFS credential for HTCondor usage.
> 
> Precisely. Even setting a directory with system:anyuser rlidwk is better
> than trying to bypass the Kerberos and AFS identity mechanisms. I still
> recommend using dedicated volumes instead of users' home directories. At
> the least it prevents users from blowing out their quotas and you can
> easily exclude the execute volumes from routine backups.
> 
> 
> Brian Bockelman wrote:
>> If you send security tokens along with your HTCondor job, the
>> workers in your HTCondor pool can act as your user within that
>> security domain.  This is true regardless of AFS / KRB5 / GSI /
>> sending shared passwords.
> 
> If I interpret the security section of the Condor manual correctly then
> this isn't true at all. What Condor calls authentication is not
> verification of a user's identity. It is verification of a user's
> permissions to use the pool's resources.
> 

(Apologies for the long response; I got started and it just kept on going :) )

We're talking about different things.  The point I'm getting across is somewhat orthogonal to authentication / authorization within the HTCondor pool.

I'm talking about what happens if you ask HTCondor to manage an external security token to an external system (such as a GSI proxy or AFS token).

Let's say that I put my Google password into a file and add it to transfer_input_files.  This means that any machine resource which enters the pool can act as me within Google's set of services.

Same thing with GSI - if I add a X509 proxy to my job, the machine resource in the pool can act as me wherever the delegated proxy is accepted.  GSI has a bit of a twist - you can limit the proxy somewhat (for example, to say that the remote machine can only do file operations but not submit further jobs).

The AFS case is analogous.  If you hand a remote machine your AFS token, the remote machine can act as your user within AFS.

My point is, to my knowledge, the same caveats apply to AFS as to the existing system of sending around GSI tokens.  It doesn't mean they aren't limitations - but it does mean the limitations are basically understood.

There's a transitive trust - if you send credential X with your job to the schedd, you're trusting the schedd to hand it to a remote resource in the pool.  If you don't trust how the sysadmins created the pool, you shouldn't give the pool your credentials.

Your example is good - you wouldn't want to trust a desktop pool your "real" AFS token.  However, if the pool was securely constructed (maybe your internal CA issues each daemon a unique certificate and every host is in a secure machine room), then you may trust it with your AFS token.  Zach has an excellent point that there are additional risk management and operational reasons to still construct a separate AFS token.

Another limitation of the HTCondor approach is that you really can't mix trusted and untrusted nodes in your pool (or flock of pools, if you're flocking).  It's not possible to say "only match this job to high-security resources" in a mixed-security level pool.  [Of course, "limitation" may be good because it's less likely the user will screw up their job requirements!]

Brian