Summary: | Slurm REST and JWKS support | ||
---|---|---|---|
Product: | Slurm | Reporter: | timeu <uemit.seren> |
Component: | slurmctld | Assignee: | Nate Rini <nate> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | 4 - Minor Issue | ||
Priority: | --- | CC: | erich.birngruber, tim, uemit.seren |
Version: | 22.05.8 | ||
Hardware: | Linux | ||
OS: | Linux | ||
See Also: | https://bugs.schedmd.com/show_bug.cgi?id=16586 | ||
Site: | IMP | Alineos Sites: | --- |
Atos/Eviden Sites: | --- | Confidential Site: | --- |
Coreweave sites: | --- | Cray Sites: | --- |
DS9 clusters: | --- | HPCnow Sites: | --- |
HPE Sites: | --- | IBM Sites: | --- |
NOAA SIte: | --- | OCF Sites: | --- |
Recursion Pharma Sites: | --- | SFW Sites: | --- |
SNIC sites: | --- | Linux Distro: | --- |
Machine Name: | CLE Version: | ||
Version Fixed: | 23.02.6,23.11.0rc1 | Target Release: | --- |
DevPrio: | --- | Emory-Cloud Sites: | --- |
Description
timeu
2023-03-02 05:53:17 MST
We are reviewing your request and should respond soon. (In reply to timeu from comment #0) > 1.) However out of the box Slurm can't validate the JWT because the code > in > https://github.com/SchedMD/slurm/blob/slurm-22-05-8-1/src/plugins/auth/jwt/ > auth_jwt.c#L293 looks for a JWKS key with the corresponding kid and the alg > set to "RS256". The jwks.json file that you receive from the AzureAD OIDC > application endpoint(see as an example: > https://login.microsoftonline.com/35e19b4a-02bb-4975-aaba-acc04ac3ebaf/ > discovery/v2.0/keys) does not contain this field. Accoridng to the spec > (see: https://www.rfc-editor.org/rfc/rfc7517#section-4.4) this field is > optional. So if we use the jwks.json file provided by the OIDC endpoint, the > SLURM Rest call will fail with "error: could not find matching kid or decode > failed" > As a workaround we manually added "alg":"RS256" to the keys in the jwks.json > file and the SLURM Rest call was successful. > > Is the check for alg == RS256 really necessary if it is anyway matched by > the "kid" which should be unique ? Looking into how best to handle "alg" not being set. > 2.) Currently one has to download the JWKS keys manually and put them to a > location where slurmdbd and slurmctld can access them. However it would be > an enhancement if Slurm would accept an URL instead for either the "OpenID > Connect metadata document" (see: > https://login.microsoftonline.com/35e19b4a-02bb-4975-aaba-acc04ac3ebaf/v2.0/. > well-known/openid-configuration) which contains the URL to the jwks keyfile > or the URL to the jwks keyfile itself. > Additionally these JWKS keys are/can be roatated. It would be a nice > enhancement if Slurm would check if it can match the kid and if not maybe > retrieve the rotated JWKS keys from the above mentioned well known URLs. There are currently no plans to implement automated retrieval of the JWKS keys. > 3.) If the above is not possible. It would be nice if the JWKS keys would be > re-loaded from disk via a systemctld reload slurmctld/slurmdbd instead of a > restart. This is an area of possible changes for the next major release. (In reply to Nate Rini from comment #4) > Looking into how best to handle "alg" not being set. We are preparing a corrective patch to honor "alg" being optional. We have modified auth/jwt to ignore the 'alg' field not existing for the upcoming Slurm-23.02.6 release:
> https://github.com/SchedMD/slurm/commit/19f42376749a0dd8c9fd6cbdfbc15c57fcd70c3b
This should resolve the issue with the Azure AD JWKS file. Please reply if there are any more questions or related issues.
|