Configurer la gestion des identités

Cette rubrique explique comment activer et configurer la gestion des identités dans Tanzu Kubernetes Grid (TKG) avec un cluster de gestion autonome.

À propos de l'activation et de la configuration de la gestion des identités

Vous pouvez activer la gestion des identités pendant ou après le déploiement du cluster de gestion, en configurant un fournisseur d'identité LDAPS ou OIDC. Tous les clusters de charge de travail que vous créez après l'activation de la gestion des identités sont automatiquement configurés pour utiliser le même fournisseur d'identité que le cluster de gestion. Pour configurer rétroactivement des clusters de charge de travail existants avec une gestion des identités récemment activée, suivez Activer la gestion des identités sur les clusters de charge de travail.

L'activation et la configuration de la gestion des identités incluent les étapes suivantes. Si vous souhaitez utiliser des fichiers kubeconfig standard non-administrateurs pour accéder aux clusters de gestion et de charge de travail, une fois les étapes de cette rubrique terminées, vous devez également configurer le contrôle d'accès basé sur les rôles (RBAC) en suivant les instructions de la section Configurer RBAC.

(Recommandé) Activation et configuration de la gestion des identités lors du déploiement du cluster de gestion :

  1. Obtenez les détails de votre fournisseur d'identité.
  2. Utilisez les détails obtenus pour configurer LDAPS ou OIDC dans Tanzu Kubernetes Grid.
  3. Une fois le cluster de gestion créé, vérifiez que le service d'authentification s'exécute correctement et terminez sa configuration.

Pour obtenir des instructions, reportez-vous à la section (Recommandé) Activer et configurer la gestion des identités lors du déploiement du cluster de gestion ci-dessous.

Activation et configuration de la gestion des identités après le déploiement du cluster de gestion :

  1. Obtenez les détails de votre fournisseur d'identité.
  2. Générez le secret du module complémentaire Pinniped pour le cluster de gestion.
  3. Vérifiez que le service d'authentification s'exécute correctement et terminez sa configuration.
  4. Si le cluster de gestion gère des clusters de charge de travail, générez le secret du module complémentaire Pinniped pour chaque cluster de charge de travail créé avant l'activation de la gestion des identités.

Pour obtenir des instructions, reportez-vous à la section Activer et configurer la gestion des identités dans un déploiement existant ci-dessous.

(Recommandé) Activer et configurer la gestion des identités lors du déploiement du cluster de gestion

Cette section explique comment activer et configurer la gestion des identités lors du déploiement du cluster de gestion.

Obtenir les détails de votre fournisseur d'identité

Avant de pouvoir activer la gestion des identités, vous devez disposer d'un fournisseur d'identité. Tanzu Kubernetes Grid prend en charge les fournisseurs d'identité LDAPS et OIDC.

  • Pour utiliser le serveur LDAPS interne de votre entreprise comme fournisseur d'identité, obtenez les informations LDAPS auprès de votre administrateur LDAP.
  • Pour utiliser OIDC comme fournisseur d'identité, vous devez disposer d'un compte avec un fournisseur d'identité qui prend en charge la norme OpenID Connect, par exemple, Okta.

Exemple : enregistrer une application Tanzu Kubernetes Grid dans Okta

Pour utiliser Okta comme fournisseur OIDC, vous devez créer un compte Okta et enregistrer une application pour Tanzu Kubernetes Grid dans votre compte :

  1. Si vous n'en avez pas, créez un compte Okta.
  2. Accédez au portail d'administration en cliquant sur le bouton Admin.
  3. Accédez à Applications et cliquez sur Ajouter une application (Add Application).
  4. Cliquez sur Créer une application (Create New App).
  5. Pour Plate-forme (Platform), sélectionnez Web et pour Méthode d'authentification (Sign on method), sélectionnez OpenID Connect, puis cliquez sur Créer (Create).
  6. Donnez un nom à votre application.
  7. Entrez un espace réservé URI de redirection de connexion (Login redirect URI). Par exemple, entrez http://localhost:8080/callback. Vous mettrez à jour cette valeur avec l'URL réelle après avoir déployé le cluster de gestion.
  8. Cliquez sur Enregistrer.
  9. Dans l'onglet Général (General) de votre application, copiez et enregistrez l'ID de client (Client ID) et le Secret du client (Client Secret). Vous aurez besoin de ces informations d'identification lorsque vous déploierez le cluster de gestion.
  10. Dans l'onglet Attributions (Assignments), attribuez des personnes et des groupes à l'application. Les personnes et les groupes que vous attribuez à l'application seront les utilisateurs qui peuvent accéder au cluster de gestion et aux clusters de charge de travail que vous utilisez pour le déploiement.

Configurer les paramètres LDAPS ou OIDC dans Tanzu Kubernetes Grid

Utilisez les détails obtenus ci-dessus pour configurer LDAPS ou OIDC dans Tanzu Kubernetes Grid :

  • Si vous déployez votre cluster de gestion à l'aide de l'interface du programme d'installation, configurez LDAPS ou OIDC dans la section Gestion des identités (Identity Management). Pour obtenir des instructions, reportez-vous à la section Configurer la gestion des identités dans Déployer des clusters de gestion avec l'interface du programme d'installation.

  • Si vous déployez votre cluster de gestion à partir d'un fichier de configuration, définissez les variables LDAP_* ou OIDC_* dans le fichier de configuration.

    Par exemple :

    LDAP :

    IDENTITY_MANAGEMENT_TYPE: ldap
LDAP_BIND_DN: ""
LDAP_BIND_PASSWORD: ""
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: memberUid
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: (objectClass=posixAccount)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
LDAP_USER_SEARCH_USERNAME: uid

    OIDC :

    IDENTITY_MANAGEMENT_TYPE: oidc
OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

    Pour obtenir des instructions sur la préparation d'un fichier de configuration de cluster de gestion, reportez-vous à la section Créer un fichier de configuration de cluster de gestion.

Remarque

Les espaces Dex doivent faire l'objet d'une rotation manuelle lorsque le certificat TLS de Dex expire (90 jours par défaut). Vous pouvez augmenter la durée du certificat à l'aide de CERT_DURATION. Pour redémarrer les espaces Dex, exécutez kubectl rollout restart deployments/dex -n tanzu-system-auth.

Terminer la configuration de la gestion des identités

Une fois le cluster de gestion déployé, terminez la configuration de la gestion des identités en suivant les procédures décrites dans les sections ci-dessous :

  1. Connectez kubectl au cluster de gestion.
  2. Vérifiez que le service d'authentification s'exécute correctement en vérifiant son état :
  3. OIDC : Fournissez l'URI de rappel au fournisseur OIDC.
  4. Pour prendre en charge l'utilisation de fichiers kubeconfig standard non-administrateurs pour accéder au cluster de gestion, configurez RBAC pour un cluster de gestion.

Connecter kubectl au cluster de gestion

Pour configurer la gestion des identités, vous devez obtenir et utiliser le contexte admin du cluster de gestion :

  1. Obtenez le contexte admin du cluster de gestion. Les procédures de cette rubrique utilisent un cluster de gestion nommé id-mgmt-test.

    tanzu mc kubeconfig get id-mgmt-test --admin

    Si votre cluster de gestion est nommé id-mgmt-test, vous devez voir la confirmation Credentials of workload cluster 'id-mgmt-test' have been saved. You can now access the cluster by running 'kubectl config use-context id-mgmt-test-admin@id-mgmt-test'. Le contexte admin d'un cluster vous donne un accès complet au cluster sans nécessiter d'authentification auprès de votre fournisseur d'identité.

  2. Définissez kubectl sur le contexte admin du cluster de gestion :

    kubectl config use-context id-mgmt-test-admin@id-mgmt-test

Vérifier l'état d'un service de gestion des identités OIDC

Tanzu Kubernetes Grid utilise Pinniped pour intégrer des clusters à un service d'identité OIDC. Lorsque vous activez OIDC, Tanzu Kubernetes Grid crée le service pinniped-supervisor dans l'espace de noms pinniped-supervisor et pinniped-concierge dans l'espace de noms pinniped-concierge. Suivez les étapes ci-dessous pour vérifier l'état du service Pinniped et notez l'adresse EXTERNAL-IP à laquelle le service est exposé.

  1. Obtenez des informations sur les services qui s'exécutent dans le cluster de gestion. Le service de gestion des identités s'exécute dans l'espace de noms pinniped-supervisor :

    kubectl get services -n pinniped-supervisor

    Vous pouvez voir l'entrée suivante dans le fichier de sortie :

    vSphere avec NSX Advanced Load Balancer (ALB) :

    NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
service/pinniped-supervisor   LoadBalancer   100.70.70.12   20.52.230.18   5556:31234/TCP   84m

    Amazon Web Services (AWS) :

    NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP                              PORT(S)         AGE
service/pinniped-supervisor   LoadBalancer   100.69.13.66   ab1[...]71.eu-west-1.elb.amazonaws.com   443:30865/TCP   56m

    Azure :

    NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)         AGE
service/pinniped-supervisor   LoadBalancer   100.69.169.220   20.54.226.44     443:30451/TCP   84m

    vSphere sans NSX ALB :

    NAME                          TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/pinniped-supervisor   NodePort   100.70.70.12   <none>        5556:31234/TCP   84m

  2. Notez les informations suivantes :

    • vSphere avec NSX ALB, AWS et Azure : notez l'adresse externe du service pinniped-supervisor, comme indiqué sous EXTERNAL-IP.
    • vSphere sans NSX ALB : notez le port sur lequel le service pinniped-supervisor s'exécute. Dans l'exemple ci-dessus, ce port est 31234.

  3. Vérifiez que tous les services du cluster de gestion sont en cours d'exécution.

    kubectl get pods -A

    Plusieurs minutes peuvent être nécessaires pour que le service Pinniped soit opérationnel. Par exemple, sur les déploiements AWS et Azure, le service doit attendre que les adresses IP LoadBalancer soient prêtes. Attendez que pinniped-post-deploy-job soit terminé avant de passer aux étapes suivantes.

    NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
[...]
pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
Remarque

Vous pouvez exécuter kubectl get pods, car vous utilisez le contexte admin pour le cluster de gestion. Les utilisateurs qui tentent de se connecter au cluster de gestion avec le contexte normal ne pourront pas accéder à ses ressources, car ils n'y sont pas encore autorisés.

Vérifier l'état d'un service de gestion des identités LDAP

Tanzu Kubernetes Grid utilise Pinniped pour intégrer des clusters à un service d'identité LDAP, ainsi que Dex pour exposer le point de terminaison du service. Lorsque vous activez LDAP, Tanzu Kubernetes Grid crée le service pinniped-supervisor dans l'espace de noms pinniped-supervisor, pinniped-concierge dans l'espace de noms pinniped-concierge et dexsvc dans l'espace de noms tanzu-system-auth. Suivez les étapes ci-dessous pour vérifier l'état d'un service LDAP et notez l'adresse EXTERNAL-IP à laquelle le service est exposé.

  1. Obtenez des informations sur les services qui s'exécutent dans le cluster de gestion dans l'espace de noms tanzu-system-auth :

    kubectl get services -n tanzu-system-auth

    Vous pouvez voir l'entrée suivante dans le fichier de sortie :

    vSphere avec NSX ALB :

    NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
service/dexsvc   LoadBalancer   100.70.70.12   20.52.230.18   443:30167/TCP   84m

    AWS :

    NAME             TYPE           CLUSTER-IP       EXTERNAL-IP                              PORT(S)         AGE
service/dexsvc   LoadBalancer   100.65.184.107   a6e[...]74.eu-west-1.elb.amazonaws.com   443:32547/TCP   84m

    Azure :

    NAME             TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
service/dexsvc   LoadBalancer   100.69.169.220   20.54.226.44  443:30451/TCP   84m

    vSphere sans NSX ALB :

    NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/dexsvc   NodePort   100.70.70.12   <none>        5556:30167/TCP   84m

  2. Vérifiez que tous les services du cluster de gestion sont en cours d'exécution :

    kubectl get pods -A

    Plusieurs minutes peuvent être nécessaires pour que le service Pinniped soit opérationnel. Par exemple, sur les déploiements AWS et Azure, le service doit attendre que les adresses IP LoadBalancer soient prêtes. Attendez que pinniped-post-deploy-job soit terminé avant de passer aux étapes suivantes.

    NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
[...]
pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
    Remarque

    Vous pouvez exécuter kubectl get pods, car vous utilisez le contexte admin pour le cluster de gestion. Les utilisateurs qui tentent de se connecter au cluster de gestion avec le contexte normal ne pourront pas accéder à ses ressources, car ils n'y sont pas encore autorisés.

  3. Vous pouvez ensuite configurer RBAC pour le cluster de gestion.

(OIDC uniquement) Fournir l'URI de rappel au fournisseur OIDC

Si vous avez configuré le cluster de gestion pour utiliser l'authentification OIDC, vous devez fournir l'URI de rappel de ce cluster de gestion à votre fournisseur d'identité OIDC. Par exemple, si vous utilisez OIDC et que votre fournisseur d'identité est Okta, procédez comme suit :

  1. Connectez-vous à votre compte Okta.
  2. Dans le menu principal, accédez à Applications.
  3. Sélectionnez l'application que vous avez créée pour Tanzu Kubernetes Grid.
  4. Dans le panneau Paramètres généraux (General Settings), cliquez sur Modifier (Edit).

  5. Sous Connexion (Login), mettez à jour les URI de redirection de connexion (Login redirect URIs) pour inclure l'adresse du nœud dans lequel le pinniped-supervisor est en cours d'exécution :

    • vSphere avec NSX ALB, AWS et Azure : Ajoutez l'adresse IP externe et le numéro de port du service pinniped-supervisor que vous avez noté dans la procédure précédente :

      https://EXTERNAL-IP/callback

    • vSphere sans NSX ALB : Ajoutez l'adresse IP que vous avez définie comme point de terminaison d'API et le numéro de port pinniped-supervisor que vous avez noté dans la procédure précédente :

      https://API-ENDPOINT-IP:31234/callback

      Dans tous les cas, vous devez spécifier https, pas http.

  6. Cliquez sur Enregistrer.

Configurer RBAC pour le cluster de gestion

Si vous prévoyez d'utiliser des fichiers kubeconfig standard non-administrateurs pour accéder au cluster de gestion, après avoir terminé la configuration de la gestion des identités, configurez RBAC en suivant les instructions de la section Configurer RBAC pour un cluster de gestion.

Activer et configurer la gestion des identités dans un déploiement existant

Cette section explique comment activer et configurer la gestion des identités dans un déploiement existant.

Obtenir les détails de votre fournisseur d'identité

Suivez les instructions de la section Obtenir les détails de votre fournisseur d'identité ci-dessus.

Générer le secret du module complémentaire Pinniped pour le cluster de gestion

Cette procédure configure le module complémentaire Pinniped et déploie les composants d'authentification dans votre cluster de gestion. Pour générer un secret Kubernetes pour le module complémentaire Pinniped :

  1. Définissez le contexte de kubectl sur le cluster de gestion. Par exemple, avec un cluster de gestion nommé id-mgmt-test :

    kubectl config use-context id-mgmt-test-admin@id-mgmt-test

  2. Créez un fichier de configuration de cluster en copiant les paramètres de configuration que vous avez définis lors du déploiement de votre cluster de gestion dans un nouveau fichier. Ajoutez les paramètres suivants au fichier de configuration du cluster de gestion, y compris les détails du fournisseur d'identité OIDC ou LDAP :

    Remarque

    Vous devez définir ces variables uniquement pour les clusters de gestion.

    # Identity management type. This must be "oidc" or "ldap".

IDENTITY_MANAGEMENT_TYPE:

# Explicitly set the namespace, which for management clusters is "tkg-system".

NAMESPACE: tkg-system

# Set these variables if you want to configure OIDC.

OIDC_IDENTITY_PROVIDER_CLIENT_ID:
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM:
OIDC_IDENTITY_PROVIDER_ISSUER_URL:
OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups"
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM:

# Set these variables if you want to configure LDAP.

LDAP_BIND_DN:
LDAP_BIND_PASSWORD:
LDAP_GROUP_SEARCH_BASE_DN:
LDAP_GROUP_SEARCH_FILTER:
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE:
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
LDAP_HOST:
LDAP_ROOT_CA_DATA_B64:
LDAP_USER_SEARCH_BASE_DN:
LDAP_USER_SEARCH_EMAIL_ATTRIBUTE: DN
LDAP_USER_SEARCH_FILTER:
LDAP_USER_SEARCH_ID_ATTRIBUTE: DN
LDAP_USER_SEARCH_NAME_ATTRIBUTE:
LDAP_USER_SEARCH_USERNAME: userPrincipalName

# Set these variables if you want to configure certificate duration

CERT_DURATION: 2160h
CERT_RENEW_BEFORE: 360h

    Pour savoir lesquelles de ces variables sont facultatives et peuvent être omises, accédez à Variables pour la configuration des fournisseurs d'identité – OIDC et Variables pour la configuration des fournisseurs d'identité – LDAP.

    Si votre cluster de gestion se trouve derrière un proxy, assurez-vous que le nouveau fichier de configuration inclut les détails de configuration du proxy :

    TKG_HTTP_PROXY:
TKG_HTTPS_PROXY:
TKG_NO_PROXY:

    Pour plus d'informations sur ces variables, reportez-vous à la section Configuration du proxy.

    vSphere : remplacez le paramètre de configuration VSPHERE_CONTROL_PLANE_ENDPOINT par une adresse IP inutilisée, en tant que valeur factice pour passer avec succès les vérifications internes.

  3. Assurez-vous que la variable IDENTITY_MANAGEMENT_TYPE de votre environnement local est définie sur oidc ou ldap et non none :

    echo $IDENTITY_MANAGEMENT_TYPE

    Si cette variable est définie sur none, exécutez une commande export pour la définir à nouveau sur oidc ou ldap.

  4. Définissez la variable d'environnement _TKG_CLUSTER_FORCE_ROLE sur management :

    export _TKG_CLUSTER_FORCE_ROLE="management"

    Sous Windows, utilisez la commande SET.

  5. Définissez la variable d'environnement FILTER_BY_ADDON_TYPE sur authentication/pinniped afin que la commande tanzu cluster create fonctionne uniquement sur les objets associés à Pinniped :

    export FILTER_BY_ADDON_TYPE="authentication/pinniped"

  6. Générez un secret pour le module complémentaire Pinniped :

    tanzu cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml

    Où :

    • CLUSTER-NAME est le nom de votre cluster de gestion cible.
    • CLUSTER-CONFIG-FILE est le fichier de configuration que vous avez créé ci-dessus.

    Du fait des paramètres de variable d'environnement, tanzu cluster create --dry-run génère un secret Kubernetes, pas un manifeste de cluster complet.

  7. Vérifiez le secret, puis appliquez-le au cluster de gestion. Par exemple :

    kubectl apply -f CLUSTER-NAME-example-secret.yaml

  8. Après avoir appliqué le secret, vérifiez l'état du module complémentaire Pinniped en exécutant la commande kubectl get app :

    $ kubectl get app CLUSTER-NAME-pinniped -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
pinniped       Reconcile succeeded     3m23s           7h50m

    Si l'état renvoyé est Reconcile failed, exécutez la commande suivante pour obtenir des détails sur l'échec :

    kubectl get app CLUSTER-NAME-pinniped -n tkg-system -o yaml

Terminer la configuration de la gestion des identités

Suivez les instructions de la section Terminer la configuration de la gestion des identités ci-dessus.

Activer la gestion des identités sur les clusters de charge de travail

Tous les clusters de charge de travail que vous créez lorsque vous activez la gestion des identités dans le cluster de gestion sont automatiquement configurés pour utiliser le même service de gestion des identités.

Authentifier des utilisateurs sur une machine sans navigateur

Si votre machine de démarrage est une jumpbox ou une autre machine sans affichage, vous pouvez vous authentifier sur un cluster à partir d'un navigateur s'exécutant sur votre machine locale. La manière dont vous procédez dépend de la version de Pinniped du cluster, qui provient de la version Tanzu Kubernetes sur laquelle le cluster est basé :

Version de Tanzu Kubernetes du cluster Procédure d'authentification sans navigateur
TKR 1.23.10 (par défaut pour Tanzu Kubernetes Grid 1.6.1) ou version ultérieure Suivez les instructions ci-dessous.
Clusters basés sur d'anciennes TKR ou créés par d'anciennes versions de Tanzu Kubernetes Grid. Suivez la procédure Authentifier des utilisateurs sur une machine sans navigateur dans la documentation de Tanzu Kubernetes Grid 1.4.
Remarque

Tanzu Kubernetes Grid v2.2 ne prend pas en charge la connexion CLI sans navigateur basée sur des comptes non interactifs ou des octrois de mots de passe.

  1. Dans une fenêtre de terminal sur votre machine locale, exécutez ssh pour vous connecter à distance à votre machine de démarrage.

  2. Définissez la variable d'environnement TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true. Cela ajoute l'option --skip-browser à kubeconfig pour le cluster.

    # Linux
export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
# Windows
set TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true

  3. Exportez le fichier kubeconfig standard pour le cluster dans un fichier local. Notez que la commande n'inclut pas l'option --admin, de sorte que le fichier kubeconfig qui est exporté est la version standard kubeconfig, pas la version admin. Par exemple, pour exporter le fichier kubeconfig vers /tmp/my-cluster-kubeconfig :

    • Pour un cluster de gestion, exécutez :

      tanzu mc kubeconfig get --export-file /tmp/my-cluster-kubeconfig

      Vous devez voir la confirmation You can now access the cluster by specifying '--kubeconfig /tmp/my-mgmt-cluster-kubeconfig' flag when using 'kubectl' command.

    • Pour un cluster de charge de travail, exécutez :

      tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig

  4. Connectez-vous au cluster à l'aide du fichier kubeconfig récemment créé :

    kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig

    La CLI génère un lien de connexion pour votre fournisseur d'identité. Par exemple :

    Log in by visiting this link:

   https://10.180.105.166:31234/oauth2/authorize?access_type=offline&client_id=pinniped-cli&code_challenge=-aJ617vJZXZeEnHPab1V2_VHPmc5VwspFig5QQKyTwg&code_challenge_method=S256&nonce=cafaf8f4d2cb714ef8fb3320c1b088ba&redirect_uri=http%3A%2F%2F127.0.0.1%3A33087%2Fcallback&response_mode=form_post&response_type=code&scope=offline_access+openid+pinniped%3Arequest-audience&state=fff3d4d46b36359d5ba2f24fad471dd8

   Optionally, paste your authorization code:

  5. Copiez le lien et collez-le dans un navigateur sur votre machine locale.

  6. Dans le navigateur, connectez-vous à votre fournisseur d'identité. Une page s'affiche et vous invite à coller un code d'autorisation dans la CLI :

    Terminer votre connexion

  7. Copiez le code d'autorisation et collez-le dans la CLI, après que l'invite Optionally, paste your authorization code: s'est affichée.

  8. Reconnectez-vous au cluster en utilisant le même fichier kubeconfig que celui utilisé précédemment :

    kubectl get pods -A --kubeconfig FILE-PATH

    • Si vous avez déjà configuré une liaison de rôle sur le cluster pour l'utilisateur authentifié, la sortie affiche les informations sur l'espace.

    • Si vous n'avez pas configuré de liaison de rôle sur le cluster, un message refusant l'accès du compte d'utilisateur aux espaces s'affiche : Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope. Cela se produit, car l'utilisateur a été authentifié, mais il n'est pas encore autorisé à accéder aux ressources sur le cluster. Pour autoriser l'utilisateur à accéder aux ressources du cluster, vous devez configurer RBAC sur le cluster en créant une liaison de rôle de cluster :

Mettre à jour les paramètres Dex après le déploiement du cluster de gestion

Le composant Pinniped utilise Dex pour les fournisseurs d'identité LDAP. Pour les fournisseurs d'identité OIDC, Dex n'est pas utilisé.

Si vous souhaitez mettre à jour un paramètre qui commence par dex. dans la section values.yaml du secret Pinniped du cluster de gestion, vous devez suivre les étapes ci-dessous :

  1. Identifiez le ou les paramètres dex. que vous souhaitez mettre à jour. Reportez-vous au tableau de la section Paramètres values.yaml du module autogéré.
  2. Récupérez le secret Pinniped pour le cluster de gestion, comme décrit dans la section Paramètres values.yaml du module autogéré.

  3. Dans le secret Pinniped, mettez à jour le ou les paramètres dex. que vous avez identifiés ci-dessus et suivez les étapes ci-dessous :

    1. Définissez les paramètres de configuration de baie dex.dns.INFRASTRUCTURE-PROVIDER.ipAddresses et dex.config.dns.INFRASTRUCTURE-PROVIDER.dnsNames. Ces champs peuvent être définis sur des baies avec n'importe quelle entrée unique non vide, par exemple, 0.0.0.0, car ils sont mis à jour automatiquement.
    2. Définissez le paramètre de configuration pinniped.upstream_oidc_issuer_url sur une chaîne non vide commençant par https. Par exemple, https://0.0.0.0. Ce champ est automatiquement mis à jour ultérieurement.
    3. Définissez le paramètre de configuration de baie dex.config.staticClients pour avoir une seule entrée. Ce paramètre peut être n'importe quel mappage avec au moins les clés name, id et secret, par exemple, {name: "example-name", id: "example-id", secret: "example-secret"}, car il est mis à jour automatiquement.

    4. Ajoutez la superposition suivante au secret Pinniped :

      #@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"metadata": {"name" : "upstream-oidc-identity-provider"}})
---
metadata:
  annotations:
    #@overlay/remove
    kapp.k14s.io/update-strategy: always-replace

  4. Appliquez le secret Pinniped.

  5. Redémarrez l'espace de noms tanzu-system-auth dans le cluster de gestion après avoir appliqué le secret Pinniped. Pour redémarrer l'espace de noms, vous pouvez supprimer l'Namespace et attendre que l'App pinniped le recrée. Vous devrez peut-être redémarrer la Job pinniped-post-deploy-job dans l'Namespace pinniped-supervisoraprès avoir appliqué le secret Pinniped. Pour ce faire, vous pouvez supprimer la Job et attendre que l'App pinniped la recrée.

Désactiver la gestion des identités dans un déploiement existant

Pour désactiver la gestion des identités dans un déploiement existant dans lequel la gestion des identités est activée :

  1. Définissez le contexte de kubectl sur le cluster de gestion. Par exemple, avec un cluster de gestion nommé id-mgmt-test :

    kubectl config use-context id-mgmt-test-admin@id-mgmt-test

  2. Récupérez le fichier de configuration du cluster de gestion et modifiez-le pour définir IDENTITY_MANAGEMENT_TYPE: none.

  3. Générez une définition de secret Pinniped en exécutant tanzu management-cluster create avec --dry-run et le filtrage pour les objets associés à Pinniped.

    FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run CLUSTER-CONFIG > PINNIPED-SECRET

    Où CLUSTER-CONFIG est le fichier de configuration du cluster et PINNIPED-SECRET est ce que vous nommez la définition de Pinniped Secret générée, telle que mc-no-idp.yaml.

  4. Appliquez le nouveau secret pour désactiver Pinniped sur le cluster de gestion :

    kubectl apply -f PINNIPED-SECRET

  5. Après la désactivation de Pinniped sur le cluster de gestion, ses clusters basés sur une classe se désactivent automatiquement, mais vous devez désactiver manuellement ses clusters hérités :

    1. Répertoriez tous les secrets Pinniped restants dans le contexte du cluster de gestion :

      kubectl get secret -A | grep pinniped-addon

    2. Examinez les secrets dans la sortie kubectl get secret, le cas échéant, à l'aide du nom secret et de l'espace de noms répertoriés :

      kubectl get secret SECRET-NAME -n SECRET-NAMESPACE -o yaml

    3. Supprimez les secrets qui contiennent les éléments suivants :

      • type: tkg.tanzu.vmware.com/addon: il s'agit de secrets de cluster hérités
      • configurations OIDC ou LDAP
      kubectl delete secret SECRET-NAME

      Où SECRET-NAME est la valeur de metadata.name définie dans la spécification Secret.

Tâches suivantes

Si vous prévoyez d'utiliser des fichiers kubeconfig standard non-administrateurs pour accorder aux utilisateurs l'accès à vos clusters de gestion et de charge de travail, vous devez configurer l'autorisation RBAC :

check-circle-line exclamation-circle-line close-line
Scroll to top icon