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

Accéder aux clusters Google Kubernetes Engine privés à 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 s'adresse 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 de cluster GKE s'exécutent tous deux dans des réseaux cloud privé virtuels (VPC) appartenant à Google. Ces réseaux VPC sont appairés à votre propre réseau VPC sur Google Cloud. Toutefois, l'appairage de réseaux VPC n'est pas compatible avec l'appairage transitif, ce qui peut être une restriction lorsque vous utilisez des pools privés Cloud Build. Ce tutoriel présente une solution qui utilise Identity Service for 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 met en proxy les requêtes envoyées au serveur d'API et valide les jetons d'identification émis par les fournisseurs d'identité OpenID Connect (OIDC). Une fois que le proxy a validé un jeton d'identification, 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. Vous pouvez accéder au proxy 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 les nœuds de cluster de votre réseau VPC.

Vous pouvez configurer Google en tant que 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. Pour 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 exécutée 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'ID 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 aux clusters GKE privés à l'aide d'Identity Service pour GKE

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

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

Avant de commencer

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

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.

Make sure that billing is enabled for your Google Cloud project.

Enable the Cloud Build, GKE, Identity-Aware Proxy (IAP), and Service Networking APIs APIs:

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

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

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.

Make sure that billing is enabled for your Google Cloud project.

Enable the Cloud Build, GKE, Identity-Aware Proxy (IAP), and Service Networking APIs 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 accès client au point de terminaison public du plan de contrôle et sur lequel Identity Service for 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'indicateur --enable-private-endpoint configure le plan de contrôle pour qu'il ne soit accessible qu'à l'aide d'adresses IP internes.
- L'indicateur --enable-private-nodes configure les nœuds du cluster pour qu'ils n'aient que des adresses IP internes.
- Les indicateurs --enable-master-authorized-networks et --enable-private-nodes n'autorisent l'accès au serveur d'API que depuis les réseaux privés spécifiés par l'indicateur --network.
- L'indicateur --workload-pool facultatif active la fédération d'identité de charge de travail pour GKE. Ce n'est pas nécessaire pour ce tutoriel.
Ajoutez une règle de pare-feu qui autorise le plan de contrôle du cluster GKE à se 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ée (CRD) Kubernetes utilisé par Identity Service for GKE pour configurer l'interaction 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 des champs Nom de l'application, Adresse e-mail d'assistance utilisateur et Coordonnées du développeur sont obligatoires et peuvent être de n'importe quelle valeur.
- Vous n'avez pas besoin d'ajouter de champs d'application pour ce tutoriel.
Lorsque vous avez terminé de configurer l'écran de consentement, cliquez sur "Retour au tableau de bord", puis recommencez à 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 un répertoire sous votre répertoire d'accueil appelé cloud-build-private-pools-gke-tutorial, puis accédez-y :

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 contenant les valeurs dont vous avez besoin ultérieurement pour corriger la ressource ClientConfig du service d'identité pour GKE :
```
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 qu'il utilise la revendication d'adresse e-mail des jetons d'identité pour identifier les utilisateurs au lieu d'utiliser la revendication secondaire 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 pour les 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 Utiliser des fournisseurs d'identité externes pour s'authentifier auprès de GKE.

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 attribuez ce compte de service Google à une instance de VM Compute Engine afin de configurer le service d'identité pour GKE et le contrôle des accès basé sur les rôles Kubernetes sur le cluster.
Accordez le rôle Administrateur de Kubernetes Engine au 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 requises pour effectuer les tâches suivantes dans 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 l'accès SSH authentifié et autorisé en dehors 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 qui autorise l'accès SSH à l'aide du transfert TCP de l'IAP à toutes les instances de VM dotées du 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 qu'IAP utilise pour le transfert TCP.
Créez une instance de VM Compute Engine dans le même réseau VPC que le 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'indicateur --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 champ d'application userinfo-email est utile lorsque vous créez 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 de correctif ClientConfig dans 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, attribuez le rôle Créateur de jetons d'identité OpenID Connect du compte de service au compte de service Google lui-même :
```
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'identification à 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 du corps JSON de la requête spécifie la revendication aud (audience) demandée du jeton d'identifiant.
Le jeton d'accès de l'étape précédente est utilisé pour 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 du service d'identité 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'indicateur --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 possède un nom et inclut éventuellement des informations de connectivité du cluster, les identifiants utilisés pour s'authentifier auprès du cluster et un espace de noms par défaut.

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

Dans Cloud Shell, copiez les fichiers contenant les données de l'autorité de certification et l'URL du serveur de l'instance de VM vers le répertoire actuel :
```
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 depuis Cloud Build :
```
kubectl config set-context private-cluster \
    --cluster private-cluster \
    --kubeconfig kubeconfig
```
L'indicateur --kubeconfig crée le contexte et la configuration du cluster dans un nouveau fichier appelé 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 autre nom de configuration de cluster dans le contexte.

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

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

Définissez le champ server sur 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.
Attribuez le rôle de compte de service Cloud Build au 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 le Créateur de jetons d'identité OpenID Connect (OpenID Connect) associé au 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écutez les autres commandes de cette section depuis 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 le compte de service 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 au 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. Un nombre inférieur correspond à une plage d'adresses plus é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 de la plage d'adresses IP réservée vers d'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 options de configuration supplémentaires, telles que le type de machine et la taille du disque pour les 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 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 délivré au compte de service Google qui exécute le build.
3. Génère un jeton d'identification à 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 du compilateur, vous pouvez créer une image de compilateur personnalisée qui ne contient que les outils requis pour 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 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 à l'aide de SSH, ajoutez l'indicateur --troubleshoot pour identifier 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 corrigez le 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 pouvez 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 ci-dessous :

Effectuer un nettoyage

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 entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez é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.

Delete a Google Cloud project:

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ôle 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 des sélecteurs de projet.
Dans le tableau des ID client OAuth 2.0, recherchez la ligne Identity Service for 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 depuis Cloud Build avec la passerelle Connect.
Découvrez comment accéder aux clusters GKE privés avec les pools privés Cloud Build à l'aide de Cloud VPN.
Découvrez comment créer des clusters privés GKE avec des proxys réseau pour l'accès au plan de contrôle.
Découvrez comment 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éder aux clusters Google Kubernetes Engine privés à 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

Effectuer un nettoyage

Supprimer le projet

Supprimer les ressources

Supprimer l'ID client OAuth 2.0

Étape suivante

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