Configurer la passerelle Connect

Ce guide s'adresse aux administrateurs de plate-forme qui doivent configurer la passerelle Connect afin qu'elle puisse être utilisée par les utilisateurs et les comptes de service de leur projet. Cette configuration permet aux utilisateurs d'effectuer les opérations suivantes :

  • utiliser la console Google Cloud pour se connecter aux clusters enregistrés en dehors de Google Cloud avec leur identité Google Cloud ;

  • utiliser kubectl pour accéder aux clusters via la passerelle Connect.

Cette configuration permet uniquement d'authentifier les utilisateurs et les services en fonction de leurs identifiants individuels, et non de leur adhésion à des groupes Google Groupes. Pour configurer la prise en charge de groupes supplémentaires, consultez la section Configurer la passerelle Connect avec Google Groupes.

Si vous n'êtes pas encore familiarisé avec la passerelle Connect, consultez notre présentation pour obtenir une explication sur ses concepts de base ainsi que son fonctionnement.

Avant de commencer

  1. Assurez-vous que les outils de ligne de commande suivants sont installés :

    • Dernière version de Google Cloud CLI, l'outil de ligne de commande permettant d'interagir avec Google Cloud.
    • kubectl pour exécuter des commandes sur les clusters Kubernetes. Si vous devez installer kubectl, suivez ces instructions.

    Si vous utilisez Cloud Shell comme environnement shell pour interagir avec Google Cloud, ces outils sont installés pour vous.

  2. Initialisez gcloud CLI pour l'utiliser avec votre projet ou exécutez les commandes suivantes pour autoriser gcloud CLI et définir votre projet comme valeur par défaut :

    gcloud auth login
gcloud config set project PROJECT_ID

Rôles IAM requis pour la configuration

Ce guide suppose que vous disposez de l'autorisation roles/owner dans votre projet. Si vous n'êtes pas un propriétaire du projet, demandez à un propriétaire de vous accorder des autorisations supplémentaires sur le projet afin de pouvoir effectuer les tâches suivantes :

  • Pour activer les API, vous avez besoin de l'autorisation serviceusage.services.enable, qui est incluse dans le rôle Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin). Un propriétaire de projet peut créer un rôle personnalisé avec l'autorisation serviceusage.services.enable activée ou vous accorder roles/serviceusage.serviceUsageAdmin, comme suit :

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/serviceusage.serviceUsageAdmin'

  • Pour accorder des autorisations IAM aux utilisateurs et aux comptes de service afin qu'ils puissent utiliser la passerelle Connect, vous devez disposer du rôle Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin), qu'un propriétaire du projet peut accorder avec la commande suivante :

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/resourcemanager.projectIamAdmin'

Activer les API

Pour ajouter la passerelle à votre projet, activez l'API Connect Gateway et les API de dépendance requises. Si vos utilisateurs souhaitent uniquement s'authentifier auprès de clusters à l'aide de la console Google Cloud, vous n'avez pas besoin d'activer connectgateway.googleapis.com mais vous devez activer les API restantes.

gcloud services enable --project=PROJECT_ID  \
    connectgateway.googleapis.com \
    anthos.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com

Vérifier les clusters enregistrés

Seuls les clusters enregistrés avec le parc de votre projet sont accessibles via la passerelle Connect. Les clusters GKE sur site et sur d'autres clouds publics sont automatiquement enregistrés lors de leur création. Cependant, les clusters GKE sur Google Cloud et les clusters associés doivent être enregistrés séparément. Si vous devez enregistrer un cluster, suivez les instructions de nos guides d'enregistrement de clusters. Notez que les clusters GKE doivent être enregistrés dans le parc pour utiliser la passerelle.

Pour vérifier que les clusters ont bien été enregistrés, exécutez la commande suivante :

gcloud container fleet memberships list

Vous devriez voir une liste de tous vos clusters enregistrés, comme illustré dans cet exemple :

NAME         EXTERNAL_ID
cluster-1    0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2    f0e2ea35-ee0c-11e9-be79-42010a8400c2

Accorder des rôles IAM aux utilisateurs

L'accès aux clusters est contrôlé par Identity and Access Management (IAM). Les rôles IAM requis pour accéder aux clusters à l'aide de kubectl diffèrent légèrement de ceux permettant d'accéder aux clusters dans la console Google Cloud, comme expliqué dans les sections suivantes.

Accorder l'accès aux rôles via kubectl

Les utilisateurs et les comptes de service ont besoin au minimum des rôles IAM suivants pour utiliser kubectl afin d'interagir avec les clusters via la passerelle Connect, sauf si l'utilisateur dispose de roles/owner dans le projet :

  • roles/gkehub.gatewayAdmin : ce rôle permet à un utilisateur d'accéder à l'API Connect Gateway pour gérer le cluster avec kubectl.

    • Si un utilisateur n'a besoin que d'un accès en lecture seule aux clusters connectés, vous pouvez accorder le rôle roles/gkehub.gatewayReader à la place.

    • Si un utilisateur a besoin d'un accès en lecture/écriture aux clusters connectés, vous pouvez accorder le rôle roles/gkehub.gatewayEditor.

  • roles/gkehub.viewer : ce rôle permet à un utilisateur de récupérer les fichiers kubeconfigs du cluster.

Pour en savoir plus sur les autorisations incluses dans ces rôles, consultez la page Rôles GKE Hub dans la documentation IAM.

Vous pouvez utiliser les commandes suivantes pour attribuer ces rôles :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

où :

  • MEMBER est l'utilisateur ou le compte de service, au format user|serviceAccount:emailID, par exemple :

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com

  • GATEWAY_ROLE correspond à roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou roles/gkehub.gatewayEditor.

Pour en savoir plus sur l'attribution d'autorisations et de rôles IAM, consultez la page Accorder, modifier et révoquer les accès à des ressources.

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

Les utilisateurs qui souhaitent interagir avec des clusters en dehors de Google Cloud à l'aide de la console Google Cloud doivent au moins disposer des rôles IAM suivants pour afficher les clusters :

  • roles/container.viewer. Ce rôle permet aux utilisateurs d'afficher la page "Clusters GKE" et les autres ressources de conteneur dans la console Google Cloud. 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. Notez qu'il s'agit de l'un des rôles requis pour accéder à kubectl. Si vous avez déjà attribué ce rôle à un utilisateur, vous n'avez pas besoin de l'accorder à nouveau. Pour en savoir plus sur les autorisations incluses dans ce rôle, consultez la page Rôles GKE Hub dans la documentation IAM.

    Dans la commande suivante, remplacez PROJECT_ID par l'ID du projet hôte du parc. Remplacez également MEMBER par l'adresse e-mail ou le compte de service de l'utilisateur au format user|serviceAccount:emailID, par exemple :

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

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 l'autorisation RBAC

Le serveur d'API Kubernetes de chaque cluster doit pouvoir autoriser les requêtes provenant de la console Google Cloud ou des commandes kubectl qui transitent par la passerelle Connect et sont émises par vos utilisateurs et comptes de service spécifiés. Pour ce faire, vous devez mettre à jour les stratégies de contrôle des accès basé sur les rôles (RBAC) sur chaque cluster que vous souhaitez rendre accessible via la passerelle. Vous devez ajouter ou mettre à jour les règles suivantes :

  • Une règle d'emprunt d'identité qui autorise l'agent Connect à envoyer des requêtes au serveur d'API Kubernetes pour le compte d'un utilisateur.
  • Une stratégie d'autorisation qui spécifie les autorisations dont l'utilisateur dispose sur le cluster. Il peut s'agir d'un rôle au niveau du cluster, tel que clusterrole/cluster-admin ou clusterrole/cloud-console-reader, ou d'un rôle au niveau de l'espace de noms, tel que role/default/pod-reader.

Créer un rôle cloud-console-reader (facultatif)

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 utilisateurs lors de la configuration de vos stratégies d'autorisation, comme décrit dans la section suivante.

Créer et appliquer les stratégies RBAC requises

L'exemple ci-dessous montre comment créer et appliquer les règles RBAC requises. Le moyen le plus simple de procéder consiste à générer et à appliquer les règles appropriées à l'aide de gcloud CLI. Si vous préférez, vous pouvez également créer un fichier de stratégie RBAC et l'appliquer avec kubectl.

gcloud

Pour générer et appliquer les règles au cluster choisi à l'aide de gcloud CLI, exécutez la commande suivante :

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

Remplacez les éléments suivants :

  • MEMBERSHIP_NAME : nom utilisé pour représenter de manière unique le cluster dans son parc. Pour savoir comment vérifier le nom d'appartenance de votre cluster, consultez la section Obtenir l'état d'appartenance à un parc.
  • ROLE : rôle Kubernetes que vous souhaitez attribuer aux utilisateurs du cluster, par exemple, clusterrole/cluster-admin, clusterrole/cloud-console-reader ou role/mynamespace/namespace-reader. Ce rôle doit déjà exister avant l'exécution de la commande.
  • USERS : adresses e-mail des utilisateurs (comptes utilisateur ou comptes de service) auxquels vous souhaitez accorder les autorisations, sous la forme d'une liste d'éléments séparés par une virgule. Exemple : --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
  • PROJECT_ID : identifiant du projet dans lequel le cluster est enregistré.
  • KUBECONFIG_PATH : chemin d'accès à l'emplacement local du fichier kubeconfig contenant une entrée pour le cluster. Dans la plupart des cas, il s'agit de $HOME/.kube/config.

  • KUBECONFIG_CONTEXT : contexte du cluster tel qu'il apparaît dans le fichier kubeconfig. Vous pouvez obtenir le contexte actuel à partir de la ligne de commande en exécutant la commande kubectl config current-context. Que vous utilisiez le contexte actuel ou non, assurez-vous qu'il fonctionne pour l'accès au cluster en exécutant la commande suivante :

    kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

Une fois la commande gcloud container fleet memberships generate-gateway-rbac exécutée, un message semblable à ce qui suit s'affiche à la fin du résultat, qui est tronqué par souci de lisibilité.

Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
---
Applying the generate RBAC policy to cluster with kubeconfig: artifacts/kubeconfig, context: example-cluster-admin@example-cluster
Writing RBAC policy for user: 222larabrown@gmail.com to cluster.
Successfully applied the RBAC policy to cluster.

Il s'agit du contexte permettant d'accéder au cluster via la passerelle Connect.

Pour en savoir plus sur la commande generate-gateway-rbac, consultez le guide de référence de gcloud CLI.

Si une erreur telle que ERROR: (gcloud.container.hub.memberships) Invalid choice: 'generate-gateway-rbac' s'affiche lorsque vous exécutez cette commande, mettez à jour votre instance de Google Cloud CLI en suivant le guide de mise à jour.

kubectl

L'exemple suivant montre comment créer des stratégies appropriées pour un utilisateur (foo@example.com) et un compte de service (test@example-project.iam.gserviceaccount.com), en lui attribuant les autorisations cluster-admin sur le cluster et en enregistrant le fichier de stratégie sous /tmp/gateway-rbac.yaml. Les stratégies sont ensuite appliquées au cluster associé au contexte actuel :

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - foo@example.com
  - test@example-project.iam.gserviceaccount.com
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-impersonate
roleRef:
  kind: ClusterRole
  name: gateway-impersonate
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin
subjects:
- kind: User
  name: foo@example.com
- kind: User
  name: test@example-project.iam.gserviceaccount.com
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH  -f /tmp/gateway-rbac.yaml

Pour en savoir plus sur la spécification des autorisations RBAC, consultez la section Utiliser l'autorisation RBAC.

Compatibilité avec VPC Service Controls

VPC Service Controls offre un niveau de sécurité supplémentaire pour les services Google Cloud, indépendamment de la gestion de l'authentification et des accès (IAM). Tandis que les stratégies IAM permettent un contrôle d'accès précis basé sur l'identité, VPC Service Controls offre une sécurité périmétrique basée sur le contexte plus étendue, et permet de contrôler la sortie des données au-delà du périmètre. Par exemple, vous pouvez indiquer que seuls certains projets peuvent accéder à vos données BigQuery. Pour en savoir plus sur la manière dont VPC Service Controls protège vos données, consultez la page Présentation de VPC Service Controls.

Pour renforcer la sécurité des données, vous pouvez utiliser VPC Service Controls avec la passerelle Connect, après vous être assuré que les API nécessaires à l'utilisation de la passerelle sont accessibles depuis le périmètre de service spécifié.

Étape suivante