1 / 49

Securing Condor

Securing Condor. Overview. General Authorization Mechanisms Host-based Authorization (Default) Problems With Default Installation Security Policy Configuration Configuring Security Methods Conclusion and Questions. Authorization. Condor users ALLOW / DENY lists to control authorization

ismaelv
Download Presentation

Securing Condor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Securing Condor

  2. Overview • General Authorization Mechanisms • Host-based Authorization (Default) • Problems With Default Installation • Security Policy Configuration • Configuring Security Methods • Conclusion and Questions

  3. Authorization • Condor users ALLOW / DENY lists to control authorization • There are different levels of access in Condor, and each can have a separate authorization list and security policy.

  4. Authorization • Possible values for authorization levels: • CLIENT • READ • WRITE • CONFIG • ADMINISTRATOR • OWNER • DAEMON • NEGOTIATOR

  5. Authorization There is also a hierarchy of authorization levels: NEGOTIATOR ADMINISTRATOR DAEMON WRITE CONFIG OWNER CLIENT READ

  6. Authorization • There is a separate ALLOW / DENY list for each authorization level. • DENY takes preference over ALLOW HOSTALLOW_READ = * HOSTALLOW_WRITE = *.cs.wisc.edu HOSTALLOW_ADMINISTRATOR = condor.cs.wisc.edu HOSTDENY_WRITE = zeroday.cs.wisc.edu

  7. Host-based Authorization • This is the default setup, which has some shortcomings but is easy to configure. • Allows you to specify capabilities by hostname, IP address, and/or subnet.

  8. Host-based Authorization • Examples: HOSTALLOW_WRITE = * HOSTALLOW_WRITE = goose.cs.wisc.edu HOSTALLOW_WRITE = *.cs.wisc.edu HOSTALLOW_WRITE = 128.105.* HOSTALLOW_WRITE = 128.105.0.0/16

  9. Host-based Authorization • Each entry is a comma-separated list. • Wildcards are allowed only at the beginning of hostnames or at the end of IP addresses. • Subnets are supported using a / and number of significant bits. HOSTALLOW_WRITE = *.cs.wisc.edu, *.engr.wisc.edu HOSTALLOW_WRITE = 128.105.*, *.engr.wisc.edu, 128.105.64.0/18

  10. Problems With Default Installation • Host-based granularity is too big • Any user who can login to central manager has “Administrator” privileges HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST) • Any user on an execute machine can evict the job on that machine via condor_vacate HOSTALLOW_OWNER = $(FULL_HOSTNAME)

  11. Problems With Default Installation • Most connections are NOT authenticated • Queue management commands (condor_submit, condor_hold, etc.) are because Condor explicitly forces authentication. • Daemon-to-daemon commands are not. • It is possible to send false information to the collector and other denials of service

  12. Problems With Default Installation • Traffic is not encrypted or checked for integrity. • Possibility of someone eavesdropping on your traffic, including files transferred to or from execute machine • Possibility of someone modifying your traffic without detection

  13. Security Policy Configuration • Condor provides many mechanisms to address the previous shortcomings: • Many authentication methods • Strong encryption • Signed checksums for integrity

  14. Security Policy Configuration • Condor will negotiate security requirements and supported methods server client I want to submit a job You must authenticate w/ kerberos KERBEROS normal submit protocol

  15. 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

  16. Security Policy Configuration Default Policy Possible Policy Values NEVER do not allow this to happen OPTIONAL do not request it, but allow it PREFFERED request it, but do not require it REQUIRED this 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

  17. Security Policy Configuration Policy Reconciliation Server Policy R P O N Required Preferred Client Policy Optional Never

  18. 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

  19. 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

  20. 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

  21. Security Policy Configuration Another Example Policy • As you can see, you may specify a different policy for each authorization level 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

  22. 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

  23. 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 • If there is no ‘/’ character, Condor will do one of two things: • If there is an ‘@’ character, it is assumed to be a username, and maps to user@domain/* • If there is no ‘@’, it is assumed to be a hostname and maps to */hostname

  24. 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.

  25. Security Policy Configuration • New map file applies to all types of authentication, not just GSI. • In your condor_config: CERTIFICATE_MAPFILE = /path/to/mapfile • Each line is a mapping rule • Each rule has three fields: method regex mapped_name

  26. Security Policy Configuration • Default map file: (each line is <method> <regex> <mappedname>) • RegEx matches and sub-matches can be referenced using \1, \2, etc. FS (.*) \1 FS_REMOTE (.*) \1 GSI (.*) GSS_ASSIST_GRIDMAP (Special Token to call Globus) SSL (.*) \1 KERBEROS (.*) \1 NTSSPI (.*) \1 CLAIMTOBE (.*) \1 ANONYMOUS (.*) CONDOR_ANONYMOUS PASSWORD (.*) \1

  27. 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

  28. Security Policy Configuration • Review: • The map file gives you a canonical name from the authenticated user: GSI Email=(.*) \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

  29. 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

  30. 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”

  31. Configuring Security Methods FS works by creating a directory and checking to see who the owner of that directory is. By default, it is created in /tmp, but this path can be overridden using FS_LOCAL_DIR in the condor_config. client Created a directory called /tmp/FS_qN21p4 mkdir(“/tmp/FS_qN21p4”); Done, check the owner Success/Failure rmdir(“/tmp/FS_qN21p4”);

  32. Configuring Security Methods FS_REMOTE is similar to FS, but is intended for shared file systems. To this end, it has some extra steps to help insure the file system is synchronized between the two machines. FS_REMOTE_DIR must be specified in the condor_config. Created a directory called /tmp/FS_qN21p4 client mkdir(“/tmp/FS_qN21p4”); Done, check the owner mkdir(“/tmp/FS_bl4hB3eF”); rmdir(“/tmp/FS_bl4hB3eF”); Success/Failure rmdir(“/tmp/FS_qN21p4”);

  33. 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.

  34. Configuring Security Methods GSI is the Globus Toolkit’s 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.

  35. 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

  36. 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.

  37. 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

  38. 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

  39. 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=/home/condor/credentials

  40. 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 configuration parameters: AUTH_SSL_SERVER_CAFILE AUTH_SSL_SERVER_CADIR AUTH_SSL_SERVER_CERTFILE AUTH_SSL_SERVER_KEYFILE AUTH_SSL_CLIENT_CAFILE AUTH_SSL_CLIENT_CADIR AUTH_SSL_CLIENT_CERTFILE AUTH_SSL_CLIENT_KEYFILE

  41. Configuring Security Methods Example SSL config: #Creds to use as server AUTH_SSL_SERVER_CAFILE = /scratch/zmiller/ssl_keys/root-ca.crt AUTH_SSL_SERVER_CERTFILE = /scratch/zmiller/ssl_keys/host.crt AUTH_SSL_SERVER_kEYFILE = /scratch/zmiller/ssl_keys/host.key #Creds to use as client AUTH_SSL_CLIENT_CAFILE = /scratch/zmiller/ssl_keys/root-ca.crt AUTH_SSL_CLIENT_CERTFILE = /scratch/zmiller/ssl_keys/host.crt AUTH_SSL_CLIENT_kEYFILE = /scratch/zmiller/ssl_keys/host.key For instructions on creating these certificates and keys using the openssl tool, please see: http://www.cs.wisc.edu/~alderman/ca_chain_directions/staff_ca_chain_setup_notes.html Or, attend the Security BOF on Thursday at 3:00pm.

  42. Configuring Security Methods For both GSI and OpenSSL, you can use the openssl command line tool to create all the necessary keys and files. Also, you will almost certainly want to use the condor map file functionality to map your SSL and GSI subject names to users. For more detailed info on that, please see the openssl man page, or come to the security BOF Thursday @ 3:00.

  43. Configuring Security Methods KERBEROS is available on both UNIX and Windows platforms, and is currently version 1.4.3. On UNIX, it authenticates against a KDC (Kerberos Domain Controller). On Windows, the Active Directory server fills this role. Windows->Unix and Unix->Windows Kerberos authentication is now possible.

  44. Configuring Security Methods For Kerberos, a user may need to run kinit if that is not part of the normal login process: % kinit zmiller@CS.WISC.EDU Password for zmiller@CS.WISC.EDU: % klist Ticket cache: FILE:/var/adm/krb5/tmp/tkt/tkt_24842_pid19635 Default principal: zmiller@CS.WISC.EDU Valid starting Expires Service principal 04/30/07 09:17:13 05/30/07 09:17:13 krbtgt/CS.WISC.EDU@CS.WISC.EDU

  45. Configuring Security Methods The Condor daemons can use the “host credential” if they are running as root. The default keytab file is typically in /etc/v5srvtab and contains a credential similar to: host/goose.cs.wisc.edu@CS.WISC.EDU Alternatively, you can specify your own keytab file and server principal to use: KERBEROS_SERVER_KEYTAB = /scratch/zmiller/keytab.zmiller KERBEROS_SERVER_PRINCIPAL = zmiller/condor@CS.WISC.EDU

  46. Configuring Security Methods PASSWORD authentication also works on both UNIX and Windows, although the interface is somewhat different. On Windows, the password is stored in a secure part of the registry. On UNIX, the password is stored in a root-owned file specified by: SEC_PASSWORD_FILE = /path/to/file

  47. Configuring Security Methods To set the pool password, use the condor_store_cred command with -c: condor_store_cred –c add

  48. Conclusion Now you have seen a general overview of the different methods that Condor supports, how to configure them, and how to set policy so they get used where you want them.

  49. Questions? Check the manual: http://www.cs.wisc.edu/condor/manual/v6.9.2/3_6Security.html Don’t forget the security BOF, Thursday @ 3:00!

More Related