Cette page a été traduite par l'API Cloud Translation.

Accédez à des clusters privés Google Kubernetes Engine à partir de pools privés Cloud Build à l'aide d'Identity Service pour GKE

Ce tutoriel explique comment accéder au plan de contrôle d'un cluster Google Kubernetes Engine (GKE) privé à l'aide de pools privés Cloud Build. Cet accès vous permet d'utiliser Cloud Build pour déployer des applications et gérer des ressources sur un cluster GKE privé. Ce tutoriel est destiné aux administrateurs de plate-forme, aux administrateurs de cluster et aux développeurs. Nous partons du principe que vous connaissez GKE, Cloud Build, OpenID Connect et l'API gcloud. de ligne de commande.

Les pools privés Cloud Build et les plans de contrôle des clusters GKE s'exécutent tous deux sur des réseaux de cloud privé virtuel (VPC) appartenant à Google. Ces réseaux VPC sont appairés à votre propre réseau VPC sur Google Cloud. Cependant, l'appairage de réseaux VPC n'est pas compatible avec l'appairage transitif, qui peut constituer une restriction lorsque vous utilisez des pools privés Cloud Build. Ce tutoriel présente une solution qui utilise Identity Service pour GKE pour permettre aux nœuds de calcul d'un pool privé Cloud Build d'accéder au plan de contrôle d'un cluster GKE privé.

Présentation de l'architecture

Identity Service pour GKE est un proxy d'authentification pour les plans de contrôle des clusters GKE. Il sert de proxy pour les requêtes envoyées au serveur d'API et valide les jetons d'ID émis par les fournisseurs d'identité OpenID Connect (OIDC). Une fois que le proxy a validé un jeton d'ID, il ajoute les en-têtes HTTP d'emprunt d'identité d'utilisateur à la requête d'origine et la transfère au serveur d'API. Le proxy s'exécute en tant que compte de service Kubernetes autorisé à emprunter l'identité des utilisateurs et des groupes.

Identity Service pour le proxy GKE s'exécute en tant que pods sur les nœuds du cluster. Un service Kubernetes de type LoadBalancer expose le proxy en dehors du cluster. Si Identity Service pour GKE est activé sur un cluster privé, le programme d'installation ajoute une annotation au service Kubernetes pour provisionner un équilibreur de charge réseau passthrough interne. Le proxy est accessible via l'équilibreur de charge via une connexion d'appairage de réseaux VPC, par exemple à partir d'un pool privé Cloud Build, car le proxy s'exécute sur des nœuds de cluster de votre réseau VPC.

Vous pouvez configurer Google comme fournisseur d'identité OpenID Connect dans Identity Service pour GKE, car le système d'authentification OAuth 2.0 de Google est conforme à la spécification OpenID Connect. Afin d'obtenir des jetons d'identification pour un compte de service Google, vous pouvez utiliser la méthode generateIdToken de l'API Service Account Credentials. Les jetons d'ID sont émis et signés par Google.

En résumé, cette solution permet d'accéder au plan de contrôle du cluster GKE privé à l'aide du proxy Identity Service pour GKE. Les compilations exécutées sur un pool privé Cloud Build se connectent au proxy via une connexion d'appairage de réseaux VPC. La compilation en cours d'exécution sur le pool privé Cloud Build s'exécute en tant que compte de service Google. Ce compte de service Google peut obtenir un jeton d'identification pour s'authentifier auprès du proxy à partir de l'API Service Account Credentials.

Le schéma suivant illustre l'architecture décrite dans le texte précédent:

Accéder à des clusters GKE privés à l'aide d'Identity Service pour GKE

Toutes les communications de cette solution ont lieu sur un espace d'adressage IP interne. Les nœuds de calcul du pool privé n'ont pas besoin d'une connectivité Internet publique.

Les autorisations Identity and Access Management (IAM) accordées aux comptes utilisateur et aux comptes de service Google ne s'appliquent pas lorsqu'ils s'authentifient à l'aide d'Identity Service pour GKE. À la place, vous utilisez le contrôle des accès basé sur les rôles Kubernetes (RBAC) pour gérer les autorisations de cluster pour ces comptes.

Avant de commencer

Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer les API Cloud Build, GKE, Identity-Aware Proxy (IAP), and Service Networking APIs :

gcloud services enable cloudbuild.googleapis.com container.googleapis.com iap.googleapis.com servicenetworking.googleapis.com

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer les API Cloud Build, GKE, Identity-Aware Proxy (IAP), and Service Networking APIs :

gcloud services enable cloudbuild.googleapis.com container.googleapis.com iap.googleapis.com servicenetworking.googleapis.com

Créer un cluster GKE privé

Dans Cloud Shell, créez un cluster GKE sans client au point de terminaison public du plan de contrôle et sur lequel Identity Service pour GKE est installé:
```
gcloud container clusters create CLUSTER  \
  --enable-identity-service \
  --enable-ip-alias \
  --enable-master-authorized-networks \
  --enable-private-endpoint \
  --enable-private-nodes \
  --master-ipv4-cidr CONTROL_PANE_CIDR \
  --network NETWORK\
  --release-channel regular \
  --scopes cloud-platform \
  --subnetwork SUBNET \
  --tags NODE_TAGS \
  --workload-pool PROJECT_ID.svc.id.goog \
  --zone ZONE
```
Remplacez les éléments suivants :
- CLUSTER : nom du cluster. Pour ce tutoriel, utilisez private-cluster.
- CONTROL_PANE_CIDR: plage d'adresses IP du plan de contrôle. Il doit comporter le préfixe /28. Pour ce tutoriel, vous pouvez utiliser 172.16.0.32/28.
- NETWORK: réseau VPC auquel le plan de contrôle se connecte. Pour ce tutoriel, utilisez default.
- SUBNET: sous-réseau auquel le plan de contrôle du cluster GKE se connecte. Le sous-réseau doit appartenir au réseau VPC spécifié par NETWORK. Pour ce tutoriel, utilisez default.
- NODE_TAGS: liste de tags réseau séparés par une virgule à appliquer aux nœuds. Pour ce tutoriel, utilisez private-cluster-node.
- PROJECT_ID : ID de votre projet Google Cloud.
- ZONE: zone du cluster GKE Pour ce tutoriel, utilisez us-central1-f.
Tenez compte des remarques suivantes pour cette commande :
- L'option --enable-identity-service active Identity Service pour GKE sur le cluster. Dans votre propre environnement, vous pouvez activer Identity Service pour GKE sur un cluster existant.
- L'option --enable-private-endpoint configure le plan de contrôle pour qu'il soit accessible qu'à l'aide d'adresses IP internes.
- L'option --enable-private-nodes configure les nœuds du cluster afin qu'ils n'aient que des adresses IP internes.
- Les options --enable-master-authorized-networks et --enable-private-nodes n'autorisent l'accès au serveur d'API qu'à partir des réseaux privés spécifiés par l'option --network.
- L'option facultative --workload-pool active Workload Identity. Elle n'est pas nécessaire pour ce tutoriel.
Ajoutez une règle de pare-feu qui autorise le contrôle du cluster GKE pour vous connecter au webhook d'admission de validation pour les ressources ClientConfig:
```
gcloud compute firewall-rules create allow-control-plane-clientconfig-webhook \
  --allow tcp:15000 \
  --network NETWORK\
  --source-ranges CONTROL_PANE_CIDR\
  --target-tags NODE_TAGS
```
ClientConfig est un type de ressource personnalisé (CRD) Kubernetes que Identity Service pour GKE utilise pour configurer comment interagir avec les fournisseurs d'identité.

Enregistrer Identity Service pour GKE en tant qu'application cliente OAuth 2.0

Dans cette section, vous allez enregistrer Identity Service pour GKE en tant qu'application cliente à l'aide du système d'authentification OAuth 2.0 de Google.

Ouvrez la page Identifiants dans la console Google Cloud.

Ouvrez la page Identifiants.
Cliquez sur Créer des identifiants.
Sélectionnez ID client OAuth.

Si l'écran d'autorisation n'a pas encore été configuré pour le projet Google Cloud, cliquez sur Configurer l'écran d'autorisation. Suivez la documentation sur la configuration de l'écran de consentement. Pour ce tutoriel, définissez les valeurs suivantes:
- Le Type d'utilisateur peut être Interne ou Externe. Pour ce tutoriel, vous pouvez sélectionner "Interne".
- Les valeurs associées aux champs Nom de l'application, Adresse e-mail d'assistance utilisateur et Coordonnées du développeur sont obligatoires et peuvent avoir n'importe quelle valeur.
- Vous n'avez pas besoin d'ajouter de champs d'application pour ce tutoriel.
Une fois la configuration de l'écran d'autorisation terminée, cliquez sur "Retour au tableau de bord", puis recommencez à partir de l'étape 1 de la procédure en cours.
Dans la liste Type d'application, sélectionnez Application Web.
Dans le champ Nom, saisissez un nom pour l'ID client. Pour ce tutoriel, utiliser Identity Service for GKE.
Cliquez sur Créer.

Une boîte de dialogue s'affiche. Copiez la valeur de Your Client ID (Votre ID client). vous en aurez besoin plus tard procédure.
Cliquez sur OK pour fermer la boîte de dialogue.
Dans Cloud Shell, créez sous votre répertoire d'accueil un sous-répertoire appelé cloud-build-private-pools-gke-tutorial, puis accédez à ce répertoire:

mkdir -p ~/cloud-build-private-pools-gke-tutorial cd ~/cloud-build-private-pools-gke-tutorial
Dans le nouveau répertoire, créez un fichier YAML nommé client-config-patch.yaml qui contient dont vous aurez besoin ultérieurement pour corriger la ressource Identity Service pour GKE ClientConfig:
```
cat << EOF > client-config-patch.yaml
spec:
  authentication:
  - name: google-oidc
    oidc:
      clientID: CLIENT_ID
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent,access_type=offline
      issuerURI: https://accounts.google.com
      kubectlRedirectURI: http://localhost:10000/callback
      scopes: email
      userClaim: email
      userPrefix: '-'
EOF
```
Remplacez CLIENT_ID par l'ID client OAuth de l'étape précédente.

Veuillez noter les points suivants à propos de ce correctif:
- Les jetons d'identification émis par le système d'authentification OAuth 2.0 de Google contiennent un identifiant numérique unique dans la sous-revendication (objet). L'utilisation de cet identifiant opaque dans les liaisons de rôles rend difficile l'identification du sujet d'une liaison de rôle. Ce correctif configure donc Identity Service pour GKE afin d'utiliser la revendication d'adresse e-mail des jetons d'ID pour identifier les utilisateurs, au lieu d'utiliser la sous-revendication par défaut.
- Le champ d'application de l'adresse e-mail est ajouté de sorte que les jetons d'ID émis incluent la revendication d'adresse e-mail.
- Les champs cloudConsoleRedirectURI, extraParams, kubectlRedirectURI et les champs d'application sont utilisés lorsque les développeurs s'authentifient auprès du cluster à l'aide d'Identity Service pour GKE. Ils ne sont pas utilisés lorsque les comptes de service Google s'authentifient auprès du cluster. Le champ kubectlRedirectURI est obligatoire.
- Le champ userPrefix est un préfixe destiné aux utilisateurs qui s'authentifient à l'aide du fournisseur d'identité configuré. La valeur '-' signifie qu'il n'y a pas de préfixe.
- Le champ spec.authentication est un tableau. Vous pouvez utiliser plusieurs fournisseurs d'identité OpenID Connect avec Identity Service pour GKE. Par exemple, vous pouvez utiliser Google comme fournisseur d'identité pour authentifier les comptes de service Google, et un autre fournisseur d'identité pour authentifier les développeurs.
Pour en savoir plus sur les champs de cette configuration, consultez S'authentifier auprès de GKE à l'aide de fournisseurs d'identité externes.

Créer un compte de service Google afin de configurer Identity Service pour GKE

Dans Cloud Shell, créez un compte de service Google Cloud :
```
gcloud iam service-accounts create ISG_GSA \
  --display-name "Configure Identity Service for GKE"
```
Remplacez ISG_GSA par le nom que vous souhaitez utiliser pour le compte de service Google. Pour ce tutoriel, utilisez identity-service-for-gke.

Vous allez attribuer ce compte de service Google à une instance de VM Compute Engine afin de configurer Identity Service pour GKE et le contrôle des accès basé sur les rôles Kubernetes sur le cluster.
Attribuez le rôle d'administrateur Kubernetes Engine. sur le projet au compte de service Google:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
  --role roles/container.admin
```
Ce rôle fournit les autorisations nécessaires pour effectuer les tâches suivantes de ce tutoriel:
- Configurer les paramètres Identity Service pour GKE sur les clusters du projet
- Créer des liaisons de rôles de cluster et des liaisons de rôles de cluster dans le cluster

Configurer Identity Service pour GKE

Pour configurer Identity Service pour GKE, vous devez avoir accès au plan de contrôle du cluster. Dans ce tutoriel, vous allez créer une instance de VM Compute Engine pour accéder au plan de contrôle.

Vous avez besoin d'un accès SSH à l'instance de VM. Pour activer un accès SSH authentifié et autorisé depuis l'extérieur du réseau VPC à l'instance de VM, vous utilisez le transfert TCP avec Identity-Aware Proxy (IAP). Cette fonctionnalité permet l'accès SSH sans que l'instance de VM ne dispose d'une adresse IP publique.

Dans Cloud Shell, créez une règle de pare-feu autorisant l'accès SSH à l'aide de Transfert TCP IAP vers toutes les instances de VM ayant le tag réseau ssh-iap:
```
gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
  --allow tcp:22 \
  --description "Allow SSH tunneling using Identity-Aware Proxy" \
  --network NETWORK \
  --source-ranges 35.235.240.0/20 \
  --target-tags ssh-iap
```
La plage source contient les adresses IP utilisées par IAP pour le transfert TCP.
Créez une instance de VM Compute Engine sur le même réseau VPC que Cluster GKE:
```
gcloud compute instances create VM \
  --metadata enable-oslogin=TRUE \
  --network NETWORK \
  --no-address \
  --scopes cloud-platform,userinfo-email \
  --service-account ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
  --subnet SUBNET  \
  --tags ssh-iap \
  --zone ZONE
```
Remplacez VM par le nom que vous souhaitez utiliser pour l'instance de VM. Pour ce tutoriel, utilisez identity-service-for-gke-configuration.

Notez les points suivants à propos de la commande ci-dessus:
- L'option --service-account associe le compte de service Google à l'instance de VM.
- Le niveau d'accès cloud-platform est requis pour accéder au compte de service Credentials.
- Le niveau d'accès userinfo-email est utile lors de la création d'une instance de VM pour gérer le contrôle des accès basé sur les rôles Kubernetes. Il est facultatif pour ce tutoriel.
- L'option --no-address signifie que l'instance de VM est créée sans adresse IP externe.
- La valeur facultative des métadonnées d'instance enable-oslogin active OS Login sur l'instance de VM. OS Login permet de gérer l'accès SSH aux instances de VM à l'aide d'IAM.
Copiez le fichier correctif ClientConfig sur l'instance de VM:
```
gcloud compute scp client-config-patch.yaml VM:~ --tunnel-through-iap --zone ZONE
```
L'option --tunnel-through-iap demande à gcloud de créer un tunnel pour la connexion. via IAP.
Connectez-vous à l'instance de VM via SSH :
```
gcloud compute ssh VM --tunnel-through-iap --zone ZONE
```
Vous exécuterez les autres commandes de cette section à partir de la session SSH.
Installez l'outil de ligne de commande kubectl et le binaire gke-gcloud-auth-plugin dans l'instance de VM:
```
sudo apt-get install -y kubectl google-cloud-sdk-gke-gcloud-auth-plugin
```

Récupérez les identifiants du cluster GKE:

export USE_GKE_GCLOUD_AUTH_PLUGIN=True
gcloud container clusters get-credentials CLUSTER --zone ZONE

Appliquez un correctif à la ressource ClientConfig par défaut:

kubectl patch clientconfig default \
    --namespace kube-public \
    --patch-file client-config-patch.yaml \
    --type merge

Extrayez le champ certificateAuthorityData de la ressource ClientConfig par défaut corrigée et stockez-le dans un fichier nommé certificateAuthorityData.pem:

kubectl get clientconfig default \
     --namespace kube-public \
     --output jsonpath='{.spec.certificateAuthorityData}' \
     | base64 --decode > certificateAuthorityData.pem

Extrayez le champ "server" de la ressource ClientConfig par défaut corrigée et stockez-le dans un fichier nommé server.txt:
```
kubectl get clientconfig default \
     --namespace kube-public \
     --output jsonpath='{.spec.server}' > server.txt
```
Quittez la session SSH :
```
exit
```

Vérifier la configuration du cluster (facultatif)

Avant de continuer, vous pouvez vérifier qu'Identity Service pour GKE a été correctement configuré sur le cluster. Vous validez la configuration en utilisant le compte de service Google associé à l'instance de VM pour s'authentifier auprès du cluster à l'aide d'Identity Service pour GKE.

Dans Cloud Shell, accordez au compte de service lui-même l'autorisation Créateur de jetons d'identité OpenID Connect (OpenID Connect) sur le compte de service Google:
```
gcloud iam service-accounts add-iam-policy-binding \
  ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
  --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
  --role roles/iam.serviceAccountOpenIdTokenCreator
```
Ce rôle fournit l'autorisation iam.serviceAccounts.getOpenIdToken nécessaire pour demander des jetons d'identification pour le compte de service à partir de l'API Service Account Credentials.
Connectez-vous à l'instance de VM via SSH :
```
gcloud compute ssh VM --tunnel-through-iap --zone ZONE
```
Vous exécuterez les autres commandes de cette section à partir de la session SSH.
Demandez un jeton d'accès OAuth 2.0 au serveur de métadonnées pour le compte de service Google associé à l'instance de VM, en utilisant l'ID client OAuth comme revendication aud (audience) demandée:
```
ACCESS_TOKEN=$(curl --silent --header "Metadata-Flavor: Google" \
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
       | python3 -c 'import json, sys; print(json.load(sys.stdin).get("access_token"))')
```
Le corps de la réponse du serveur de métadonnées est un document JSON. La commande utilise un script Python intégré pour extraire le champ access_token du corps de la réponse.

Demandez un jeton d'ID à l'API Service Account Credentials pour le compte de service Google associé à l'instance de VM:

ID_TOKEN=$(curl --silent --request POST \
    --data '{"audience": "CLIENT_ID", "includeEmail": true}' \
    --header "Authorization: Bearer $ACCESS_TOKEN" \
    --header "Content-Type: application/json; charset=utf-8" \
"https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/ISG_GSA@PROJECT_ID.iam.gserviceaccount.com:generateIdToken" \
       | python3 -c 'import json, sys; print(json.load(sys.stdin).get("token"))')

Notez les points suivants à propos de la commande ci-dessus:

Le champ audience dans le corps de la requête JSON spécifie la revendication aud (audience) demandée pour le jeton d'ID.
Le jeton d'accès de l'étape précédente permet de s'authentifier auprès de l'API.

Affichez les revendications dans le jeton d'ID:
```
echo $ID_TOKEN \
    | cut -d. -f2 \
    | base64 --decode --ignore-garbage 2> /dev/null \
    | python3 -m json.tool
```
Vérifiez que la revendication email contient l'adresse e-mail du compte de service Google.
Utilisez le jeton d'ID pour vous authentifier auprès du plan de contrôle à l'aide d'Identity Service pour GKE:
```
kubectl get namespaces \
    --certificate-authority certificateAuthorityData.pem \
    --server $(cat server.txt) \
    --token $ID_TOKEN
```
Le résultat se présente comme suit :
```
  Error from server (Forbidden): namespaces is forbidden: User "ISG_GSA@PROJECT_ID.iam.gserviceaccount.com" cannot list resource "namespaces" in API group "" at the cluster scope
```
Cette erreur est fréquente. Bien que le compte de service Google ait reçu des autorisations IAM sur les clusters GKE du projet, les autorisations IAM ne s'appliquent pas lorsque vous vous authentifiez à l'aide d'Identity Service pour GKE. À la place, vous configurez l'accès à l'aide du contrôle des accès basé sur les rôles Kubernetes (RBAC).
Créez une liaison de rôle de cluster qui attribue le rôle de cluster view au compte de service Google lorsque celui-ci s'authentifie auprès du cluster à l'aide du fournisseur OpenID Connect de Google:
```
kubectl create clusterrolebinding ISG_GSA-cluster-view \
    --clusterrole view \
    --user ISG_GSA@PROJECT_ID.iam.gserviceaccount.com
```
Si vous définissez une valeur userPrefix autre que - dans ClientConfig dans votre propre environnement, ajoutez le préfixe à la valeur de l'option --user dans cette commande.

Accédez au cluster GKE à l'aide d'Identity Service pour GKE:

kubectl get namespaces \
    --certificate-authority certificateAuthorityData.pem \
    --server $(cat server.txt) \
    --token $ID_TOKEN

Le résultat se présente comme suit :

NAME                      STATUS   AGE
anthos-identity-service   Active   1h
default                   Active   1h
kube-node-lease           Active   1h
kube-public               Active   1h
kube-system               Active   1h

Quittez la session SSH :
```
exit
```

Créer un contexte pour l'outil `kubectl`

La commande kubectl peut utiliser un fichier kubeconfig pour configurer l'accès aux clusters. Un fichier kubeconfig contient un ou plusieurs contextes. Chaque contexte a un nom et inclut éventuellement des informations de connectivité du cluster, des identifiants permettant de s'authentifier auprès du cluster et un espace de noms par défaut.

Dans cette section, vous allez créer un fichier kubeconfig contenant un contexte. Le contexte inclut les détails de connectivité du service Identity Service pour le proxy GKE de votre cluster. Vous n'ajoutez aucun identifiant utilisateur au fichier kubeconfig.

Dans Cloud Shell, copiez dans le répertoire actuel les fichiers contenant les données de l'autorité de certification et l'URL du serveur de l'instance de VM:
```
gcloud compute scp VM:~/certificateAuthorityData.pem VM:~/server.txt . \
    --tunnel-through-iap --zone ZONE
```
Créez un contexte et une configuration de cluster que vous utiliserez plus tard pour vous connecter au cluster GKE à partir de Cloud Build:
```
kubectl config set-context private-cluster \
    --cluster private-cluster \
    --kubeconfig kubeconfig
```
L'option --kubeconfig crée le contexte et la configuration du cluster dans un nouveau fichier nommé kubeconfig dans le répertoire actuel.

Cette commande utilise le nom du cluster GKE comme nom de configuration du cluster pour le contexte. Dans votre propre environnement, vous pouvez utiliser un nom de configuration de cluster différent dans le contexte.

Définissez le champ certificateAuthorityData dans la configuration du cluster:

kubectl config set-cluster private-cluster \
    --certificate-authority certificateAuthorityData.pem \
    --embed-certs \
    --kubeconfig kubeconfig

Définissez le champ server dans la configuration du cluster:

kubectl config set-cluster private-cluster \
    --kubeconfig kubeconfig \
    --server $(cat server.txt)

Créer un compte de service Google pour Cloud Build

Dans Cloud Shell, créez un compte de service Google pour exécuter des compilations sur le Pool privé Cloud Build:
```
gcloud iam service-accounts create CB_GSA \
  --description "Runs builds on Cloud Build private pools" \
  --display-name "Cloud Build private pool"
```
Remplacez CB_GSA par le nom que vous souhaitez utiliser pour le compte de service Google. Pour ce tutoriel, utilisez cloud-build-private-pool.
Accordez le rôle de compte de service Cloud Build sur le projet au compte de service Google:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/cloudbuild.builds.builder
```
Ce rôle fournit les autorisations par défaut du compte de service Cloud Build géré par Google.
Accordez au compte de service lui-même l'autorisation Créateur de jetons d'identité OpenID Connect (OpenID Connect) du compte de service Google:
```
gcloud iam service-accounts add-iam-policy-binding \
    CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.serviceAccountOpenIdTokenCreator
```
Ce rôle fournit l'autorisation iam.serviceAccounts.getOpenIdToken nécessaire pour demander des jetons d'identification pour le compte de service à partir de l'API Service Account Credentials.
Connectez-vous à l'instance de VM via SSH :
```
gcloud compute ssh VM --tunnel-through-iap --zone ZONE
```
Vous exécuterez les autres commandes de cette section à partir de la session SSH.
Dans la session SSH, créez une liaison de rôle de cluster Kubernetes qui attribue le rôle de cluster cluster-admin au compte de service Google lorsque celui-ci s'authentifie auprès du cluster à l'aide du fournisseur OpenID Connect de Google:
```
kubectl create clusterrolebinding CB_GSA-cluster-admin \
    --clusterrole cluster-admin \
    --user CB_GSA@PROJECT_ID.iam.gserviceaccount.com
```
Le rôle de cluster cluster-admin accorde des autorisations étendues à l'échelle du cluster. Dans votre propre environnement, vous pouvez utiliser un rôle de cluster qui ne fournit que les autorisations nécessaires aux tâches effectuées par Cloud Build. Vous pouvez également utiliser des liaisons de rôles pour n'accorder des autorisations qu'à des espaces de noms spécifiques.

Si vous définissez un userPrefix dans ClientConfig de votre propre environnement, vous devez ajouter ce préfixe à la valeur de l'option --user dans cette commande.
Quittez la session SSH :
```
exit
```

Créer un pool privé Cloud Build

Dans Cloud Shell, allouez une plage d'adresses IP dans votre réseau VPC pour la connexion avec le pool privé:
```
gcloud compute addresses create RESERVED_RANGE_NAME \
--addresses RESERVED_RANGE_START_IP\
    --description "Cloud Build private pool reserved range" \
    --global \
    --network NETWORK \
    --prefix-length RESERVED_RANGE_PREFIX_LENGTH \
    --purpose VPC_PEERING
```
Remplacez les éléments suivants :
- RESERVED_RANGE_NAME: nom de la plage d'adresses IP allouée qui héberge le pool privé Cloud Build. Pour ce tutoriel, utilisez cloud-build-private-pool.
- RESERVED_RANGE_START_IP: première adresse IP de la plage d'adresses IP allouée. Pour ce tutoriel, utilisez 192.168.12.0.
- RESERVED_RANGE_PREFIX_LENGTH: longueur de préfixe (masque de sous-réseau) de la plage d'adresses IP allouée. La longueur du préfixe doit être /23 ou un nombre inférieur, par exemple /22 ou /21. Plus le nombre est faible, plus la plage d'adresses est étendue. Pour ce tutoriel, utilisez 23 et ne saisissez pas la barre oblique (/) du début.

Créez une règle de pare-feu pour autoriser le trafic entrant depuis la plage d'adresses IP réservée vers les autres ressources de votre réseau VPC:

gcloud compute firewall-rules create allow-private-pools-ingress \
    --allow all \
    --network NETWORK \
    --source-ranges RESERVED_RANGE_START_IP/RESERVED_RANGE_PREFIX_LENGTH

Créez une connexion de service privée pour connecter votre réseau VPC au service Service Networking:
```
gcloud services vpc-peerings connect \
    --network NETWORK \
    --ranges RESERVED_RANGE_NAME \
    --service servicenetworking.googleapis.com
```
Les pools privés Cloud Build exécutent des nœuds de calcul à l'aide de Service Networking. La connexion de service privée permet à votre réseau VPC de communiquer avec le pool privé sur la plage d'adresses IP internes allouée, à l'aide d'une connexion d'appairage de réseaux VPC.

La création de la connexion au service privé peut prendre quelques minutes.

Si vous utilisez un VPC partagé dans votre propre environnement, consultez Configurer votre environnement pour obtenir des informations supplémentaires sur les étapes de création de la connexion de service privée.
Créez un pool privé Cloud Build dans un réseau VPC appartenant à Google qui est appairé à votre réseau VPC:
```
gcloud builds worker-pools create PRIVATE_POOL_NAME \
   --no-public-egress \
   --peered-network projects/PROJECT_ID/global/networks/NETWORK \
   --region REGION
```
Remplacez les éléments suivants :
- PRIVATE_POOL_NAME: nom du pool privé. Pour ce tutoriel, utilisez private-pool.
- REGION: région à utiliser pour le pool privé. Pour ce tutoriel, utilisez us-central1.
L'option --no-public-egress signifie que les nœuds de calcul du pool privé n'ont pas d'adresse IP publique. Dans votre environnement, vous pouvez supprimer cette option si vous souhaitez que les nœuds de calcul du pool privé disposent d'une connectivité Internet à l'aide d'adresses IP publiques.

Pour en savoir plus sur les autres options de configuration, telles que le type de machine et la taille de disque des nœuds de calcul du pool privé, consultez Créer et gérer des pools privés.

Valider la solution

Dans cette section, vous allez vérifier la solution en exécutant une compilation sur le pool privé Cloud Build. La compilation accède au cluster GKE privé.

Dans Cloud Shell, créez un bucket Cloud Storage pour stocker les journaux de compilation à partir de Cloud Build:
```
gcloud storage buckets create gs://PROJECT_ID-build-logs --location=REGION
```
Créez un fichier de configuration de compilation pour Cloud Build:
```
cat << "EOF" > cloudbuild.yaml
steps:
- id: list-services
  name: gcr.io/google.com/cloudsdktool/google-cloud-cli
  entrypoint: bash
  args:
  - -eEuo
  - pipefail
  - -c
  - |-
    kubectl config use-context $_KUBECTL_CONTEXT

    ACCESS_TOKEN=$$(curl --silent \
        --header "Metadata-Flavor: Google" \
        http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
        | python3 -c 'import json, sys; print(json.load(sys.stdin).get("access_token"))')

    ID_TOKEN=$$(curl --silent --request POST \
        --data '{"audience": "CLIENT_ID", "includeEmail": true}' \
        --header "Authorization: Bearer $$ACCESS_TOKEN" \
        --header "Content-Type: application/json; charset=utf-8" \
        "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$_SERVICE_ACCOUNT:generateIdToken" \
        | python3 -c 'import json, sys; print(json.load(sys.stdin).get("token"))')

    kubectl get services --namespace $_NAMESPACE --token $$ID_TOKEN

logsBucket: gs://PROJECT_ID-build-logs

options:
  env:
  - KUBECONFIG=/workspace/$_KUBECONFIG

substitutions:
  _KUBECONFIG: kubeconfig
  _KUBECTL_CONTEXT: private-cluster
  _NAMESPACE: default

serviceAccount: projects/$PROJECT_ID/serviceAccounts/$_SERVICE_ACCOUNT
EOF
```
L'étape du fichier de configuration de compilation effectue les opérations suivantes:
1. Passe au contexte kubectl spécifié par la substitution _KUBECTL_CONTEXT. La valeur de substitution par défaut est private-cluster.
2. Récupère un jeton d'accès à partir du serveur de métadonnées. Le jeton d'accès est émis pour le compte de service Google qui exécute la compilation.
3. Génère un jeton d'ID à l'aide de l'API Service Account Credentials. La requête de génération du jeton d'ID est authentifiée à l'aide du jeton d'accès. La revendication aud (audience) demandée du jeton d'ID correspond à l'ID client OAuth 2.0 spécifié par la substitution _CLIENT_ID.
4. Répertorie les services Kubernetes dans l'espace de noms spécifié par la substitution _NAMESPACE. La valeur de substitution par défaut est default. La requête est authentifiée à l'aide du jeton d'ID généré dans la commande précédente.
Notez les points suivants concernant le fichier de configuration de compilation:
- Le caractère $ est le préfixe des substitutions. $$ est utilisé pour l'extension des paramètres bash et la substitution de commandes.
- Les substitutions _KUBECONFIG et _KUBECTL_CONTEXT permettent de spécifier différents fichiers kubeconfig et différents contextes lorsque vous exécutez une compilation. Ces substitutions vous permettent de gérer plusieurs configurations de cluster à l'aide d'un seul fichier kubeconfig avec plusieurs contextes ou de plusieurs fichiers kubeconfig.
- Aucune valeur par défaut n'est associée à la substitution _SERVICE_ACCOUNT. Vous devez indiquer une valeur pour cette substitution lorsque vous exécutez une compilation.
- Le bloc options définit la variable d'environnement KUBECONFIG pour toutes les étapes de la compilation.
- L'étape de compilation utilise l'image du compilateur gcr.io/google.com/cloudsdktool/google-cloud-cli. Il s'agit d'une image de conteneur volumineuse, dont l'extraction depuis le registre vers le nœud de calcul du pool privé prend un certain temps. Pour réduire le temps nécessaire à l'extraction de l'image de compilateur, vous pouvez créer une image de compilateur personnalisée contenant uniquement les outils nécessaires à l'étape de compilation, tels que curl, kubectl et Python.
Pour en savoir plus sur les scripts shell intégrés dans les fichiers de configuration de compilation, consultez la section Exécuter des scripts bash.
Exécutez une compilation à l'aide du fichier de configuration de compilation et des fichiers du répertoire actuel:
```
gcloud builds submit \
    --config cloudbuild.yaml \
    --region REGION \
    --substitutions _SERVICE_ACCOUNT=CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --worker-pool projects/PROJECT_ID/locations/REGION/workerPools/PRIVATE_POOL_NAME
```
La commande importe tous les fichiers du répertoire actuel vers Cloud Storage pour que Cloud Build puisse les utiliser. L'étape de compilation utilise le fichier kubeconfig pour se connecter au cluster GKE.

Vers la fin du résultat, des lignes semblables aux suivantes s'affichent:
```
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   2h
```
Ce résultat montre que le nœud de calcul du pool privé s'est connecté au plan de contrôle du cluster à l'aide du proxy d'authentification Identity Service pour GKE.

Dépannage

Si vous ne parvenez pas à vous connecter à l'instance de VM via SSH, ajoutez l'option --troubleshoot pour déterminer la cause des problèmes de connectivité:

gcloud compute ssh VM --tunnel-through-iap --zone ZONE --troubleshoot

Si le message Error from server (NotFound): clientconfigs.authentication.gke.io "default" not found s'affiche lorsque vous appliquez un correctif à ClientConfig par défaut sur le cluster GKE, assurez-vous d'avoir créé la règle de pare-feu comme décrit dans la section Créer un cluster GKE privé. Vérifiez que la règle de pare-feu existe:

gcloud compute firewall-rules describe allow-control-plane-clientconfig-webhook

Si vous ne parvenez pas à vous authentifier auprès d'Identity Service pour le proxy GKE, recherchez les erreurs dans les journaux des pods du déploiement gke-oidc-service:

gcloud compute ssh VM --tunnel-through-iap --zone ZONE --command \
    'kubectl logs deployment/gke-oidc-service \
         --namespace anthos-identity-service --all-containers'

Si vous rencontrez d'autres problèmes avec ce tutoriel, nous vous recommandons de consulter les documents suivants:

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer le projet

Attention : La suppression d'un projet aura les effets suivants :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches de ce document, lorsque vous le supprimez, vous supprimez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

Supprimez un projet Google Cloud :

gcloud projects delete PROJECT_ID

Supprimer les ressources

Si vous souhaitez conserver le projet que vous avez utilisé dans ce tutoriel, supprimez les différentes ressources:

Dans Cloud Shell, supprimez le pool privé Cloud Build:

gcloud builds worker-pools delete PRIVATE_POOL_NAME --region REGION --quiet

Supprimez la connexion de service privée à Service Networking:

gcloud services vpc-peerings delete --network NETWORK \
  --service servicenetworking.googleapis.com --quiet --async

Supprimez la plage d'adresses IP allouée aux pools privés Cloud Build:

gcloud compute addresses delete RESERVED_RANGE_NAME --global --quiet

Supprimez le bucket Cloud Storage et tout son contenu:

gcloud storage rm gs://PROJECT_ID-build-logs --recursive

Supprimez le cluster GKE :

gcloud container clusters delete CLUSTER --zone ZONE --quiet --async

Supprimez l'instance de VM Compute Engine :

gcloud compute instances delete VM --zone ZONE --quiet

Supprimez les règles de pare-feu :

gcloud compute firewall-rules delete allow-private-pools-ingress --quiet

gcloud compute firewall-rules delete allow-ssh-ingress-from-iap --quiet

gcloud compute firewall-rules delete allow-control-plane-clientconfig-webhook --quiet

Supprimez les liaisons de rôles IAM:

gcloud projects remove-iam-policy-binding PROJECT_ID \
    --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/cloudbuild.builds.builder

gcloud projects remove-iam-policy-binding PROJECT_ID \
    --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/container.admin

gcloud iam service-accounts remove-iam-policy-binding \
    CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member serviceAccount:CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.serviceAccountOpenIdTokenCreator

gcloud iam service-accounts remove-iam-policy-binding \
    ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member serviceAccount:ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.serviceAccountOpenIdTokenCreator

Supprimez les comptes de service Google :

gcloud iam service-accounts delete CB_GSA@PROJECT_ID.iam.gserviceaccount.com \
   --quiet

gcloud iam service-accounts delete ISG_GSA@PROJECT_ID.iam.gserviceaccount.com \
   --quiet

Supprimer l'ID client OAuth 2.0

Accédez à la page Identifiants de la console Google Cloud:

Ouvrez la page Identifiants.
Sélectionnez votre projet dans la liste de sélection de projets.
Dans le tableau des ID clients OAuth 2.0, recherchez la ligne Identity Service for GKE (Service Identity pour GKE), puis cliquez sur l'icône Supprimer le client OAuth.
Dans la boîte de dialogue, cliquez sur Supprimer.

Étape suivante

Découvrez comment accéder aux clusters Anthos à partir de Cloud Build avec la passerelle de connexion.
Découvrez comment accéder à des clusters GKE privés avec des pools privés Cloud Build à l'aide de Cloud VPN.
Apprenez à créer des clusters privés GKE avec des proxys réseau pour l'accès au plan de contrôle.
Apprenez à accéder aux ressources externes d'un réseau privé à l'aide d'une adresse IP externe statique.
Découvrez GKE Identity Service. GKE Identity Service vous permet de gérer l'authentification des fournisseurs d'identité externes sur un parc de clusters Anthos.

Accédez à des clusters privés Google Kubernetes Engine à partir de pools privés Cloud Build à l'aide d'Identity Service pour GKE

Présentation de l'architecture

Avant de commencer

Créer un cluster GKE privé

Enregistrer Identity Service pour GKE en tant qu'application cliente OAuth 2.0

Créer un compte de service Google afin de configurer Identity Service pour GKE

Configurer Identity Service pour GKE

Vérifier la configuration du cluster (facultatif)

Créer un contexte pour l'outil kubectl

Créer un compte de service Google pour Cloud Build

Créer un pool privé Cloud Build

Valider la solution

Dépannage

Nettoyer

Supprimer le projet

Supprimer les ressources

Supprimer l'ID client OAuth 2.0

Étape suivante

Créer un contexte pour l'outil `kubectl`