[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Schedd and kerberos
- Date: Fri, 28 Nov 2008 13:38:53 +0000
- From: David McBride <dwm@xxxxxxxxxxxx>
- Subject: Re: [Condor-users] Schedd and kerberos
Liam Gretton wrote:
> I'm setting up a Condor pool which consists of a single Central Manager,
> a number of execute hosts and a much smaller number of separate submit
> hosts (all running Condor 7.0.5).
> I need to treat the submit hosts as untrusted to some extent, and I'm
> trying to use Kerberos to authenticate job submissions.
We have a very similar configuration -- using Kerberos to authenticate
all job submissions and also to authenticate all daemon-daemon
Our configuration differs slightly in that I'm not using a dedicated
service principal for daemon-daemon communications
(condor/hostname@REALM) but am instead using the existing host host keys
> What I can't work out from the Condor security documentation is on
> which host I need to set the Kerberos features. I've created a condor
> service principal (condor/hostname@REALM) in Kerberos and have set
> the following security options on the Central Manager:
> KERBEROS_MAP_FILE = /opt/condor/etc/condor.kmap
> CONDOR_SERVER_PRINCIPAL = condor
> SEC_ADVERTISE_SCHEDD_AUTHENTICATION_METHODS = KERBEROS
> SEC_ADVERTISE_SCHEDD_AUTHENTICATION = REQUIRED
> ...but that's not helping.
If you're using Condor service principals of the form
condor/hostname@REALM to authenticate daemon-daemon communications, I
suspect that you may need such principals to exist for all peers so as
to provide for mutual authentication.
I also don't think that the configuration you've specified is sufficient
to achieve the desired security properties; Kerberos authentication in
this case is only occuring when a SCHEDD is trying to publish a record
to a central COLLECTOR; no requirement is made of the SCHEDD telling it
that it must authenticate job submissions it receives from clients.
(Though I'm not sure, it's been quite some time since I last set this up!)
> I'd be very grateful for any pointers to where I'm going wrong.
The configuration we're using (set on all participating Condor hosts) is
as follows; you may find it a useful starting point:
# -----8<----- Cut here -----8<-----
## Security configuration.
## Set default security requirements:
# Strong authentication and signing of messages between daemons and
# clients is required.
SEC_DEFAULT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_INTEGRITY = REQUIRED
# Messages are not considered confidential. Encryption is optional.
SEC_DEFAULT_ENCRYPTION = OPTIONAL
# Read operations: authentication is not required.
SEC_READ_AUTHENTICATION = OPTIONAL
SEC_READ_INTEGRITY = OPTIONAL
## Specify what security backends may be used:
SEC_DEFAULT_AUTHENTICATION_METHODS = KERBEROS
#SEC_DEFAULT_INTEGRITY_METHODS = # Only MD5 is available,
# usage assumed.
SEC_DEFAULT_ENCRYPTION_METHODS = 3DES, BLOWFISH
## Client-side security configuration
## This needs to be relatively relaxed so that we can interoperate
## gracefully with condor services outside of DoC.
## (Such as the global collector at WISC.)
SEC_CLIENT_AUTHENTICATION = OPTIONAL
SEC_CLIENT_INTEGRITY = OPTIONAL
SEC_CLIENT_ENCRYPTION = OPTIONAL
## Kerberos configuration
# Daemons should use local host keys of the form host/hostname@REALM
CONDOR_SERVER_PRINCIPAL = host
## User-based access control rules.
# Rules are of the form username@domain/hostname
# Allow anyone read access of the pool state.
ALLOW_READ = */*
# Allow only valid DoC users job submission / state update.
ALLOW_WRITE = *@doc.ic.ac.uk/*.doc.ic.ac.uk
# Only grant condor-admin user administrator, OWNER and CONFIG rights.
ALLOW_ADMINISTRATOR = dwm@xxxxxxxxxxxx/*.doc.ic.ac.uk
ALLOW_NEGOTIATOR = condor@xxxxxxxxxxxx/$(NEGOTIATOR_HOST)
ALLOW_CONFIG = $(ALLOW_ADMINISTRATOR)
ALLOW_OWNER = $(ALLOW_ADMINISTRATOR)
# -----8<----- Cut here -----8<-----
This appears to do what we want -- job submissions must be authenticated
via a user's kerberos TGT; all daemon-daemon communications are
authenticated via host keytab, but unprivileged users who don't have any
Kerberos credentials at all (such as cron jobs that generate utilization
figures, etc.) are able to query the state of the pool.
Hope this helps!
David McBride <dwm@xxxxxxxxxxxx>
Department of Computing, Imperial College, London