[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] restricting admin commands
- Date: Tue, 26 May 2020 21:24:40 +0000
- From: Zach Miller <zmiller@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] restricting admin commands
There are many ways to do this, but If you already have a Kerberos infrastructure set up, that should be fairly easy to use, in theory at least.
First, add these lines to the condor_config:
SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = KERBEROS
SEC_ADMINISTRATOR_AUTHENTICATION = REQUIRED
SEC_ADMINISTRATOR_INTEGRITY = REQUIRED
ALLOW_ADMINISTRATOR = condor@*, root@*
You'll need to reconfig your daemons to have that take effect. (** Note that if the new settings don't work, you won't be able to run reconfig anymore since that itself is an ADMINISTRATOR command! You can always use "service condor stop/start" as root if needed).
The above forces HTCondor to authenticate administrator commands and then only allow them from root or the condor user. Just FYI, the default "host/blah.cs.wisc.edu" Kerberos principal will by default map to "condor" and not "root".
You can also use FS (File System) authentication, which only works locally (because it uses the /tmp directory). This is more lightweight and doesn't use any network traffic or KDC resources. To use that, change the first line to:
SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = FS
Finally, you can tell condor to try FS first, and if that fails (perhaps because you are doing a condor_off to a remote machine) then try Kerberos:
SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = FS, KERBEROS
After making the config changes (and doing the reconfig), test it out by running this as root:
You should hopefully see a line similar to this:
ADMINISTRATOR using (no encryption, MD5, and KERBEROS) succeeded as condor@xxxxxxxxxxx
Then also check that same command as a regular user and you should get something like this:
ADMINISTRATOR failed! Use -verbose for more information.
This is all assuming of course that Kerberos authentication with HTCondor is working. If not, we can debug that, or set things up to use a different authentication method.
As you mentioned, host-based authorization is not very good and would allow bad users to manipulate the system. You should also enable security for DAEMON level authorizations. Assuming you have some authentication method working that is as easy as just doing this:
SEC_DAEMON_AUTHENTICATION_METHODS = KERBEROS
SEC_DAEMON_AUTHENTICATION = REQUIRED
SEC_DAEMON_INTEGRITY = REQUIRED
ALLOW_DAEMON = condor@*, root@*
If you need any help getting authentication working, please let me know. (If it's a more involved or you need to include private information you can submit a ticket to htcondor-admin@xxxxxxxxxxx while we work through the details off-list, and then I post a summary of the results back here for reference. That's up to you though.)
On 5/22/20, 3:53 PM, "HTCondor-users on behalf of Pezzarossi, Gianni" <htcondor-users-bounces@xxxxxxxxxxx on behalf of gpezza2@xxxxxxxxxxxx> wrote:
I have a condor cluster where one system is both the submission machine and central manager and it just struck me that because of default host-based auth, it means all users on the system can use admin-level condor commands (such as condor_userprio).
I am going to see about moving submission to its own system since that simplifies the auth piece, however I wonder if there is another easy way to restrict it so that only root can use admin commands, and all the other users cannot. I tried looking into setting
up one of the authn /authz setups like Kerberos since that is what we use for system login, but I cannot get it to work, plus I donât think it would work with the local root account anyway. Any suggestions as to what I can use to restrict admin commands to
Thanks. (running version 8.8 btw)
Computational System Analyst
Engineering IT Shared Services
University of Illinois @ Urbana-Champaign