Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Open ID Connect (OIDC)

Présentation

SUSE Observability peut s’authentifier en utilisant un fournisseur d’authentification OIDC. Pour activer cela, vous devez configurer à la fois SUSE Observability et le fournisseur OIDC pour qu’ils puissent communiquer entre eux. Les sections suivantes décrivent les configurations respectives.

Configurer le fournisseur OIDC

Avant de pouvoir configurer SUSE Observability pour s’authentifier en utilisant OIDC, vous devez créer un client pour SUSE Observability sur votre fournisseur OIDC.

Rancher

Cela ne fonctionne qu’avec Rancher 2.12 ou une version ultérieure. Vous devez configurer Rancher en tant que fournisseur OIDC.

Créez une ressource OIDCClient dans la grappe locale de Rancher :

apiVersion: management.cattle.io/v3
kind: OIDCClient
metadata:
  name: oidc-observability
spec:
  tokenExpirationSeconds: 600
  refreshTokenExpirationSeconds: 3600
  redirectURIs:
    - "https://<observability-base-url>/loginCallback?client_name=StsOidcClient"

Rancher mettra le client ID et le secret à disposition dans son champ d’état :

apiVersion: management.cattle.io/v3
kind: OIDCClient
metadata:
  name: oidc-observability
spec:
  tokenExpirationSeconds: 600
  refreshTokenExpirationSeconds: 3600
  redirectURIs:
    - "https://<observability-base-url>/loginCallback?client_name=StsOidcClient"
status:
  clientID: <oidc-client-id>
  clientSecrets:
    client-secret-1:
      createdAt: "xxx"
      lastFiveCharacters: xxx

Et vous pouvez obtenir la valeur du secret avec

kubectl get secret <oidc-client-id> -n cattle-oidc-client-secrets -o jsonpath="{.data.client-secret-1}" | base64 -d

D’autres fournisseurs OIDC

Utilisez les paramètres suivants pour le client (si nécessaire par le fournisseur OIDC) :

  • Utilisez le flux d’autorisation OIDC, qui est également souvent appelé le flux de code d’autorisation. SUSE Observability ne prend pas en charge les flux d’octroi implicite et hybrides, donc il n’est pas nécessaire d’activer le support pour eux.

  • Définissez le URI de redirection sur l’URL de base de SUSE Observability suffixée par /loginCallback?client_name=StsOidcClient. Par exemple https://stackstate.acme.com/loginCallback?client_name=StsOidcClient. Pour certains fournisseurs OIDC, tels que Google et Azure Entra ID, l’URI de redirection doit correspondre exactement, y compris tous les paramètres de requête. Dans ce cas, vous devez configurer l’URI comme ceci https://stackstate.acme.com/loginCallback?client_name=StsOidcClient.

  • Donnez à SUSE Observability accès à au moins les portées openid et email ou l’équivalent de celles-ci pour votre fournisseur OIDC. Selon le fournisseur, d’autres portées peuvent être requises, si un profile séparé existe, incluez-le également.

  • SUSE Observability a besoin d’un accès hors ligne OIDC. Pour certains fournisseurs d’identité, cela nécessite une portée supplémentaire, généralement appelée offline_access.

Le résultat de cette configuration devrait produire un clientId et un secret. Copiez-les et gardez-les à portée de main pour configurer SUSE Observability. Notez également le discoveryUri du fournisseur. En général, cela se trouve soit sur le même écran, soit dans la documentation.

Configurer SUSE Observability pour OIDC

Rancher

Cela ne fonctionne qu’avec Rancher 2.12 ou une version ultérieure. Vous devez configurer Rancher en tant que fournisseur OIDC.

Pour configurer Rancher en tant que fournisseur OIDC pour SUSE Observability, vous devez ajouter les détails OIDC aux valeurs d’authentification :

stackstate:
  authentication:
    rancher:
      clientId: "<oidc-client-id>"
      secret: "<oidc-secret>"
      baseUrl: "<rancher-url>"

Vous pouvez remplacer et étendre la configuration OIDC pour Rancher avec les champs suivants :

  • discoveryUri - URI que vous pouvez utiliser pour découvrir le fournisseur OIDC : Normalement, également documenté ou retourné lors de la création du client dans le fournisseur OIDC :

  • redirectUri - Optionnel (non dans l’exemple) : L’URI où le point de terminaison de rappel de connexion de SUSE Observability est accessible. Rempli par défaut en utilisant le stackstate.baseUrl, mais peut être remplacé : Cela doit être une URL entièrement qualifiée qui pointe vers le chemin /loginCallback :

  • customParameters - Carte optionnelle de paires clé/valeur que vous envoyez au fournisseur OIDC en tant que paramètres de requête personnalisés : Certains fournisseurs OIDC nécessitent des paramètres de requête supplémentaires qui ne sont pas envoyés par défaut :

Si vous devez désactiver la vérification TLS en raison d’une configuration n’utilisant pas de certificats SSL vérifiables, vous pouvez désactiver les vérifications SSL avec la configuration de l’application (ne pas utiliser en production) :

Pour la configuration Non-HA :

stackstate:
  components:
    server:
      extraEnv:
        open:
          CONFIG_FORCE_stackstate_misc_sslCertificateChecking: false

Pour la configuration HA (haute disponibilité) :

stackstate:
  components:
    api:
      extraEnv:
        open:
          CONFIG_FORCE_stackstate_misc_sslCertificateChecking: false

Dans les déploiements HA, le composant api gère la configuration différemment : Utilisez ce qui suit :
=== Kubernetes

Pour configurer SUSE Observability afin d’utiliser un fournisseur d’authentification OIDC sur Kubernetes, vous devez ajouter les détails OIDC et la cartographie des rôles utilisateurs au fichier authentication.yaml : Par exemple :

stackstate:
  authentication:
    oidc:
      clientId: "<client-id-from-oidc-provider>"
      secret: "<secret-from-oidc-provider>"
      discoveryUri: "https://oidc.acme.com/.well-known/openid-configuration"
      jwsAlgorithm: RS256
      scope: ["openid", "email"]
      jwtClaims:
        usernameField: email
        displayNameField: name
        groupsField: groups
      customParameters:
        access_type: offline

    # map the groups from OIDC provider
    # to the 4 standard roles in SUSE Observability (guest, powerUser, k8sTroubleshooter and admin)
    roles:
      guest: ["guest-group-in-oidc-provider"]
      powerUser: ["powerUser-group-in-oidc-provider"]
      admin: ["admin-group-in-oidc-provider"]
      k8sTroubleshooter: ["troubleshooter-group-in-oidc-provider"]

Suivez les étapes ci-dessous pour configurer SUSE Observability afin de s’authentifier en utilisant OIDC :

  1. Dans authentication.yaml - ajoutez les détails du fournisseur d’authentification OIDC (voir l’exemple ci-dessus) :

    • clientId - L’ID du client OIDC que vous avez créé pour SUSE Observability :

    • secret - Le secret pour le client OIDC que vous avez créé pour SUSE Observability :

    • discoveryUri - URI qui peut être utilisée pour découvrir le fournisseur OIDC : Normalement également documenté ou retourné lors de la création du client dans le fournisseur OIDC :

    • jwsAlgorithm - La valeur par défaut pour OIDC est RS256 : Si votre fournisseur OIDC utilise un autre, il peut être défini ici :

    • scope - Doit correspondre, ou être un sous-ensemble, de la portée fournie dans la configuration du fournisseur OIDC : SUSE Observability utilise cela pour demander l’accès à ces parties d’un profil utilisateur dans le fournisseur OIDC :

    • redirectUri - Optionnel (non dans l’exemple) : L’URI où le point de terminaison de rappel de connexion de SUSE Observability est accessible. Rempli par défaut en utilisant le stackstate.baseUrl, mais peut être remplacé : Cela doit être une URL entièrement qualifiée qui pointe vers le chemin /loginCallback :

    • customParameters - Carte optionnelle de paires clé/valeur qui sont envoyées au fournisseur OIDC en tant que paramètres de requête personnalisés : Certains fournisseurs OIDC nécessitent des paramètres de requête supplémentaires qui ne sont pas envoyés par défaut.

    • jwtClaims -

      • usernameField - Le champ dans le profil OIDC de l’utilisateur qui doit être utilisé comme nom d’utilisateur. Par défaut, cela sera le preferred_username, cependant, de nombreux fournisseurs omettent ce champ. Une bonne alternative est email.

      • displayNameField - Le champ dans le profil OIDC de l’utilisateur qui doit être utilisé comme nom d’affichage. Par défaut, cela sera le name.

      • groupsField - Le champ à partir duquel SUSE Observability lira le rôle/groupe pour un utilisateur.

  2. Dans authentication.yaml - mappez les rôles des utilisateurs d’OIDC aux sujets appropriés de SUSE Observability en utilisant les paramètres roles.guest, roles.powerUser, roles.admin ou roles.platformAdmin (voir l’exemple ci-dessus). Pour plus de détails, voir les rôles par défaut de SUSE Observability. D’autres rôles SUSE Observability peuvent également être créés, voir la documentation RBAC.

  3. Stockez le fichier authentication.yaml avec le fichier values.yaml des instructions d’installation de SUSE Observability.

  4. Exécutez une mise à niveau Helm pour appliquer les modifications :

     helm upgrade \
   --install \
   --namespace suse-observability \
   --values values.yaml \
   --values authentication.yaml \
 suse-observability \
 suse-observability/suse-observability

Remarque :

  • La première exécution de la commande de mise à niveau helm entraînera le redémarrage des pods, ce qui peut provoquer une courte interruption de disponibilité.

  • Incluez authentication.yaml à chaque exécution de helm upgrade.

  • La configuration d’authentification est stockée en tant que secret Kubernetes.

Guides de configuration

Utilisation d’un secret externe

Lorsque les secrets OIDC doivent provenir d’un secret externe, suivez ces étapes mais remplissez les données suivantes :

kind: Secret
metadata:
   name: "<custom-secret-name>"
type: Opaque
data:
  oidc_client_id: <base64 of client id>
  oidc_secret: <base64 of secret>

Reportez-vous également à la section