Zach Miller Computer Sciences Department University of Wisconsin-Madison zmiller@cs.wisc.edu Securing Condor

  • View
    215

  • Download
    0

Embed Size (px)

Text of Zach Miller Computer Sciences Department University of Wisconsin-Madison zmiller@cs.wisc.edu ...

  • Slide 1

Zach Miller Computer Sciences Department University of Wisconsin-Madison zmiller@cs.wisc.edu http://www.cs.wisc.edu/condor Securing Condor Slide 2 www.cs.wisc.edu/condor Overview Problems With Default Installation Security Policy Configuration Configuring Security Methods Conclusion and Questions Slide 3 www.cs.wisc.edu/condor Problems With Default Installation Host-based granularity is too big Any user who can login to central manager has Administrator privileges Any user on a machine can evict the job on that machine via condor_vacate Slide 4 www.cs.wisc.edu/condor Problems With Default Installation Most connections are NOT authenticated Queue management commands are. Daemon-to-daemon commands are not. It is possible to send false information to the collector and other denials of service Slide 5 www.cs.wisc.edu/condor Problems With Default Installation Traffic is not encrypted or checksummed Possibility of someone eavesdropping on your traffic, including files transferred to or from execute machine Possibility of someone modifying your traffic without detection Slide 6 www.cs.wisc.edu/condor Security Policy Configuration Condor provides many mechanisms to address the previous shortcomings: Many authentication methods Strong encryption Signed checksums for integrity Slide 7 www.cs.wisc.edu/condor Security Policy Configuration Condor will negotiate security requirements and supported methods client server I want to submit a job You must authenticate w/ kerberos KERBEROS normal submit protocol Slide 8 www.cs.wisc.edu/condor Security Policy Configuration Default Policy SEC_DEFAULT_ENCRYPTION = OPTIONAL SEC_DEFAULT_INTEGRITY = OPTIONAL SEC_DEFAULT_AUTHENTICATION = OPTIONAL SEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, SSL, PASSWORD#UNIX SEC_DEFAULT_AUTHENTICATION_METHODS = NTSSPI, KERBEROS, SSL, PASSWORD#WIN32 Slide 9 www.cs.wisc.edu/condor Security Policy Configuration Default Policy Possible Policy Values NEVERdo not allow this to happen OPTIONALdo not request it, but allow it PREFFEREDrequest it, but do not require it REQUIREDthis is mandatory SEC_DEFAULT_ENCRYPTION = OPTIONAL SEC_DEFAULT_INTEGRITY = OPTIONAL SEC_DEFAULT_AUTHENTICATION = OPTIONAL SEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, SSL, PASSWORD#UNIX SEC_DEFAULT_AUTHENTICATION_METHODS = NTSSPI, KERBEROS, SSL, PASSWORD#WIN32 Slide 10 www.cs.wisc.edu/condor Security Policy Configuration YYYX YYYN YYNN XNNN R P O N Required Preferred Optional Never Client Policy Server Policy Policy Reconciliation Slide 11 www.cs.wisc.edu/condor Security Policy Configuration Very Secure Policy SEC_DEFAULT_ENCRYPTION = REQUIRED SEC_DEFAULT_INTEGRITY = REQUIRED SEC_DEFAULT_AUTHENTICATION = REQUIRED SEC_DEFAULT_AUTHENTICATION_METHODS = SSL SSL CONFIGURATION LATER IN THIS TUTORIAL Slide 12 www.cs.wisc.edu/condor Security Policy Configuration Policy Reconciliation Example 1 CLIENT POLICY SEC_DEFAULT_ENCRYPTION = OPTIONAL SEC_DEFAULT_INTEGRITY = OPTIONAL SEC_DEFAULT_AUTHENTICATION = OPTIONAL SEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, SSL, PASSWORD SERVER POLICY SEC_DEFAULT_ENCRYPTION = REQUIRED SEC_DEFAULT_INTEGRITY = REQUIRED SEC_DEFAULT_AUTHENTICATION = REQUIRED SEC_DEFAULT_AUTHENTICATION_METHODS = SSL RECONCILED POLICY ENCRYPTION = YES INTEGRITY = YES AUTHENTICATION = YES METHODS = SSL Slide 13 www.cs.wisc.edu/condor Security Policy Configuration Policy Reconciliation Example 2 CLIENT POLICY SEC_DEFAULT_ENCRYPTION = PREFERRED SEC_DEFAULT_INTEGRITY = OPTIONAL SEC_DEFAULT_AUTHENTICATION = REQUIRED SEC_DEFAULT_AUTHENTICATION_METHODS = SSL, GSI, KERBEROS, PASSWORD SERVER POLICY SEC_DEFAULT_ENCRYPTION = NEVER SEC_DEFAULT_INTEGRITY = PREFERRED SEC_DEFAULT_AUTHENTICATION = OPTIONAL SEC_DEFAULT_AUTHENTICATION_METHODS = FS,GSI,SSL RECONCILED POLICY ENCRYPTION = NO INTEGRITY = YES AUTHENTICATION = YES METHODS = GSI,SSL Slide 14 www.cs.wisc.edu/condor Security Policy Configuration As you can see, you may specify a different policy for each authorization level Another Example Policy SEC_DEFAULT_ENCRYPTION = OPTIONAL SEC_DEFAULT_INTEGRITY = PREFERRED SEC_DEFAULT_AUTHENTICATION = REQUIRED SEC_DEFAULT_AUTHENTICATION_METHODS = FS, GSI, KERBEROS, PASSWORD, SSL SEC_READ_INTEGRITY = OPTIONAL SEC_READ_AUTHENTICATION = OPTIONAL SEC_CLIENT_INTEGRITY = OPTIONAL SEC_CLIENT_AUTHENTICATION = OPTIONAL Slide 15 www.cs.wisc.edu/condor Security Policy Configuration Possible values for authorization levels: CLIENT READ WRITE CONFIG ADMINISTRATOR OWNER DAEMON NEGOTIATOR Slide 16 www.cs.wisc.edu/condor Security Policy Configuration There is now a hierarchy of authorization: READ WRITE DAEMONADMINISTRATOR CONFIG OWNER CLIENT NEGOTIATOR Slide 17 www.cs.wisc.edu/condor Security Policy Configuration Once you have authenticated users, you may use a more fine-grained authorization list: ALLOW_WRITE = zmiller@cs.wisc.edu ALLOW_WRITE = zmiller@cs.wisc.edu/goose.cs.wisc.edu ALLOW_WRITE = zmiller@cs.wisc.edu/*.cs.wisc.edu Slide 18 www.cs.wisc.edu/condor Security Policy Configuration Format of canonical username: user@domain/host One wildcard allowed in the user@domain portion, and one allowed in the host portion Slide 19 www.cs.wisc.edu/condor Security Policy Configuration Usernames can now be mapped with regular expressions. Old GSI mapfile: /C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=Zach Miller/Email=zmiller@cs.wisc.edu zmiller@cs.wisc.edu /C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=Todd Tannenbaum/Email=tannenba@cs.wisc.edu tannenba@cs.wisc.edu Etc. Slide 20 www.cs.wisc.edu/condor Security Policy Configuration New mapfile applies to all types of authentication In your condor_config: SEC_CANONICAL_MAPFILE = /path/to/mapfile Each line is a mapping rule Slide 21 www.cs.wisc.edu/condor Security Policy Configuration Sample map file: CLAIMTOBE.*nobody FS(.*)\1 GSIEmail=(.*)\1 Slide 22 www.cs.wisc.edu/condor Security Policy Configuration Review: The security policy determines which types of security mechanism will be used for a given type of command: SEC_ADMINISTRATOR_AUTHENTICATION = REQUIRED SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = GSI Slide 23 www.cs.wisc.edu/condor Security Policy Configuration Review: The map file gives you a canonical name from the authenticated user: GSIEmail=(.*)\1 /C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin Madison/O=Computer Sciences Department/OU=Condor Project /CN=Zach Miller/Email=zmiller@cs.wisc.edu zmiller@cs.wisc.edu Slide 24 www.cs.wisc.edu/condor Security Policy Configuration Review: The ALLOW_ and DENY_ lists control the authorization of the canonical users: ALLOW_WRITE = *@cs.wisc.edu, zach@otherdomain.com DENY_WRITE = *.evildomain.net Slide 25 www.cs.wisc.edu/condor Configuring Security Methods CLAIMTOBE is not configurable, and is meant for testing purposes only. ANONYMOUS is also not configurable, and always sends the username CONDOR_ANONYMOUS Slide 26 www.cs.wisc.edu/condor Configuring Security Methods FS works by creating a file in /tmp, and checking to see who the owner of that file is. FS_REMOTE is similar, but allows you to specify where to create the file, allowing you to use a directory on NFS or some other shared storage. This is specified like so: FS_REMOTE_DIR = /shared/temp/space Slide 27 www.cs.wisc.edu/condor Configuring Security Methods NTSSPI uses Windows SSPI authentication. This requires that the username and password be the same on two machines that are authenticating to each other. There are no configuration options for this method. Slide 28 www.cs.wisc.edu/condor Configuring Security Methods GSI is the Globus Toolkits implementation of X.509. There are quite a number of configuration options for this which essentially specify which credentials to use, which to expect, and who is allowed to sign the credentials. Slide 29 www.cs.wisc.edu/condor Configuring Security Methods When using GSI, a user typically has a public key (certificate) and a private key that is encrypted with a password. A temporary certificate, called a proxy, is created for use with condor: % grid-proxy-init -cert zmiller.crt -key zmiller.key Your identity: /C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=Zach Miller/Email=zmiller@cs.wisc.edu Enter GRID pass phrase for this identity: Creating proxy............................................... Done Slide 30 www.cs.wisc.edu/condor Configuring Security Methods For the Condor daemons to use GSI authentication, however, they will need either a proxy or a private key with no password. Proxies would need to be valid for a considerable length of time to be useful in this context, so usually a cert/keypair is used. Slide 31 www.cs.wisc.edu/condor Configuring Security Methods GSI_DAEMON_CERT = condor_cred.crt GSI_DAEMON_KEY = condor_cred.key Also, Condor needs to know the public key of any CA that signs certificates: GSI_DAEMON_TRUSTED_CA_DIR=/path/to/keys Slide 32 www.cs.wisc.edu/condor Configuring Security Methods Typically, there is a host credential which is owned by root in: /etc/grid-security/host.crt /etc/grid-security/host.key And also a directory of signing keys in /etc/grid-security/certificates Slide 33 www.cs.wisc.edu/condor Configuring Security Methods Condor will use those defaults without any additional configuration, if it has root privilege to read the host key. Alternatively, you can specify your own directory to hold the key files and the signing certificates by using: GSI_DAEMON_DIRECTORY=~/globus/ Slide 34 www.cs.wisc.edu/condor Configuring Security Methods Since GSI is currently available only on UNIX systems, we have also added support for OpenSSL. It needs essentially the same information as GSI, which is specified in this case with a different set of configuratio