Authentification par idtoken
Un besoin d'une authentification par idtoken pour l'éxécution de commandes distantes lancées par l'utilisateur
L'authentification par idtoken a été mise en place sur le pool htcondor pour
- permettre aux utilisateurs une authentification distante à certains services du pool htcondor,
- et ainsi permettre à ces utilisateurs d'exécuter des commandes nécessitant des appels vers d'autres machines du pool htcondor que celle sur laquelle la connexion a été établie (Une machine lappui, par exemple).
L'accès à certaines commandes, et les interactions sous-jacentes avec certains services htcondor, étaient en effet impossible avec la seule méthode d'authentification jusqu'alors utilisée : la méthode "FS", qui ne permet de communiquer qu'avec les démons htcondor locaux de la machine sur laquelle l'utilisateur est connectée.
Par exemple, jusqu'à maintenant, si vous aviez soumis des jobs depuis plusieurs Access Points (AP) différents (lappui9a et lappui9b, par exemple), il vous était impossible d visualiser la liste de l'ensemble de ces jobs depuis un des AP, avec la commande condor_q :
- cette commande lancée sans paramètre ne renvoie en effet que la liste des jobs lancés depuis la machine locale sur laquelle vous êtes connectés (lappui9a, par exemple).
- Et la commande lancée avec le paramètre "global" (
condor_q -global) ne pouvait pas aboutir, car les processus lancés pour générer la sortie de cette commande, interrogent des services htcondor résidant sur d'autres machines du pool que celle sur laquelle la commande est lancée. C'est le sens de l'erreur qu'on peut voir ci-dessous:
[pierrot@lappui9c ~]$ condor_q -global
Error: Couldn't contact the condor_collector on
cm01.tests.local.fr?sock=collector, cm02.tests.local.fr?sock=collector.
Extra Info: the condor_collector is a process that runs on the central
manager of your Condor pool and collects the status of all the machines and
jobs in the Condor pool. The condor_collector might not be running, it might
be refusing to communicate with you, there might be a network problem, or
there may be some other problem. Check with your system administrator to fix
this problem.
If you are the system administrator, check that the condor_collector is
running on cm01.tests.local.fr?sock=collector,
cm02.tests.local.fr?sock=collector, check the ALLOW/DENY configuration in
your condor_config, and check the MasterLog and CollectorLog files in your
log directory for possible clues as to why the condor_collector is not
responding. Also see the Troubleshooting section of the manual.
Depuis la mise en place des idtoken, cette commande renvoie les infos sur l'ensemble des jobs de l'utilisateur qui la lance, même si ces jobs ont été lancées sur une autre machine que celle sur laquelle la commande est exécutée.
[pierrot@lappui9a pierrot]$ condor_q -global
-- Schedd: ce04.tests.local.fr : <192.168.96.172:9618?... @ 11/12/25 10:20:31
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
Total for query: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for pierrot: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for all users: 1904 jobs; 0 completed, 0 removed, 316 idle, 1588 running, 0 held, 0 suspended
-- Schedd: ce06.tests.local.fr : <192.168.96.174:9618?... @ 11/12/25 10:20:31
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
Total for query: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for pierrot: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for all users: 1837 jobs; 0 completed, 0 removed, 290 idle, 1547 running, 0 held, 0 suspended
-- Schedd: lapthui9d.tests.local.fr : <192.168.10.188:9618?... @ 11/12/25 10:20:31
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
Total for query: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for pierrot: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for all users: 2 jobs; 0 completed, 0 removed, 0 idle, 2 running, 0 held, 0 suspended
-- Schedd: lappui9a.tests.local.fr : <192.168.10.162:9618?... @ 11/12/25 10:20:31
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
pierrot ID: 13906 11/12 10:16 _ _ 1 _ 1 13906.0
Total for query: 1 jobs; 0 completed, 0 removed, 1 idle, 0 running, 0 held, 0 suspended
Total for pierrot: 1 jobs; 0 completed, 0 removed, 1 idle, 0 running, 0 held, 0 suspended
Total for all users: 1 jobs; 0 completed, 0 removed, 1 idle, 0 running, 0 held, 0 suspended
-- Schedd: lappusmb9a.tests.local.fr : <192.168.96.231:9618?... @ 11/12/25 10:20:31
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
Total for query: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for pierrot: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for all users: 7 jobs; 0 completed, 0 removed, 6 idle, 1 running, 0 held, 0 suspended
-- Schedd: lappusmb9c.tests.local.fr : <192.168.96.228:9618?... @ 11/12/25 10:20:31
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
Total for query: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for pierrot: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
Total for all users: 4 jobs; 0 completed, 0 removed, 3 idle, 1 running, 0 held, 0 suspended
Utilisation des idtoken
Génaration d'un idtoken
Après avoir vu l'utilité d'utiliser l'authentification par "idtoken", voyons comment créer un idtoken. Depuis un serveur lappui, un utilisateur authentifié est autonome pour créer un idtoken avec la commande suivante.
condor_token_fetch -token <tokenname>
Cette commande va créer
- un fichier portant le nom passé en paramètre de la commande (ici 'tokenname'),
- et le placer automatiquement dans le répértoire de l'utilisateur
~/.condor/tokens.d/.
L'identité renfermée dans le token est identique à celle de l'utilisateur connecté sur la machine où a été lancé la commande de création du token.
L'utilisateur peut voir la liste des token en sa possession avec la commande 'condor_token_list'. la sortie affiche les métadonnées associées au token (notamment : identité et emplacement du fichier), comme ci-dessous.
[pierrot@ui03 pierrot]$ condor_token_list
Header: {"alg":"HS256","kid":"POOL"} Payload: {"iat":1758549431,"iss":"tests.local.fr","jti":"22bd332c9b38f7541a84b56735f93a4e","sub":"pierrot@tests.local.fr"} File: /home1/pierrot/.condor/tokens.d/idtoken_maq
Header: {"alg":"HS256","kid":"POOL"} Payload: {"iat":1758548684,"iss":"tests.local.fr","jti":"b3ade2dd0f1607109d110c8c38df47fb","sub":"pierrot@tests.local.fr"} File: /home1/pierrot/.condor/tokens.d/idtokentest
Possibilités offertes au niveau des commandes
Avoir la liste des jobs soumis, quelque soit la machine sur laquelle ils ont été soumis
Dans la sortie de la commande ci-dessous ('condor_q -global'), lancée sur la machine 'ui02', on voit apparaître dans la liste des jobs, un job lancé sur la machine 'ui03'
[pierrot@ui02 pierrot]$ condor_q -global
-- Schedd: ui03.tests.local.fr : <192.168.136.3:9618?... @ 06/30/25 11:40:43
OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS
pierrot ID: 141579 6/30 11:40 _ 1 _ _ 1 1.0
Total for query: 1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended
Total for pierrot: 1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended
Total for all users: 1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended
Informations détaillées sur un job
Pour avoir des informations détaillées sur un job particulier, ci-dessous, celui ayant l'id '41579', on peut utiliser la commande "condor_q" avec le paramètre "-better-analyze", et ainsi facilement trouver les raisons expliquant qu'un job n'est par exemple pas pris en charge par un noeud de calcul, ou qu'il échoue.
Pour avoir cette information même si ce job a été lancé depuis une autre machine que celle depuis laquelle on veut visualiser ces informations, il faut ajouter l'option "-global".
$ condor_q -global -better-analyze 41579
(...)
-- Schedd: lappui9f.tests.local.fr : <192.168.10.175:9618?...
The Requirements expression for job 41579.000 is
((regexp(".*k80.*",TARGET.GPU_MODEL,"i")) ||
(regexp(".*p6000.*",TARGET.GPU_MODEL,"i")) ||
(regexp(".*1g.5gb.*",TARGET.GPU_MODEL,"i"))) && GpuUsageRequirements
Job 41579.000 defines the following attributes:
FileSystemDomain = "condor.must.tests.local.fr"
GpuUsageRequirements = (Machine =!= LastRemoteHost) && (TARGET.Arch == "X86_64") && (TARGET.OpSys == "LINUX") && (TARGET.Disk >= RequestDisk) && (TARGET.Memory >= RequestMemory) && (TARGET.Cpus >= RequestCpus) && (TARGET.GPUs >= RequestGPUs) && ((TARGET.FileSystemDomain == MY.FileSystemDomain) || (TARGET.HasFileTransfer))
RequestCpus = 8
RequestDisk = 102400 (kb)
RequestGPUs = 1
RequestMemory = 8192 (mb)
The Requirements expression for job 41579.000 reduces to these conditions:
Slots
Step Matched Condition
----- -------- ---------
[1] 14 regexp(".*p6000.*",TARGET.GPU_MODEL,"i")
[5] 3 GpuUsageRequirements
[6] 0 [1] && [5]
No successful match recorded.
Last failed match: Fri Sep 19 16:50:31 2025
Reason for last match failure: no match found
41579.000: Run analysis summary ignoring user priority. Of 206 machines,
206 are rejected by your job's requirements
0 reject your job because of their own requirements
0 match and are already running your jobs
0 match but are serving other users
0 are able to run your job
Obtenir des informations sur le status du pool htcondor
Avec la commande condor_status, il est maintenant possible d'obtenir des infos sur le statut du pool: , nom des machines de type GPU, types de GPU, taux d'occupation, caractéristiques d'une machine...
Par exemple, pour connaître la liste des serveurs ayant des cartes graphiques (GPU), le type de carte graphique et le détail de leur disponibilité, on peut utiliser la commande suivante
[pierrot@lappui9a ~]$ condor_status -gpu
Name ST User GPUs GPU-Memory GPU-Name
slot1@wngpu004.local.fr Ui _ 1 15.8 GB Tesla V100-PCIE-16GB
slot1@wngpu005.local.fr Ui _ 1 23.9 GB Quadro P6000
slot1@wngpu006.local.fr Ui _ 4 14.6 GB Tesla T4
slot1@wngpu007.local.fr Ui _ 2 39.5 GB NVIDIA A100-PCIE-40GB
slot1_2@wngpu007.local.fr Cb lafloud@local.fr 1 39.5 GB NVIDIA A100-PCIE-40GB
slot1@wngpu008.local.fr Ui _ 0 39.5 GB NVIDIA A100-PCIE-40GB
slot1_1@wngpu008.local.fr Cb thiboup@local.fr 1 39.5 GB NVIDIA A100-PCIE-40GB
slot1_2@wngpu008.local.fr Cb lafloud@local.fr 1 39.5 GB NVIDIA A100-PCIE-40GB
slot1_3@wngpu008.local.fr Cb lafloud@local.fr 1 39.5 GB NVIDIA A100-PCIE-40GB
slot1@wngpu009.local.fr Ui _ 0 39.5 GB NVIDIA A100-PCIE-40GB
slot1_1@wngpu009.local.fr Cb versoil@local.fr 1 39.5 GB NVIDIA A100-PCIE-40GB
slot1@wngpu010.local.fr Ui _ 3 79.3 GB NVIDIA A100 80GB PCIe
slot1@wngpu011.local.fr Ui _ 2 79.3 GB NVIDIA A100 80GB PCIe
slot1_1@wngpu011.local.fr Cb aliseapo@local.fr 1 79.3 GB NVIDIA A100 80GB PCIe
slot1@wngpu012.local.fr Ui _ 1 79.3 GB NVIDIA A100 80GB PCIe
Pour avoir le détail des informations sur une machine donnée
condor_status -l wn02.tests.must-dcc.fr
Pour avoir une vision de l'état d'occupation des schedulers
pierrot@lapui9a ~]$ condor_status -sched
Name Machine RunningJobs IdleJobs HeldJobs
lapce24.local.fr lapce04.local.fr 2002 243 0
lapce25.local.fr lapce05.local.fr 706 20 0
lapui9a.local.fr lapui9a.local.fr 2 0 0
lapui9b.local.fr lapui9b.local.fr 0 0 0
lappusmb9a.local.fr lappusmb9a.local.fr 1 5 0
lappusmb9b.local.fr lappusmb9b.local.fr 0 0 0
lapthui9c.local.fr lapthui9c.local.fr 0 0 0
lapthui9d.local.fr lapthui9d.local.fr 3 0 0
Sécurité
Un idtoken permet donc de vous identifier auprès du pool htocondor et d'executer des commandes sous votre identité: vous avez d'ailleurs pu voir que les informations renfermées dans l'idtoken font référence à votre identité. La possession de cet idtoken est donc équivalent au fait de connaître votre mot de passe. Il est donc très important de sécuriser l'accès à cet idtoken, pour éviter qu'une personne puisse entrer en sa possession et ainsi executer des commandes sous votre identité.
Par défaut, au moment de leur création, l'accès à un idtoken est sécurisé, puisqu'il est stocké dans votre répertoire personnel, avec des autorisations restrictives, puisque
- vous en êtes le propriétaire
- et que vous êtes le seul à pouvoir le lire,
comme on peut le voir ci-dessous:
[pierrot@ui03 ~]$ ls -al .condor/tokens.d/
total 16
-rw------- 1 pierrot calcul 244 Sep 22 16:18 idtokentest
Une fois un idtoken créé, le plus simple est sans doute de ne pas déplacer, et de ne pas modifier ces autorisations positionnées par défaut, pour ne pas en permettre l'accès à d'autres personnes.
Toutefois, pour minimiser encore un peu plus les risques de sécurité, nous avons pris la décision de regénérer régulièrement la clé servant à signer ces tokens. Cette opération aura pour conséquence de rendre invalides les idtoken ayant été signés avec cette clé, vous confrontant alors à problème d'authentification lors du lancement des commandes pour lesquelles un idtoken valide est requis. Pour éviter de vous poser des questions liées aux messages d'erreur qui pourraient alors survenir, nous vous invitons à supprimer vos idtoken à la fin de vos sessions, et à en regenérer un nouveau à l'ouverture de session: de cette manière, vous disposerez toujours d'un idtoken valide.