next up previous contents
Next: 3.7 Setting up Condor Up: 3 Administrators' Manual Previous: 3.5 DaemonCore

Subsections

3.6 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.6.1 How does it work?

  Inside the Condor daemons or tools that use DaemonCore (see section 3.5 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.6.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.6.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.

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:

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.3.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.6.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.6.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.

next up previous contents
Next: 3.7 Setting up Condor Up: 3 Administrators' Manual Previous: 3.5 DaemonCore
Derek Wright
5/22/1998