Re: [HTCondor-users] idtoken capabilities for status queries?

[Jaime Frey <jfrey@xxxxxxxxxxx>]

It looks like what you have should work. The READ authorization is the important one in the token for queries. What shows up in the collector log when one of these commands fails? Are the EP and AP daemons able to advertise to the collector with these tokens?

Regarding HA, both CMs should have the same TRUST_DOMAIN value (which should look like a single DNS host or domain name) and the same signing keys (using the same filenames in /etc/condor/passwords.d/). That way, any token can be validated by either CM.

 - Jaime

> On Apr 5, 2024, at 8:14âAM, Thomas Hartmann <thomas.hartmann@xxxxxxx> wrote:
> 
> Hi all,
> 
> to get rid of old habits, we have dropped now in our pre-production cluster passwords etc. in favour of IDTOKENs only.
> 
> In principle, execution and access points can connect to the central manager [1]. However, I have not managed yet to identify the correct token capabilities and ALLOW_* to allow from each daemon to query the cluster status, i.e., to be able to run `condor_status` from each node.
> 
> The tokens I tried so far have the points' daemon flavor, master announce as well as read and advertise [1]. And the token identities have been added to the corresponding rule sets [2].
> 
> But still I am not able to query the central manager from a client
> 
> [root@batch1504 ~]# condor_status
> Error: communication error
> SECMAN:2010:Received "DENIED" from server for user executionpoint-grid@xxxxxxx using method IDTOKENS.
> 
> I toyed also with the client role assuming that a EP or AP would count as server(?) when querying the central manager (becoming a client??) - but also without success so far.
> 
> As side question: in a HA set up, is it sufficient to keep the signing key the same on both central manager nodes - or would one has to sync created tokens as well (I would assume that the fallback CM should be able to validate tokens created on the active CM with the symmetric key, or?)
> 
> Cheers and thanks for ideas,
>  Thomas
> 
> 
> [1]
> > condor_token_create -identity accesspoint-condorce-grid@xxxxxxx -authz ADVERTISE_SCHEDD -authz ADVERTISE_MASTER -authz READ  -authz ADVERTISE -authz CLIENT -token accesspoint-condorce-grid
> 
> > condor_token_list
> ...
> Header: {"alg":"HS256","kid":"POOL"} Payload: {"iat":1234,"iss":"desy.de","jti":"56789","scope":"condor:\/ADVERTISE_STARTD condor:\/ADVERTISE_MASTER condor:\/READ condor:\/ADVERTISE condor:\/CLIENT","sub":"executionpoint-grid@xxxxxxx"} File: /etc/condor/tokens.d/executionpoint-grid
> 
> 
> 
> [2]
> ALLOW_ADMINISTRATOR = $(CONDOR_HOST), $(IP_ADDRESS)
> ALLOW_ADVERTISE = *.desy.de  executionpoint-grid@xxxxxxx accesspoint-condorce-grid@xxxxxxx
> ALLOW_CLIENT = *
> ALLOW_CONFIG = batch*.desy.de grid*.desy.de
> ALLOW_DAEMON = *.desy.de  executionpoint-grid@xxxxxxx accesspoint-condorce-grid@xxxxxxx
> ALLOW_NEGOTIATOR = *.desy.de
> ALLOW_READ = *.desy.de  executionpoint-grid@xxxxxxx accesspoint-condorce-grid@xxxxxxx
> ALLOW_SUBMIT_FROM_KNOWN_USERS_ONLY = false
> ALLOW_TRANSFER_REMAP_TO_MKDIR = true
> ALLOW_WRITE = *.$(UID_DOMAIN)
>