Security
The following new features affect cluster security.
New administration command to start and stop LSF daemons
LSF now has a new, separate administration command, bctrld, to start and stop LSF daemons (LIM, RES, and sbatchd).
The bctrld executable file, which is owned by root, is installed with the setuid flag turned off and this command can be used only by root. To allow non-root users (such as LSF administrators) to run the bctrld command to start the LSF daemons, you must either add the non-root users to the sudo Linux group or enable the setuid flag and configure the non-root users in the lsf.sudoers file.
This command moves all the LSF daemon start, stop, and restart administration subcommands into one separate command. The old administration subcommands are now obsolete and will be deprecated in a future release. The bctrld command syntax is identical to the old administration subcommands. The following table lists the old administration subcommands that the bctrld replaces:
| Old LSF administration subcommand | New bctrld subcommand |
|---|---|
| badmin hrestart | bctrld restart sbd |
| badmin hshutdown | bctrld stop sbd |
| badmin hstartup | bctrld start sbd |
| lsadmin limrestart | bctrld restart lim |
| lsadmin limshutdown | bctrld stop lim |
| lsadmin limstartup | bctrld start lim |
| lsadmin resrestart | bctrld restart res |
| lsadmin resshutdown | bctrld stop res |
| lsadmin resstartup | bctrld start res |
The bctrld command syntax follows the general format of bctrld action daemon_name options.
Moving the LSF daemon start and stop actions to a separate command means that LSF administration commands no longer require root privileges. Therefore, the LSF installer no longer enables the setuid bit for the LSF administration commands (badmin, lsadmin, egosh, utmpreg, swtbl_api, ntbl_api, lstbl_nid, and swtbl_poe), so the LSF commands no longer run with root privileges. This increases the security of your cluster by preventing unauthorized use of root privileges.
Restrict user access to the lsmake command
LSF can now restrict users from using the lsmake command to run make tasks on remote hosts.
To enable LSF to restrict users from using the lsmake command, set the existing parameter LSF_DISABLE_LSRUN parameter to Y in the lsf.conf file. This parameter enables the LSF RES process to refuse remote connections from the lsrun and lsgrun commands unless the user is either an LSF administrator or root, but this parameter now also enables RES to refuse remote connections from the lsmake command.
This increases cluster security by preventing unauthorized users from accessing remote hosts.
Kerberos user impersonation
LSF can now use Kerberos user impersonation to submit jobs as the authenticated Kerberos TGT user.
To enable Kerberos user impersonation, first enable user eauth with krb5, then set the new LSB_KRB_IMPERSONATE parameter to Y in the lsf.conf file. For the blaunch command to work when user eauth with krb5 is enabled, you must also set LSF_EAUTH_DATA_REUSE=N in the lsf.conf file.
Run the Kerberos command kinit -r user_name to obtain a user TGT for the submission user to impersonate. When submitting a job, LSF changes the OS submission user on the job execution host to this TGT user.
If Kerberos user impersonation is enabled, the following LSF commands work differently:
- If the token user is not the OS submission user, commands that depend on OS file permissions (such as bpeek and brestart) do not work properly.
- The ACL feature for the bacct and bhist commands is disabled to prevent other users from getting the LSF administrator token. To ensure that the commands remain secure, do not enable the setuid bit for the bacct and bhist executable files, and disable them if they are already set.
- The lsrun command might behave inconsistently between running on local and remote hosts, because when an lsrun task is run on the local host, it does not go through eauth authorization.
Secured authorization requests
LSF can now add a checksum to each authorization request that is sent to LSF. This ensures that any authorization request that is sent to LSF is identified if it is modified, which prevents users from changing either the user credential or the content of the LSF authentication requests.
To enable checksum-secured authorization requests, set the value of the existing LSF_STRICT_CHECKING parameter in the lsf.conf file to ENHANCED. This new keyword also enables the existing feature of strict checking for communications between LSF daemons and between LSF commands and daemons that exists when LSF_STRICT_CHECKING is set to Y.
You must set to the LSF_STRICT_CHECKING parameter to the same value in the entire cluster, as it affects all communications within LSF. If it is used in a MultiCluster environment, it must either be set to the same value in all clusters, or not set in any cluster. Ensure that all binaries and libraries are upgraded to LSF Version 10.1 Fix Pack 11, including LSF_BINDIR, LSF_SERVERDIR, and LSF_LIBDIR directories, if you enable this parameter.
Authentication of query commands
LSF can now use authentication for query commands when external authentication is enabled.
To enable query command authentication, set the new LSF_AUTH_QUERY_COMMANDS parameter to Y in the lsf.conf file. Use the LSF_AUTH parameter in the lsf.conf file to specify the external client to server authentication method that is used.
After changing the value of the LSF_AUTH_QUERY_COMMANDS parameter, you must restart the mbatchd and gpolicyd daemons for this parameter to take effect.
- Before enabling query command authentication in the LSF cluster, you must ensure that all hosts in the cluster (including management, server, and client hosts), including all LSF command executable files, are updated to LSF, Version 10.1 Fix Pack 11, or newer. If you have any commands that are built using the APIs from previous versions of LSF, you must also rebuild these commands with the APIs from this latest version of LSF.
- If you are enabling query command authentication for the LSF multicluster capability, ensure that all LSF clusters use the same LSF_EAUTH_KEY value in the lsb.sudoers file.