Procédure Pour: administrateurs

Authentification unique

Connecter un fournisseur d'identité OpenID Connect dans la console, donner des rôles à ses groupes et se connecter avec un compte d'organisation.

Kyvernon connecte les utilisateurs par un fournisseur d'identité qui parle OpenID Connect. Il utilise le flux de code d'autorisation avec PKCE et lit les groupes de l'utilisateur dans un claim du jeton d'identité. Le fournisseur effectue l'authentification, y compris son propre second facteur. Vous avez besoin du privilège Global.Settings sur la racine.

Avant de commencer, enregistrez Kyvernon comme client chez le fournisseur et notez l'adresse de l'émetteur, l'identifiant du client et le secret du client. Faites en sorte que le fournisseur envoie les groupes de l'utilisateur dans un claim, groups par défaut, par exemple avec la portée groups. Conservez l'administrateur local et le compte de secours (break-glass) : ils donnent accès quand le fournisseur est indisponible.

Dans la console

  1. Ouvrez le Menu utilisateur en haut à droite, sélectionnez Administration, puis dans la liste de gauche sélectionnez Authentification unique. Le titre Fournisseur d’identité indique l'état, Configuré ou Non configuré.

    Paramètres de l'authentification unique pour un fournisseur OpenID Connect (Agrandir)
  2. Saisissez l'URL de l’émetteur : l'adresse https du fournisseur. Kyvernon lit le document de découverte à <issuer>/.well-known/openid-configuration.
  3. Saisissez le Identifiant client et le Secret client que le fournisseur vous a donnés. Le secret est conservé et n'est plus jamais affiché. Quand un secret est conservé, laissez le champ vide pour le garder, ou saisissez-en un nouveau pour le remplacer.
  4. Vérifiez la URI de redirection. La console renseigne l'adresse sous laquelle vous l'avez atteinte, et vous enregistrez exactement cette adresse chez le fournisseur.
  5. Sous Portées, listez les portées en plus de openid, séparées par des espaces, par exemple profile email groups. Sous Revendication des groupes, indiquez le claim qui contient les noms de groupes. Sous Délai pour terminer la connexion (minutes), saisissez un nombre entier de 1 à 60.
  6. Sélectionnez Enregistrer.

La page de connexion propose maintenant le bouton Se connecter avec votre organisation, ou Se connecter avec ... avec le nom d'hôte de l'émetteur, au-dessus de la ligne ou utilisez un compte local et du formulaire de connexion locale. Un utilisateur sélectionne le bouton, se connecte chez le fournisseur et revient à la console.

Un utilisateur fédéré n'a d'abord aucun rôle. Donnez un rôle au groupe que le fournisseur envoie : sur l'écran Autorisations, ajoutez une autorisation pour le Groupe dont le nom est la valeur du claim des groupes, comme décrit dans Rôles et autorisations.

Pour arrêter la connexion par le fournisseur, sélectionnez Supprimer le fournisseur et confirmez. Les comptes restent et la connexion locale continue de fonctionner ; assurez-vous donc d'abord qu'au moins un administrateur local peut se connecter.

Note

L'écran nécessite un plan de contrôle qui propose ce paramètre. Sur un plan de contrôle qui ne le propose pas, il affiche Pas encore disponible sur ce plan de contrôle ; la section Automatisation décrit la méthode qui fonctionne aujourd'hui.

Résultat

Les personnes du fournisseur se connectent avec le compte d'organisation. Un compte fédéré est créé à la première connexion, avec le nom d'utilisateur préféré du fournisseur en minuscules comme nom d'utilisateur, ou oidc:<subject> quand le fournisseur n'en envoie aucun. Kyvernon met à jour les groupes, l'adresse e-mail et le nom affiché à chaque connexion ; un changement de groupe chez le fournisseur s'applique donc à la connexion suivante, et un utilisateur que vous désactivez reste refusé. Un utilisateur fédéré dont le nom est identique à celui d'un utilisateur local est refusé, afin qu'un compte local ne puisse pas être repris. Le journal d'audit consigne chaque connexion sous identity.login.oidc avec l'émetteur ; voir Sessions et audit.

La CLI se connecte avec un mot de passe ou un jeton ; un utilisateur fédéré qui a besoin de la CLI demande donc un jeton d'API à un administrateur.

Automatisation

Avec la CLI

Le fournisseur se définit de façon native, sans modifier le fichier de configuration. Affichez le réglage actuel, définissez le fournisseur et supprimez-le :

Shell
kyvernon users oidc
kyvernon users set-oidc --issuer https://idp.example.com --client-id kyvernon \
  --client-secret-file /root/oidc-secret \
  --redirect-uri https://controller.example.com/v1/identity/oidc/callback \
  --scope profile --scope email --scope groups --groups-claim groups --login-ttl 600
kyvernon users remove-oidc

--client-secret-file lit le secret dans un fichier, ou sur l'entrée standard avec -. Sans cette option, le secret stocké est conservé ; elle est obligatoire la première fois, sauf si la section [oidc] de controller.toml en contient déjà un. Avant de stocker quoi que ce soit, le contrôleur exécute la découverte OpenID à <issuer>/.well-known/openid-configuration. Un fournisseur qui ne répond pas est refusé avec error.identity.oidc_unreachable, et le fournisseur stocké reste en place.

Le réglage remplace la section [oidc] de controller.toml. remove-oidc supprime le fournisseur, et désactive aussi un fournisseur issu de la section [oidc]. La connexion locale reste disponible.

Vous pouvez aussi définir le fournisseur dans la section [oidc] de la configuration du contrôleur : émetteur, identifiant du client, fichier contenant le secret du client, adresse de redirection, portées et claim des groupes. Redémarrez le contrôleur après la modification, puis vérifiez que la console propose le fournisseur :

Shell
kyvernon auth config

La réponse montre oidc avec enabled à true et le libellé du bouton. Donnez un rôle au groupe que le fournisseur envoie :

Shell
kyvernon roles list
kyvernon permissions set group-d1 vm-admins --group --role <role-id>

group-d1 est le dossier racine et vm-admins est la valeur du claim des groupes.

Avec l'API

GET /v1/auth/config indique à un client, avant que quiconque se soit connecté, si le fournisseur est configuré. Le flux par navigateur utilise GET /v1/identity/oidc/start, qui renvoie l'adresse du fournisseur et définit un cookie liant la connexion au navigateur, et GET /v1/identity/oidc/callback, que le fournisseur appelle. Les clients programmatiques n'utilisent pas ces routes.

Le fournisseur lui-même se gère avec GET, PUT et DELETE /v1/identity/oidc/config. Les trois exigent Global.Settings, et les modifications sont auditées. La vue contient ces champs :

ChampSignification
configuredIndique si un fournisseur est défini.
issuer, clientId, redirectUri, scopes, groupsClaim, loginTtlSecondsLes paramètres en vigueur.
clientSecretSetIndique si un secret est stocké. Le secret n'est jamais renvoyé.
sourceconsole, configuration ou none.

PUT accepte ces champs :

ChampSignification
issuerL'adresse https du fournisseur.
clientIdL'identifiant du client.
clientSecretEn écriture seule. Vide ou absent, il conserve le secret stocké. Obligatoire la première fois, sauf si la section [oidc] de controller.toml en contient déjà un.
redirectUriNormalement https://<contrôleur>/v1/identity/oidc/callback.
scopesPortées en plus de openid.
groupsClaimLe claim qui contient les noms de groupes. Par défaut groups.
loginTtlSecondsDe 60 à 3600.

Le secret est scellé avec la clé d'identité du contrôleur dans le store répliqué. DELETE supprime le fournisseur.

Version 0.1. Dernière modification : 2026-11-14