Configurer l'authentification OIDC sur les clusters d'utilisateur

Cette page s'adresse aux administrateurs de plates-formes.

Cette page explique comment activer l'authentification OIDC (OpenID Connect) sur les clusters d'utilisateur et comment configurer le contrôle des accès basé sur les rôles (RBAC). Pour en savoir plus sur l'authentification avec OIDC, consultez la page Gestion des identités avec OIDC dans les clusters Anthos sur solution Bare Metal.

Activer l'authentification OIDC sur les clusters d'utilisateur

L'authentification OIDC peut être activée lors de la création du cluster d'utilisateur ou sur un cluster d'utilisateur existant. Pour configurer l'authentification OIDC, vous devez disposer des profils d'identité à appliquer au cluster. Consultez la page Créer des profils d'identité.

Définir un ou plusieurs profils d'identité lors de la création du cluster

Consultez la page Créer des clusters d'utilisateur pour savoir comment créer des clusters d'utilisateur avec la console Anthos Management Center. Sur la page Configuration du cluster pour créer un cluster d'utilisateur, sélectionnez les profils d'identité dans la liste déroulante Configurations AIS. Ces profils d'identité seront appliqués au cluster d'utilisateur.

Appliquer le profil d'identité lors de la création du cluster

Définir des profils d'identité sur un cluster d'utilisateur existant

  1. Accédez à la page Identité et accès.

    Page "Profils d'identité"

  2. Cliquez sur Appliquer des profils aux clusters.

    Appliquer des profils au cluster d'utilisateur existant

  3. Sélectionnez les profils d'identité à appliquer dans la liste déroulante Profils.

  4. Sélectionnez les clusters auxquels appliquer les profils d'identité dans la liste déroulante Clusters.

Afficher les profils d'identité appliqués au cluster d'utilisateur

Vous pouvez afficher les profils d'identité appliqués au cluster d'utilisateur à partir de la page Identité et accès.

Sélectionnez l'onglet Cluster, recherchez le cluster d'utilisateur à afficher, puis cliquez sur Afficher la configuration pour ce cluster d'utilisateur.

Afficher la configuration de l'identité du cluster d'utilisateur

Télécharger le fichier de configuration de connexion du cluster d'utilisateur

Télécharger la configuration de la connexion au cluster d'utilisateur

Sur la page déroulante Afficher la configuration, cliquez sur Télécharger la configuration de connexion.

Spécifier la configuration OIDC à partir du fichier

Créez un fichier contenant les éléments suivants. Enregistrez ce fichier sous le nom user-cluster-oidc-config.yaml :

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos private mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

Remplacez les éléments suivants :

  • CONFIGURATION_NAME : Nom de la configuration OIDC à créer.
  • CLIENT_ID : ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID.
  • CLIENT_SECRET : code secret de l'application cliente.
  • EXTRA_PARAMS : paramètres supplémentaires de clé-valeur (séparés par une virgule) à envoyer au fournisseur OpenID.
  • ISSUER_URI : URL à laquelle les requêtes d'autorisation sont envoyées à votre OpenID.
  • SCOPES : champs d'application supplémentaires (séparés par une virgule) à envoyer au fournisseur OpenID.
  • USER_CLAIM : revendication JWT à utiliser comme nom d'utilisateur. Vous pouvez choisir d'autres revendications, telles que l'e-mail ou le nom, en fonction du fournisseur OpenID. Toutefois, les revendications autres que l'e-mail sont précédées de l'URL de l'émetteur pour éviter les conflits de noms.
  • GROUPS_CLAIM : nom de la revendication dans le jeton d'ID OIDC qui contient les informations du groupe de l'utilisateur.
  • CERT_AUTHORITY_DATA : certificat facultatif encodé au format PEM encodé en base64 pour le fournisseur OIDC. Supprimez-le si nécessaire. Pour créer la chaîne, encodez le certificat, y compris les en-têtes, en base64. Incluez la chaîne obtenue dans certificateAuthorityData en tant que ligne unique.

Après avoir modifié le fichier avec la configuration souhaitée, exécutez la commande suivante :

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Remplacez les éléments suivants :

  • USER_CLUSTER_KUBECONFIG : chemin d'accès au fichier Kubeconfig du cluster d'utilisateur.
  • OIDC_CONFIG : chemin d'accès au fichier de configuration que vous avez créé.

Configurer RBAC sur le cluster d'utilisateur

Cette section donne un exemple de configuration de RBAC pour accorder l'accès à des espaces de noms individuels. Pour plus d'informations, reportez-vous à la documentation de Kubernetes RBAC.

Supposons deux espaces de noms : workload-a et workload-b. L'objectif est de rendre les ressources de l'espace de noms workload-a lisibles et modifiables par l'utilisateur alice@example.com et workload-b lisibles par l'utilisateur bob@example.com. alice@example.com ne peut pas accéder à workload-b et bob@example.com ne peut pas accéder à workload-a.

Créez les espaces de noms dans le cluster d'utilisateur :

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

Pour limiter l'accès à chaque espace de noms, vous devez définir l'autorisation d'accès à chacun. Dans Kubernetes, vous pouvez créer un objet "Role".

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

Le verbs défini pour foo-full-access détermine toutes les actions que ce rôle est autorisé à effectuer dans l'espace de noms.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

Pour b-read-access, les verbes définis autorisent le rôle à uniquement interroger les ressources.

Pour que les utilisateurs obtiennent des autorisations, les objets "RoleBinding" doivent être créés. Les objets "RoleBinding" peuvent inclure des utilisateurs individuels ou des groupes. Cet exemple présente des utilisateurs individuels.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: prefix-alice@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

L'objet "RoleBinding" ci-dessus (a-full-access-users) accorde à l'utilisateur alice@example.com les autorisations définies par le rôle a-full-access. Cela signifie que l'utilisateur alice@example.com est capable de lire et d'écrire dans des ressources de l'espace de noms workload-a.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: bob@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

Cet objet RoleBinding (b-read-access-users) accorde à l'utilisateur bob@example.com les autorisations définies dans le rôle b-read-access. Par conséquent, l'utilisateur bob@example.com ne bénéficie que d'un accès en lecture sur les ressources de l'espace de noms workload-b.

Se connecter avec le fournisseur OIDC

En tant qu'administrateur du cluster d'utilisateur, faites en sorte que tous les utilisateurs du cluster utilisent le fichier de configuration de connexion pour se connecter : Consultez la section Télécharger le fichier de configuration des connexions au cluster d'utilisateur pour obtenir la configuration de connexion à partir du centre de gestion Anthos. Vous pouvez également créer le fichier de configuration de connexion en exécutant la commande suivante :

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

Distribuez le fichier USER_CLUSTER_NAME-actl-auth-login-config.yaml aux utilisateurs du cluster d'utilisateur.

Authentifiez-vous auprès du fournisseur OIDC et suivez les instructions de la ligne de commande :

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

Remplacez USER_CLUSTER_NAME par le nom du cluster d'utilisateur, comme indiqué dans la Console d'administration. --kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig est le nom du fichier Kubconfig de sortie. Remplacez CONFIGURATION_NAME par le nom du profil d'identité avec lequel vous authentifier. Ouvrez USER_CLUSTER_NAME-actl-auth-login-config.yaml pour afficher les noms de profil.

Utilisez la nouvelle interface Kubeconfig avec kubectl comme suit :

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

Étapes suivantes