3.7 Setting Up IP/Host-Based Security in Condor

This section describes the mechanisms for setting up Condor's host-based security. This allows you to control what machines can join your Condor pool, what machines can find out information about your pool, and what machines within your pool can perform administrative commands. By default, Condor is configured to allow anyone to view or join your pool. You probably want to change that.

First, we discuss how the host-based security works inside Condor. Then, we list the different levels of access you can grant and what parts of Condor use which levels. Next, we describe how to configure your pool to grant (or deny) certain levels of access to various machines. Finally, we provide some examples of how you might configure your pool.

  
3.7.1 How does it work?

Inside the Condor daemons or tools that use DaemonCore (see section 3.6 on ``DaemonCore'' for details), most things are accomplished by sending commands to another Condor daemon. These commands are just an integer to specify which command, followed by any optional information that the protocol requires at that point (such as a ClassAd, capability string, etc). When the daemons start up, they register which commands they are willing to accept, what to do with them when they arrive, and what access level is required for that command. When a command comes in, Condor sees what access level is required, and then checks the IP address of the machine that sent the command and makes sure it passes the various allow/deny settings in your config file for that access level. If permission is granted, the command continues. If not, the command is aborted.

As you would expect, settings for the access levels in your global config file will affect all the machines in your pool. Settings in a local config file will only affect that specific machine. The settings for a given machine determine what other hosts can send commands to that machine. So, if you want machine ``foo'' to have administrator access on to machine ``bar'', you need to put ``foo'' in bar's config file access list, not the other way around.

  
3.7.2 Security Access Levels

The following are the various access levels that commands within Condor can be registered with:

READ

  Machines with READ access can read information from Condor. For example, they can view the status of the pool, see the job queue(s) or view user permissions. READ access does not allow for anything to be changed or jobs to be submitted. Basically, a machine listed with READ permission cannot join a condor pool - it can only view information about the pool.

WRITE

  Machines with WRITE access can write information to condor. Most notably, it means that it can join your pool by sending ClassAd updates to your central manager and can talk to the other machines in your pool to submit or run jobs. In addition, any machine with WRITE access can request the condor_startd to perform a periodic checkpoint on any job it is currently executing (after a periodic checkpoint, the job will continue to execute and the machine will still be claimed by whatever schedd had claimed it). This allows users on the machines where they submitted their jobs to use the condor_checkpoint command to get their jobs to periodically checkpoint, even if they don't have an account on the remote execute machine.

IMPORTANT: For a machine to join a condor pool, it must have WRITE permission AND READ permission! (Just WRITE permission is not enough).

ADMINISTRATOR

  Machines with ADMINISTRATOR access have special Condor administrator rights to the pool. This includes things like changing user priorities (with ``condor_userprio -set''), turning Condor on and off (``condor_off <machine>), asking Condor to reconfigure or restart itself, etc. Typically you would want only a couple machines in this list - perhaps the workstations where the Condor administrators or sysadmins typically work, or perhaps just your Condor central manager.

IMPORTANT: This is host-wide access we're talking about. So, if you grant ADMINISTRATOR access to a given machine, ANY USER on that machine now has ADMINISTRATOR rights. Therefore, you should grant ADMINISTRATOR access carefully.

OWNER

  This level of access is required for commands that the owner of a machine (any local user) should be able to use, in addition to the Condor administrators. For example the condor_vacate command that causes the condor_startd to vacate any running condor job is registered with OWNER permission, so that anyone can issue condor_vacate to the local machine they are logged into.

NEGOTIATOR

  This is a special access level that means the specified command must come from the Central Manager of your pool. The commands that have this access level are the ones that tell the condor_schedd to begin negotiating and that tell an available condor_startd that it has been matched to a condor_schedd with jobs to run.

  
3.7.3 Configuring your Pool

NEGOTIATOR permission is handled automatically by Condor, and there is nothing special you need to configure. The other four permissions, READ, WRITE, ADMINISTRATOR and OWNER need to be specified in the config files. See the section on Configuring Condor for details on where these files might be located, general information about how to set parameters, and how to reconfigure the Condor daemons.

ADMINISTRATOR access defaults to only your central manager. OWNER access defaults to the local machine, and any machines listed with ADMINISTRATOR access. You can probably leave that how it is. If you want other machines to have OWNER access, you probably want them to have ADMINISTRATOR access as well. By granting machines ADMINISTRATOR access, they would automatically have OWNER access, given how OWNER access is configured.

For these permissions, you can optionally list an ALLOW or a DENY.

• If you have an ALLOW, it means "only allow these machines". No ALLOW means allow anyone.

• If you have a DENY, it means "deny these machines". No DENY means to deny nobody.

• If you have both an ALLOW and a DENY, it means allow the machines listed in ALLOW except for the machines listed in DENY.

Therefore, the settings you might set are:

        HOSTALLOW_READ = <machines>
        HOSTDENY_READ = ...
        HOSTALLOW_WRITE = ...
        HOSTDENY_WRITE = ...
        HOSTALLOW_ADMINISTRATOR = ...
        HOSTDENY_ADMINISTRATOR = ...
        HOSTALLOW_OWNER = ...
        HOSTDENY_OWNER = ...

Machines can be listed by:

• Individual hostnames - example: condor.cs.wisc.edu
• Individual IP address - example: 128.105.67.29
• IP subnets (use a trailing ``*'') - examples: 144.105.*, 128.105.67.*
• Hostnames with a wildcard ``*'' character (only one ``*'' is allowed per name) - examples: *.cs.wisc.edu, sol*.cs.wisc.edu

Multiple machine entries can be separated by either a space or a comma.

For resolving something that falls into both allow and deny: Individual machines have a higher order of precedence than wildcard entries, and hostnames with a wildcard have a higher order of precedence than IP subnets. Otherwise, DENY has a higher order of precedence than ALLOW. (this is intuitively how most people would expect it to work).

In addition, you can specify any of the above access levels on a per-daemon basis, instead of machine-wide for all daemons. You do this with the subsystem string (described in section 3.4.1 on ``Subsystem Names''), which is one of: ``STARTD'', ``SCHEDD'', ``MASTER'', ``NEGOTIATOR'', or ``COLLECTOR''. For example, if you wanted to grant different read access for the condor_schedd:

        HOSTALLOW_READ_SCHEDD = <machines>

  
3.7.4 Access Levels each Daemons Uses

Here are all the commands registered in Condor, what daemon registers them, and what permission they are registered with. With this information, you should be able to grant exactly the permission you wish for your pool:

STARTD:

WRITE

: All commands that relate to a schedd claiming the startd, starting jobs there, and stopping those jobs.

The command that condor_checkpoint sends to periodically checkpoint all running jobs.

READ

: The command that condor_preen sends to find the current state of the startd.

OWNER

: The command that condor_vacate sends to vacate any running jobs.

NEGOTIATOR

: The command that the negotiator sends to match this startd with a given schedd.

NEGOTIATOR:

WRITE

: The command that initiates a new negotiation cycle (sent by the schedd when new jobs are submitted, or someone issues a condor_reschedule).

READ

: The command that can retrieve the current state of user priorities in the pool (what condor_userprio sends).

ADMINISTRATOR

: The command that can set the current values of user priorities (what condor_userprio -set sends).

COLLECTOR:

WRITE

: All commands that update the collector with new ClassAds.

READ

: All commands that query the collector for ClassAds.

SCHEDD:

NEGOTIATOR

: The command that the negotiator sends to begin negotiating with this schedd to match its jobs with available startds.

WRITE

: The command which condor_reschedule sends to the schedd to get it to update the collector with a current ClassAd and begin a negotiation cycle.

The commands that a startd sends to the schedd when it must vacate its jobs and release the schedd's claim.

OWNER

: The command that condor_reconfig_schedd sends to get the schedd to re-read it's config files.

READ

: The ``queue management'' command, which all tools which view the status of the job queue send (such as condor_q, condor_submit, etc). Queue commands that want to write information to the job queue (such as condor_submit or condor_rm) do their own user-level authentication, so you can't update anything in a given ClassAd without being the owner of that ClassAd. Therefore, this command only requires READ access, since any writes are authenticated separately.

MASTER: All commands are registered with ADMINISTRATOR access:

reconfig

: Master and all its children reconfigure themselves

restart

: Master restarts itself (and all its children)

off

: Master shuts down all its children

on

: Master spawns all the daemons it's configured to spawn

master_off

: Master shuts down all its children and exits

  
3.7.5 Access Level Examples

Notice in all these examples that ADMINISTRATOR access is only granted through a HOSTALLOW setting to explicitly grant access to a small number of machines. We recommend this.

• Let anyone join your pool. Only your central manager has administrative access (this is the default that ships with Condor)

  HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST)
  HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
  

• Only allow machines at NCSA to join or view the pool, Central Manager is the only machine with ADMINISTRATOR access.

  HOSTALLOW_READ = *.ncsa.uiuc.edu
  HOSTALLOW_WRITE = *.ncsa.uiuc.edu
  HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST)
  HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
  

• Only allow machines at NCSA and U of I Math department join the pool, EXCEPT do not allow lab machines to do so. Also do not allow the 177.55 subnet (perhaps this is the dial-in subnet). Allow anyone to view pool statistics. Only let "bigcheese" administer the pool (not the central manager).

  HOSTALLOW_WRITE = *.ncsa.uiuc.edu, *.math.uiuc.edu
  HOSTDENY_WRITE = lab-*.edu, *.lab.uiuc.edu, 177.55.*
  HOSTALLOW_ADMINISTRATOR = bigcheese.ncsa.uiuc.edu
  HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
  

• Only allow machines at NCSA and UW-Madison's CS department to view the pool. Only NCSA machines and ``raven.cs.wisc.edu'' can join the pool: (Note: raven has the read access it needs through the wildcard setting in HOSTALLOW_READ). This example also shows how you could use ``\'' to continue a long list of machines onto multiple lines, making it more readable (this works for all config file entries, not just host access entries, see section 3.4 on ``Configuring Condor'' for details).

  HOSTALLOW_READ = *.ncsa.uiuc.edu, *.cs.wisc.edu
  HOSTALLOW_WRITE = *.ncsa.uiuc.edu, raven.cs.wisc.edu
  HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), bigcheese.ncsa.uiuc.edu, \
                            biggercheese.uiuc.edu
  HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
  

• Allow anyone except the military to view the status of your pool, but only let machines at NCSA view the job queues. Only NCSA machines can join the pool. The central manager, bigcheese, and biggercheese can perform most administrative functions. However, only ``biggercheese'' can update user priorities.

  HOSTDENY_READ = *.mil
  HOSTALLOW_READ_SCHEDD = *.ncsa.uiuc.edu 
  HOSTALLOW_WRITE = *.ncsa.uiuc.edu
  HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), bigcheese.ncsa.uiuc.edu, \
                            biggercheese.uiuc.edu
  HOSTALLOW_ADMINISTRATOR_NEGOTIATOR = biggercheese.uiuc.edu
  HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)