S'authentifier à l'aide d'un jeton de support

Cette page explique comment configurer l'authentification à l'aide d'un jeton de support pour se connecter à des clusters enregistrés en dehors de Google Cloud. Une fois la configuration terminée, les administrateurs de cluster pourront se connecter aux clusters à partir de la console Google Cloud. De nombreux types de jetons de support sont acceptés, comme spécifié dans l'authentification Kubernetes. La méthode la plus simple consiste à créer un compte de service Kubernetes (KSA) dans le cluster et à utiliser son jeton de support pour se connecter.

Autres méthodes d'authentification

Au lieu de configurer l'authentification à l'aide d'un jeton de support, vous pouvez configurer l'une des méthodes d'authentification suivantes en fonction des besoins de votre organisation:

  • Google Identity, qui permet aux utilisateurs de se connecter à l'aide de leur identité Google Cloud Identity. Utilisez cette option si vos utilisateurs ont déjà accès à Google Cloud avec une identité Google.

  • Si votre cluster est configuré pour utiliser un fournisseur d'identité OIDC, vous pouvez vous en servir pour vous authentifier sur le cluster à partir de Google Cloud Console. Pour savoir comment configurer OIDC pour les clusters GKE, consultez les guides suivants :

Si ces méthodes d'authentification fournies par Google ne sont pas adaptées à votre organisation, suivez les instructions de cette page pour configurer l'authentification à l'aide d'un jeton de support.

Accorder des rôles IAM pour l'accès via la console Google Cloud

Les utilisateurs qui souhaitent afficher les clusters connectés à l'aide de la console Google Cloud doivent disposer au minimum des rôles IAM suivants :

  • roles/container.viewer Ce rôle permet aux utilisateurs d'afficher les ressources de conteneurs dans la console Google Cloud, y compris sur la page des clusters GKE. Pour en savoir plus sur les autorisations incluses dans ce rôle, consultez la page Rôles Kubernetes Engine dans la documentation IAM.

  • roles/gkehub.viewer Ce rôle permet aux utilisateurs d'afficher les clusters situés en dehors de Google Cloud dans la console Google Cloud. Les utilisateurs n'ont pas besoin de ce rôle si votre parc n'inclut pas de clusters en dehors de Google Cloud. Pour en savoir plus sur les autorisations incluses dans ce rôle, consultez la page Rôles GKE Hub dans la documentation IAM.

Exécutez les commandes suivantes pour attribuer ces rôles :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/gkehub.viewer

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet du projet hôte du parc.

  • EMAIL_ADDRESS : adresse e-mail associée au compte Google Cloud de l'utilisateur.

Pour en savoir plus sur l'attribution de rôles IAM, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations dans la documentation IAM.

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

Le contrôle des accès aux clusters est effectué à l'aide du contrôle des accès basé sur les rôles (RBAC) de Kubernetes.

Vous ou un administrateur du cluster devez de préférence créer un KSA pour chaque utilisateur qui se connecte au cluster. L'utilisation d'un jeton de support revient à utiliser un mot de passe, chaque utilisateur devant disposer de son propre compte. Lors de la connexion avec le jeton de support du KSA (compte de service Kubernetes), toutes les opérations sont exécutées au nom du KSA et sont limitées par les rôles RBAC qu'il détient.

Le KSA doit conserver au moins les rôles RBAC suivants dans le cluster pour y accéder via la console :

Créer et appliquer le rôle RBAC cloud-console-reader

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. 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 ClusterRole RBAC (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 le 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 attribuer ce rôle aux KSA, comme décrit dans la section suivante.

Créer et autoriser un KSA

kubectl

Pour créer un KSA et lui accorder des autorisations, procédez comme suit :

  1. Créez les ressources KSA et ClusterRoleBinding pour lier les ClusterRoles RBAC Kubernetes view et cloud-console-reader au KSA :

    KSA_NAME=KSA_NAME
kubectl create serviceaccount ${KSA_NAME}
kubectl create clusterrolebinding VIEW_BINDING_NAME \
   --clusterrole view --serviceaccount default:${KSA_NAME}
kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
   --clusterrole cloud-console-reader --serviceaccount default:${KSA_NAME}

    Remplacez l'élément suivant :

    • KSA_NAME : nom que vous avez choisi pour le KSA
    • VIEW_BINDING_NAME : nom que vous avez choisi pour la ressource ClusterRoleBinding view ; vous pouvez la nommer comme vous le souhaitez, mais il est sans doute plus simple de le faire en fonction du KSA
    • CLOUD_CONSOLE_READER_BINDING_NAME : nom que vous avez choisi pour la ressource ClusterRoleBinding cloud-console-reader ; vous pouvez également la nommer comme vous le souhaitez

  2. Selon l'accès que le compte de service devrait avoir, associez des rôles supplémentaires au KSA. Pour les options, consultez les rôles par défaut de Kubernetes.

    Par exemple, si vous souhaitez déployer une application Kubernetes à partir de Cloud Marketplace, associez le rôle cluster-admin au KSA :

    kubectl create clusterrolebinding BINDING_NAME \
   --clusterrole cluster-admin --serviceaccount default:KSA_NAME

    Remplacez BINDING_NAME par le nom de la liaison de rôle du cluster pour le compte de service.

Autoriser d'autres comptes

kubectl

Pour chaque autre utilisateur ou compte de service ayant accès au cluster, créez des ressources ClusterRoleBinding pour lier les rôles view et cloud-console-reader au compte :

  1. Liez les ClusterRoles view et cloud-console-reader :

    ACCOUNT_NAME=ACCOUNT_NAME
kubectl create clusterrolebinding VIEW_BINDING_NAME \
   --clusterrole view --serviceaccount default:${ACCOUNT_NAME}
kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
   --clusterrole cloud-console-reader --serviceaccount default:${ACCOUNT_NAME}

    Remplacez l'élément suivant :

    • ACCOUNT_NAME : compte de service Kubernetes
    • VIEW_BINDING_NAME : nom que vous avez choisi pour la ressource ClusterRoleBinding view ; vous pouvez la nommer comme vous le souhaitez, mais il est sans doute plus simple de le faire en fonction du compte de service
    • CLOUD_CONSOLE_READER_BINDING_NAME : nom que vous avez choisi pour la ressource ClusterRoleBinding view ; vous pouvez la nommer comme vous le souhaitez, mais il est sans doute plus simple de le faire en fonction du KSA

  2. Liez des rôles supplémentaires en fonction de l'accès dont le compte devrait disposer. Pour les options, consultez les rôles par défaut de Kubernetes.

    Par exemple, pour lier le rôle cluster-admin, exécutez la commande suivante :

    kubectl create clusterrolebinding BINDING_NAME \
   --clusterrole cluster-admin --serviceaccount default:ACCOUNT_NAME

    Remplacez BINDING_NAME par le nom de la liaison de rôle du cluster pour le compte de service.

Obtenir le jeton de support du KSA

kubectl

Pour acquérir le jeton de support du KSA, exécutez la commande suivante :

SECRET_NAME=KSA_NAME-token

kubectl apply -f - << __EOF__
apiVersion: v1
kind: Secret
metadata:
  name: "${SECRET_NAME}"
  annotations:
    kubernetes.io/service-account.name: "${KSA_NAME}"
type: kubernetes.io/service-account-token
__EOF__

until [[ $(kubectl get -o=jsonpath="{.data.token}" "secret/${SECRET_NAME}") ]]; do
  echo "waiting for token..." >&2;
  sleep 1;
done

kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 --decode

Remplacez KSA_NAME par le nom que vous avez choisi pour le KSA.

À partir du résultat de cette commande, copiez le jeton et enregistrez-le pour que les utilisateurs puissent l'utiliser pour se connecter à la console Google Cloud.