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

Re: [HTCondor-users] refreshment of access token fetched in job sandbox



Hi,

this is maybe a bit complex for the list, the rough setup is you need a

SEC_CREDENTIAL_PRODUCER = /var/lib/condor/util/get_token_cmd

on the submit node,

get_token_cmd should perform some checks and then write the token to <stdout>

The receiving host is the CREDD_HOST  which is most likely the SCHEDD_HOST running the credd

If you want todo additional credd manipulation on the sched or on the worker you need to come up with a daemon that will be called by 

SEC_CREDENTIAL_MONITOR

manipulating or shepherding the tokens in

SEC_CREDENTIAL_DIRECTORY

If you want we can maybe discuss this in more depth in a zoom session ?

best
christoph



--
Christoph Beyer
DESY Hamburg
IT-Department

Notkestr. 85
Building 02b, Room 009
22607 Hamburg

phone:+49-(0)40-8998-2317
mail: christoph.beyer@xxxxxxx


Von: "Benoit Roland" <benoit.roland@xxxxxxx>
An: "HTCondor-Users Mail List" <htcondor-users@xxxxxxxxxxx>
Gesendet: Donnerstag, 19. Januar 2023 15:07:55
Betreff: [HTCondor-users] refreshment of access token fetched in job sandbox

Dear all,

our question is related to the refreshment of access token fetched in the job sandbox.

We want to develop a Credential Monitoring component for our particular need, and be able to use the File Transfer Service implemented in HTCondor.

We have developed some preliminary version of this Credential Monitoring plugin, following as guideline the plugins already implemented in [1].

Our strategy for the token management is the following:

1. The user has an oidc-agent configured for a specific OIDC provider [2] and the Mytoken service [3].

2. Before submitting jobs via HTCondor, the user generates a Mytoken via the command line.
   
    This Mytoken is the equivalent of a refresh token: this is the object we manipulate to generate the first access token,
    and to generate further access tokens when refreshment is needed.

    The refreshment procedure is implemented in the Credential Monitoring plugin, via a POST request using the HTTP python library "Requests".

3. Besides the generation of a Mytoken via the command line before jobs submission, this procedure should ensure that the token management is transparent to the user.

Apart from the Credential Monitoring plugin, we also wrote the equivalent of the executable [4] and modified the CMakeLists [5] accordingly.
We also took care to define the following macros we make use of:

DAEMON_LIST
CREDD_HOST
CREDMON_OAUTH
CREDMON_OAUTH_LOG
CREDMON_OAUTH_TOKEN_LIFETIME
SEC_CREDENTIAL_DIRECTORY_OAUTH
SEC_DEFAULT_ENCRYPTION

So far, we were not able to successfully test the implementation of our Credential Monitoring Plugin.

Our question is the following: does the approach described above comply with the strategy implemented in HTCondor?

I went through the credd and file transfer cpp files, but was not able to get a final answer.

As an example, in our approach, we don't need to define the variables "<OAuth2ServiceName>_*" in the HTCondor configuration, neither the "use_oauth_services" in the job jdl file.
All we need is already implemented in the POST request in the Credential Monitoring plugin. We do not even need at all the configuration variables <OAuth2ServiceName>_CLIENT_ID and <OAuth2ServiceName>_CLIENT_SECRET_FILE.

Thanks a lot in advance for your answer and advice!

Kind regards,
Benoit

[1] https://github.com/htcondor/htcondor/tree/main/src/condor_credd/condor_credmon_oauth/credmon/CredentialMonitors
[2] https://login.helmholtz.de/home/
[3] https://mytoken.data.kit.edu/#mt
[4] https://github.com/htcondor/htcondor/blob/main/src/condor_credd/condor_credmon_oauth/condor_credmon_oauth
[5] https://github.com/htcondor/htcondor/blob/main/src/condor_credd/condor_credmon_oauth/CMakeLists.txt


_______________________________________________
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/