29
Greg Quinn Computer Sciences Department University of Wisconsin-Madison [email protected] http://www.cs.wisc.edu/condor Condor on Windows

Greg Quinn Computer Sciences Department University of Wisconsin-Madison [email protected] Condor on Windows

Embed Size (px)

Citation preview

Greg QuinnComputer Sciences Department

University of [email protected]

http://www.cs.wisc.edu/condor

Condor on Windows

www.cs.wisc.edu/condor

Overview

› Latest features› Running jobs as submitting user

› Cross-platform authentication methods (Kerberos, SSL, Password)

› Running condor in an unprivileged account

www.cs.wisc.edu/condor

Running Jobs as the Submitting

User

www.cs.wisc.edu/condor

condor_store_cred add

C:\>condor_store_cred addAccount: gquinn@CROW

Enter password:

Operation succeeded.

›Contacts local schedd and asks it to securely store a user’s password

›Password is placed encrypted in a registry location

y0urs

myp4sswd

www.cs.wisc.edu/condor

condor_store_cred query

C:\>condor_store_cred query

Account: gquinn@CROW

A credential is stored and is valid.

› Checks if password is stored for your user name

› Also makes sure password is up to date (by making sure it can be used to log in)

www.cs.wisc.edu/condor

condor_store_cred delete

C:\>condor_store_cred delete

Account: gquinn@CROW

Enter password:

Operation succeeded.

›Removes password from secure password store

www.cs.wisc.edu/condor

Job Execution: Submit Side

schedd

submit

submit

shadow

y0urs

myp4sswd

Secure Password Store

www.cs.wisc.edu/condor

Job Execution: Execute Side

starter

condor_exec.exe

Jobs run using a Condor-specific account with minimal privileges.condor-reuse-

vm1

www.cs.wisc.edu/condor

Job Execution: Execute Side

starter

condor_exec.exe

y0urs

myp4sswdschedd

VM1_USER = CROW\gquinn

VM2_USER = CROW\gquinn

www.cs.wisc.edu/condor

It’d be nice if…

› My jobs could access my files just like the condor_shadow can

› I didn’t have to tie my execute machines to a single account

› I didn’t have to run condor_store_cred from every machine where my credential is needed

www.cs.wisc.edu/condor

The Windows CredD

y0urs

myp4sswd

C:\>condor_store_cred addAccount: gquinn@CROW

Enter password:

Operation succeeded.

credd

›A centralized repository for user passwords

“store password”

<password>

www.cs.wisc.edu/condor

The Windows CredD

y0urs

myp4sswdschedd

shadowSubmit machines can use the CredD to impersonate the user in the shadow

“fetch password”

<password>

www.cs.wisc.edu/condor

The Windows CredD

y0urs

myp4sswdstarter

condor_exec.exeExecute machines can use the CredD to run jobs as the submitting user!

“fetch password”

<password>

www.cs.wisc.edu/condor

Running Jobs as Submitting User

universe = vanillaexecutable = whoami.exelog = whoami.logoutput = whoami.out

run_as_owner = true

queue

›Example submit file:

www.cs.wisc.edu/condor

Running Jobs as Submitting User

CREDD_HOST = vault.cs.wisc.edu

STARTER_ALLOW_RUNAS_OWNER = True

CREDD_CACHE_LOCALLY = True

SEC_CLIENT_AUTHENTICATION_METHODS = \ NTSSPI, PASSWORD

›In config file on submit and execute nodes:

www.cs.wisc.edu/condor

Running Jobs as Submitting User

›See example config file included with Condor: condor_config.local.credd

# Set security settings so that full security to the credd is requiredCREDD.SEC_DEFAULT_AUTHENTICATION =REQUIREDCREDD.SEC_DEFAULT_ENCRYPTION = REQUIREDCREDD.SEC_DEFAULT_INTEGRITY = REQUIREDCREDD.SEC_DEFAULT_NEGOTIATION = REQUIRED

# Require PASSWORD auth for password fetchingCREDD.SEC_DAEMON_AUTHENTICATION_METHODS = PASSWORD

# Only honor password fetch requests to the trusted "condor_pool" userCREDD.ALLOW_DAEMON = condor_pool@($UID_DOMAIN)

www.cs.wisc.edu/condor

Securing the CredD

y0urs

myp4sswd

C:\>condor_store_cred addAccount: gquinn@CROW

Enter password:

Operation succeeded.

credd

› NTSSPI can be used to authenticate to CredD and send the password encrypted over the network

“store password”

www.cs.wisc.edu/condor

Securing the CredD

y0urs

myp4sswdstarter

condor_exec.exe

“fetch password”

Condor normally runs as SYSTEM, and therefore can’t use NTSSPI

www.cs.wisc.edu/condor

Securing the CredD

› Options for securing password fetch operations

•Kerberos / SSL authentication

•Password authentication

•Run the Condor service as a normal account and use NTSSPI

www.cs.wisc.edu/condor

Password Authentication

www.cs.wisc.edu/condor

Password Authentication

›Mutual authentication of Condor daemons possessing a shared “pool password”

›Good for small pools where more heavyweight methods aren’t desirable

www.cs.wisc.edu/condor

Password Authentication

› Pool password can be stored with new “-c” argument to condor_store_cred

› Can also be done remotely with “-n” argument

C:\> condor_store_cred –c add

C:\> condor_store_cred –n crow.cs.wisc.edu –c add

www.cs.wisc.edu/condor

Using an Unprivileged Account for

Condor

www.cs.wisc.edu/condor

Personal Condor

›Allows creating a 1-machine Condor pool as any user

C:\> SET CONDOR_CONFIG=c:\condor\condor_config

C:\> condor_master -f

www.cs.wisc.edu/condor

Unprivileged Service

›Condor still runs using the Service Control Manager (SCM)

www.cs.wisc.edu/condor

Uncovered Questions?

www.cs.wisc.edu/condor

Windows BOF

›Thursday, 11:30 - 12:30›Room 219

www.cs.wisc.edu/condor

Questions?

www.cs.wisc.edu/condor

condor_store_credC:\>condor_store_cred add

Account: gquinn@CROW

Enter password:

Operation failed.

Make sure your HOSTALLOW_WRITE setting includes this host.

›Indicates communications error between condor_store_cred and the schedd