Configurer l'accès des utilisateurs pour GKE Identity Service

Ce document s'adresse aux administrateurs de cluster qui ont déjà configuré des clusters pour GKE Identity Service en suivant les instructions de l'article Configurer des clusters pour GKE Identity Service au niveau du parc ou Configurer des clusters pour GKE Identity Service à l'aide d'OIDC. Il vous explique comment configurer (et restreindre) l'accès au cluster configuré pour les développeurs de votre organisation et les autres utilisateurs du cluster.

Configurer la connexion des utilisateurs

Après avoir configuré un cluster, vous devez générer un fichier de configuration de connexion et le distribuer aux utilisateurs du cluster. Ce fichier permet aux utilisateurs de se connecter au cluster à partir de la ligne de commande avec le fournisseur choisi, comme décrit dans Accéder aux clusters avec GKE Identity Service.

Avec les fournisseurs OIDC uniquement, les utilisateurs peuvent également se connecter au cluster depuis la console Google Cloud sans fichier de connexion, comme décrit dans Utiliser des clusters à partir de la console Google Cloud.

Générer la configuration de connexion

Console

(Configuration au niveau du parc uniquement)

Copiez la commande gcloud affichée et exécutez-la pour générer le fichier.

gcloud

Si vous avez configuré le cluster à l'aide de la CLI gcloud ou si vous devez à nouveau générer le fichier, exécutez la commande suivante pour le générer:

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

où KUBECONFIG est le chemin d'accès au fichier kubeconfig pour le cluster. S'il existe plusieurs contextes dans le fichier kubeconfig, le contexte actuel est utilisé. Vous devrez peut-être réinitialiser le contexte actuel sur le cluster approprié avant d'exécuter la commande.

Vous trouverez toutes les informations de référence sur cette commande, y compris des paramètres facultatifs supplémentaires, dans le guide de référence de Google Cloud CLI.

Le nom par défaut du fichier de configuration de connexion est kubectl-anthos-config.yaml, qui correspond au nom attendu par la CLI Google Cloud lors de la connexion au fichier. Si vous souhaitez attribuer un nom différent de celui par défaut, consultez la section correspondante de la section Distribuer la configuration de connexion ci-dessous.

Pour en savoir plus sur l'accès des utilisateurs, consultez la section Résoudre les problèmes d'accès des utilisateurs.

Distribuer la configuration de connexion

Voici quelques méthodes possibles pour distribuer le fichier de configuration :

  • Hébergez le fichier en l'associant à une URL accessible. Les utilisateurs peuvent spécifier cet emplacement avec l'option --login-config lors de l'exécution de gcloud anthos auth login, ce qui permet à la CLI Google Cloud d'obtenir le fichier.

    Envisagez d'héberger le fichier sur un hôte sécurisé. Pour en savoir plus sur l'utilisation de certificats PEM pour l'accès HTTPS sécurisé, consultez l'option --login-config-cert de gcloud CLI.

  • Fournissez manuellement le fichier à chaque utilisateur, avec des informations sur son emplacement de sauvegarde sur leur ordinateur local : Google Cloud CLI s'attend à trouver le fichier dans un emplacement par défaut spécifique au système d'exploitation. Si le fichier a un nom ou un emplacement autre que celui par défaut, vos utilisateurs doivent utiliser l'indicateur --login-config pour spécifier l'emplacement du fichier de configuration lors de l'exécution de commandes sur le cluster. Les instructions permettant aux utilisateurs d'enregistrer le fichier se trouvent dans la section Accéder aux clusters avec GKE Identity Service.

  • Utilisez vos outils internes pour transférer le fichier de configuration d'authentification sur l'ordinateur de chaque utilisateur. Google Cloud CLI s'attend à trouver le fichier aux emplacements suivants, en fonction du système d'exploitation utilisateur:

    Linux

    $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    macOS

    $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

    Windows

    %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Configurer l'accès d'un utilisateur via un autre processus d'authentification

Au lieu de distribuer le fichier de configuration à tous les utilisateurs, vous pouvez configurer l'accès d'un utilisateur à l'aide d'un autre processus d'authentification. Les utilisateurs peuvent s'authentifier directement sur le serveur GKE Identity Service à l'aide d'un nom de domaine complet. Pour les fournisseurs SAML, l'accès utilisateur est uniquement pris en charge par ce processus d'authentification alternatif.

Partager le nom de domaine complet avec les utilisateurs

Au lieu d'un fichier de configuration, les administrateurs de cluster peuvent partager le nom de domaine complet de leur serveur GKE Identity Service avec les utilisateurs. Les utilisateurs peuvent utiliser ce nom de domaine complet pour se connecter au cluster. L'URL du serveur GKE Identity Service est fournie dans l'un des formats suivants:

  • https://CLUSTER-SERVER-NAME.com
  • CLUSTER-SERVER-NAME.com

Connexion des utilisateurs à l'aide de certificats SNI approuvés

Les certificats SNI simplifient l'accès au cluster en exploitant des certificats de confiance déjà présents sur les appareils de l'entreprise. Les administrateurs utilisent ce certificat au moment de la création du cluster. En tant qu'utilisateur, vous devez utiliser le nom de domaine complet fourni par votre administrateur pour vous connecter au cluster. Vous pouvez également utiliser un fichier kubeconfig sécurisé dans lequel le jeton est stocké après une authentification réussie.

Avant d'exécuter la commande suivante, assurez-vous que le certificat utilisé par le serveur GKE Identity Service est approuvé par l'appareil sur lequel l'activité de connexion utilisateur est effectuée.

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE

Remplacez les éléments suivants :

  • APISERVER_URL: nom de domaine complet du serveur GKE Identity Service.
  • OUTPUT_FILE: utilisez cet indicateur si votre fichier kubeconfig se trouve à un autre emplacement que celui par défaut. Si cet indicateur est omis, les jetons d'authentification sont ajoutés au fichier kubeconfig à l'emplacement par défaut. Par exemple, --kubeconfig /path/to/custom.kubeconfig.

Accès utilisateur à l'aide de certificats émis par l'autorité de certification du cluster

En tant qu'utilisateur, si vous n'utilisez pas de certificat SNI approuvé au niveau du cluster, le certificat utilisé par le service de gestion des identités est délivré par l'autorité de certification du cluster. Les administrateurs distribuent ce certificat CA aux utilisateurs. Exécutez la commande suivante en utilisant le certificat CA du cluster pour vous connecter à votre cluster:

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

Configurer le contrôle des accès basé sur les rôles (RBAC)

L'authentification est souvent combinée avec le contrôle des accès basé sur les rôles (RBAC) de Kubernetes afin de fournir un contrôle d'accès plus précis aux clusters pour les utilisateurs authentifiés et les comptes de service. Dans la mesure du possible, il est recommandé de créer des stratégies RBAC qui utilisent des noms de groupe plutôt que des identifiants d'utilisateur. En associant explicitement vos stratégies RBAC à des groupes, vous pouvez gérer entièrement les droits d'accès des utilisateurs avec votre fournisseur d'identité. Ainsi, le cluster n'a pas besoin d'être mis à jour chaque fois que les privilèges utilisateur sont modifiés. Notez que pour configurer le contrôle des accès en fonction de l'appartenance à des groupes de sécurité avec OIDC, vous devez vous assurer que GKE Identity Service est configuré pour permettre l'obtention d'informations d'appartenance aux groupes auprès de votre fournisseur d'identité.

Par exemple, si vous souhaitez que certains utilisateurs authentifiés aient accès aux pods du cluster, créez un ClusterRole accordant l'accès à ces ressources, comme dans l'exemple suivant :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["pods"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Vous créez ensuite un ClusterRoleBinding correspondant pour accorder les autorisations dans le ClusterRole aux utilisateurs concernés (dans ce cas, les membres du groupe de sécurité us-east1-cluster-admins et l'utilisateur ayant l'ID u98523-4509823) :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-admins
subjects:
  # Grants anyone in the "us-east1-cluster-admins" group
  # read access to Pods in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Grants this specific user read access to Pods in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Dans l'exemple suivant, ce ClusterRoleBinding accorde des autorisations dans ClusterRole au groupe concerné avec l'ID 12345678-BBBb-cCCCC-0000-123456789012. Notez que ce paramètre ne concerne que les fournisseurs Azure AD et qu'il est disponible pour les clusters Google Distributed Cloud Virtual pour les clusters Bare Metal. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

Pour en savoir plus sur l'utilisation du contrôle des accès RBAC, consultez les pages Configurer le contrôle des accès basé sur les rôles et Utiliser l'autorisation RBAC.

Créer un rôle RBAC pour accéder à la console Google Cloud

Les utilisateurs authentifiés à l'aide de fournisseurs OIDC peuvent se connecter aux clusters depuis la console Google Cloud ainsi que depuis la ligne de commande.

Les utilisateurs authentifiés qui souhaitent accéder aux ressources d'un cluster dans la console Google Cloud doivent disposer des autorisations Kubernetes appropriées pour le faire. Si vous ne souhaitez pas accorder à ces utilisateurs des autorisations plus étendues, telles que celles d'un administrateur de cluster, vous pouvez créer un rôle RBAC personnalisé qui inclut les autorisations minimales requises pour afficher les nœuds, les volumes persistants, les pods et les classes de stockage du cluster. Vous pouvez définir cet ensemble d'autorisations en créant une ressource RBAC ClusterRole, cloud-console-reader, dans le cluster.

cloud-console-reader accorde à ses utilisateurs les autorisations get, list et watch sur les nœuds, les volumes persistants, les pods et les classes de stockage du cluster, ce qui leur permet d'afficher des informations détaillées sur ces ressources.

kubectl

Pour créer la ClusterRole cloud-console-reader et l'appliquer au cluster, exécutez la commande suivante:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

Vous pouvez ensuite accorder ce ClusterRole aux utilisateurs lors de la configuration de vos règles d'autorisation, comme décrit dans la section précédente. Notez que les utilisateurs doivent également disposer des autorisations IAM pour afficher les clusters dans la console Google Cloud.