[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] restricting admin commands



Hello,

Glad you got it working with FS.  I am curious about the Kerberos (AD) setup though because if HTCondor is doing the wrong thing or has bad default behavior I would like to know for future use.  When you are logged in as the root and/or condor user locally, what do you see if you run "klist"?  What about "klist -k"?  Possibly HTCondor could authenticate as one of these principals to do administrative commands.  (The advantage to that would be you could do them remotely if you ever needed to.)

Thanks!


Cheers,
-zach


ïOn 6/3/20, 2:13 PM, "HTCondor-users on behalf of Pezzarossi, Gianni" <htcondor-users-bounces@xxxxxxxxxxx on behalf of gpezza2@xxxxxxxxxxxx> wrote:

    Awesome! Thanks Zach, I got the FS one to work for me, which I'll say is good enough for now since I only care to auth local users.

    I could not get Kerberos to work though, but I think that one made sense, since the user "root" does not exist in our Kerberos (shared Active Directory). Same for the "condor" user, so that actually seems to work as expected since I can't kinit as either of those users. So I guess that was silly to ask initially :-p

    Anyway, thanks again!

    -------------------------------------
    Gianni Pezzarossi
    Computational System Analyst
    User Services:Research
    Engineering IT Shared Services
    University of Illinois @ Urbana-Champaign
    (217)244-7549
    2312 Siebel Center for Computer Science
    engrit-help@xxxxxxxxxxxx

    -----Original Message-----
    From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Zach Miller
    Sent: Tuesday, May 26, 2020 4:25 PM
    To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
    Subject: Re: [HTCondor-users] restricting admin commands

    Hello,

    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:
    	condor_ping ADMINISTRATOR

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


    Cheers,
    -zach



    On 5/22/20, 3:53 PM, "HTCondor-users on behalf of Pezzarossi, Gianni" <htcondor-users-bounces@xxxxxxxxxxx on behalf of gpezza2@xxxxxxxxxxxx> wrote:

        Greetings,
        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
         just root?

        Thanks. (running version 8.8 btw)

        -------------------------------------
        Gianni Pezzarossi
        Computational System Analyst
        User Services:Research
        Engineering IT Shared Services
        University of Illinois @ Urbana-Champaign




    _______________________________________________
    HTCondor-users mailing list
    To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
    subject: Unsubscribe
    You can also unsubscribe by visiting
    https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

    The archives can be found at:
    https://lists.cs.wisc.edu/archive/htcondor-users/

    _______________________________________________
    HTCondor-users mailing list
    To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
    subject: Unsubscribe
    You can also unsubscribe by visiting
    https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

    The archives can be found at:
    https://lists.cs.wisc.edu/archive/htcondor-users/