GlideinWMS

GSI Deprecation Notice

Support for GSI authentication is rapidly ending, and will cease to work with OSG software some time in 2022. Please migrate your installation to JWT (Token) authentication as soon as possible.

1. Quick Reference Guide to GSI Authentication Setup

GlideinWMS uses GSI for authentication/authorization of services and clients. The table below acts as a quick reference guide for configuring GSI in GlideinWMS.

NOTE: The Factory is not required to have proxy (it will authenticate with the WMS Pool by being on the same host and using the file system). Glideins can run using credentials supplied by the Frontend (prefered mode) but can also be configured to run with Factory supplied credentials. If the Factory is configured to not use any GSI credentials, exclude the Factory from the list of condor_config and GSI_DAEMON_NAME in the table below.

Service	Comments
WMS Pool (Collector)	GSI_DAEMON_NAME in condor_config should contain DNs of GlideinWMS Collector. HTCondor Mapfile should contain DNs of WMS Collector, Glidein Frontend, Glidein Factory.
Glidein (Through Glidein Factory)	condor mapfile to be used by glidein startd should contain DN of User Schedds and User Pool. This condor mapfile is not used by the Factory itself but passed over to the glidein via staging area.
User Pool (Collector)	GSI_DAEMON_NAME in condor_config should contain DNs of Glidein Pool Collector, User Schedd Nodes, glidein startd. HTCondor Mapfile should contain DNs of Glidein Pool Collector, User Schedd Nodes, glidein startd, Glidein Frontend
Glidein Frontend	DN of Glidein Frontend should be in the gridmapfile of WMS Pool, User Pool and User Schedds.
User Schedd	GSI_DAEMON_NAME in condor_config should contain DNs of Glidein Pool Collector, User Schedd Node itself, Glidein Frontend, glidein startd HTCondor Mapfile should contain DNs of User Pool, User Schedd Nodes, Glidein Frontend, glidein startd.

2. Required software

3. Installation instructions

The installation will assume you have installed HTCondor v8+ or newer. The install directory is /opt/glidecondor. If you want to use a different setup, make the necessary changes.

Unless explicity mentioned, all operations are to be done as root.

3.1 Install OSG Client

If you have not installed already OSG Client as RPM or tarball, do it now.
(Note: An EGEE/gLite Grid User Interface will work as well, but you need to replace commands and configuration paths with whatever is appropriate for that installation)

See the prerequisites page for instructions on installing the OSG client.

(Please notice that those installation assume that the CA certificates will be installed in /etc/grid-security/certificates. You may have to change that path below if you installed it differently)

3.2 Prepare the security directories and files

Create /opt/glidecondor/certs

mkdir /opt/glidecondor/certs
chmod a+rx /opt/glidecondor/certs

This directory will host the grid-mapfile and eventual service proxy (see below). Note that the RPM installations will use different paths. See the above mentioned documents.

Now you need to select what proxy or certificate you will be used for authentication. You have essentially three options:

You use the host certificates located in /etc/grid-security
You request a service certificate for use with HTCondor, and put it in /opt/glidecondor/certs
You create and maintain a valid proxy, obtained from a personal or service certificate, in /opt/glidecondor/certs. How you keep this proxy valid (via MyProxy, kx509, voms-proxy-init from a local certificate, scp from other nodes, or other methods), is beyond the scope of this document.

Most of my test installations used option(3), but you may be better served with (1) or (2) for a large production pool.

Anyhow, most of the examples in this collection will assume you use (3), with the proxy being named /opt/glidecondor/certs/x509_service_proxy.

Note: The proxy and/or the certificate key must bereadable by the owner only! If it is either group or world readable (and/or writable), HTCondor will refuse to use it (since it could have been stolen and/or compromised by now).

Once you have the proxy or the certificate, you need to create /opt/glidecondor/certs/grid-mapfile and insert the DN of the proxy/cert followed by a symbolic name.

Assuming the DN of the proxy/cert to be "/DC=org/DC=doegrids/OU=Service/CN=mycondor345", you would insert:

"/DC=org/DC=doegrids/OU=Service/CN=mycondor345" condor

The symbolic name is not really important, it has no meaning in Unix space. It is just a nickname you will use in configuration and log files.

In addition to its own DN, the grid-mapfile must contain also the DNs of all the clients and servers that will ever talk to this HTCondor installation:

The DNs of other HTCondor nodes, i.e. the HTCondor Central Manager, the HTCondor Submit nodes and the HTCondor Execute nodes.
If this is a Submit node or Execute node and your users use GSI authentication, you also need to list all the users' DNs.

Again, you will need to add nicknames to those DNs. In the case of a Submit node or Execute node running as root, the user nicknames must represent actual Unix account.

In all other cases, the nicknames have no special meaninig, and are there just for use in configuration and log files.

For example, assuming this is the Central Manager, and it has two Submit nodes, with DNs "/DC=org/DC=doegrids/OU=Service/CN=schedd34" and "/DC=org/DC=doegrids/OU=Service/CN=schedd98", while all the Execute nodes are glideins, and thus share the same DN "/DC=org/DC=doegrids/OU=Service/CN=work12", the /opt/glidecondor/certs/grid-mapfile could be:

"/DC=org/DC=doegrids/OU=Service/CN=mycondor345" condor
"/DC=org/DC=doegrids/OU=Service/CN=schedd34" scondor1
"/DC=org/DC=doegrids/OU=Service/CN=schedd98" scondor2
"/DC=org/DC=doegrids/OU=Service/CN=work12" gcondor

3.3 Configure HTCondor security

Force GSI authentication in /etc/condor/condor_config, by adding:

############################################################
## Security config
############################################################

############################
# Authentication settings
############################
SEC_DEFAULT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = FS,GSI
SEC_READ_AUTHENTICATION = OPTIONAL
SEC_CLIENT_AUTHENTICATION = OPTIONAL

# Grid Certificate directory
GSI_DAEMON_TRUSTED_CA_DIR=/etc/grid-security/certificates

############################
# Privacy settings
############################
SEC_DEFAULT_ENCRYPTION = OPTIONAL
SEC_DEFAULT_INTEGRITY = REQUIRED
SEC_READ_INTEGRITY = OPTIONAL
SEC_CLIENT_INTEGRITY = OPTIONAL
SEC_READ_ENCRYPTION = OPTIONAL
SEC_CLIENT_ENCRYPTION = OPTIONAL

############################
# Set daemon cert location
############################
GSI_DAEMON_DIRECTORY = /opt/glidecondor/certs

# Keep this if you use a proxy
GSI_DAEMON_PROXY = $(GSI_DAEMON_DIRECTORY)/x509_service_proxy

# If you use a Certificate, uncomment below, pointing it to the right place, and comment the proxy line
#GSI_DAEMON_CERT = /etc/grid-security/hostcert.pem
#GSI_DAEMON_KEY = /etc/grid-security/hostkey.pem

############################
# Where to find DN->uid mappings
############################
GRIDMAP=$(GSI_DAEMON_DIRECTORY)/grid-mapfile

Since all the security is now GSI based, we don't rely on IP checks anymore. Change HOSTALLOW_WRITE in /etc/condor/condor_config, to:

# do not use IP based controls
HOSTALLOW_WRITE = *

GlideinWMS The Glidein-based Workflow Management System

Components

GSI Authentication