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 les 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 bien GKE, Cloud Build, OpenID Connect et l'outil de ligne de commande gcloud.

Les pools privés Cloud Build et les plans de contrôle des clusters GKE s'exécutent tous deux dans 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. Toutefois, 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 de clusters GKE. Elle sert de proxy pour 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'ID, il ajoute des 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 sous la forme d'un compte de service Kubernetes autorisé à emprunter l'identité d'utilisateurs et de groupes.

Le service Identity Service pour GKE s'exécute en tant que pods sur les nœuds de 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 les 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. Pour obtenir des jetons d'ID pour un compte de service Google, vous pouvez utiliser la méthode generateIdToken de l'API Service Account Credentials. Les jetons d'identification sont émis et signés par Google.

En résumé, cette solution permet d'accéder au plan de contrôle privé du cluster GKE à l'aide d'Identity Service pour le proxy 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 qui s'exécute sur le pool privé Cloud Build s'exécute via un 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 à des clusters GKE privés à l'aide d'Identity Service pour GKE

Toutes les communications de cette solution ont lieu via un espace d'adressage IP interne. Les nœuds de calcul du pool privé n'ont pas besoin d'une connexion 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 d'Identity Service pour GKE. Pour gérer les autorisations de cluster pour ces comptes, vous devez utiliser le contrôle des accès basé sur les rôles Kubernetes (RBAC).

Avant de commencer

  1. 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.
  2. Installez Google Cloud CLI.
  3. Pour initialiser gcloudCLI, exécutez la commande suivante :

    gcloud init
  4. Créez ou sélectionnez un projet Google Cloud.

    • Créez un projet Google Cloud :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

    • Sélectionnez le projet Google Cloud que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre projet Google Cloud.

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

  6. 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
  7. Installez Google Cloud CLI.
  8. Pour initialiser gcloudCLI, exécutez la commande suivante :

    gcloud init
  9. Créez ou sélectionnez un projet Google Cloud.

    • Créez un projet Google Cloud :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

    • Sélectionnez le projet Google Cloud que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre projet Google Cloud.

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

  11. 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é

  1. Dans Cloud Shell, créez un cluster GKE qui n'a pas d'accès 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 ne soit accessible qu'à l'aide d'adresses IP internes.

    • L'option --enable-private-nodes configure les nœuds du cluster pour qu'ils ne disposent que d'adresses IP internes.

    • Les options --enable-master-authorized-networks et --enable-private-nodes autorisent l'accès au serveur d'API uniquement à 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.

  2. Ajoutez une règle de pare-feu qui permet au plan de contrôle du cluster GKE de 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é (CRD) Kubernetes qu'Identity Service pour GKE utilise 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.

  1. Ouvrez la page Identifiants dans la console Google Cloud.

    Ouvrez la page Identifiants.

  2. Cliquez sur Créer des identifiants.

  3. 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 de consentement. 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 App name (Nom de l'application), User support email (Adresse e-mail d'assistance utilisateur) et Developer contact (Coordonnées du développeur) sont obligatoires, et peuvent avoir n'importe quelle valeur.
    • Il n'est pas nécessaire d'ajouter des champs d'application pour ce tutoriel.

    Lorsque vous avez terminé de configurer l'écran de consentement, cliquez sur "Revenir au tableau de bord", puis recommencez à partir de l'étape 1 de la procédure actuelle.

  4. Dans la liste Type d'application, sélectionnez Application Web.

  5. Dans le champ Nom, saisissez un nom pour l'ID client. Pour ce tutoriel, utilisez Identity Service for GKE.

  6. Cliquez sur Créer.

    Une boîte de dialogue s'affiche. Copiez la valeur de Your Client ID (Votre ID client), car vous en aurez besoin ultérieurement dans cette procédure.

  7. Cliquez sur OK pour fermer la boîte de dialogue.

  8. Dans Cloud Shell, créez un répertoire nommé cloud-build-private-pools-gke-tutorial sous votre répertoire d'accueil, puis accédez-y:

    mkdir -p ~/cloud-build-private-pools-gke-tutorial cd ~/cloud-build-private-pools-gke-tutorial

  9. Dans le nouveau répertoire, créez un fichier YAML nommé client-config-patch.yaml contenant les valeurs dont vous aurez besoin ultérieurement pour appliquer un correctif à 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.

    Notez 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 revendication de sous-objet (objet). L'utilisation de cet identifiant opaque dans les liaisons de rôles complique 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'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é afin que les jetons d'identification émis incluent la revendication de l'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 l'absence 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 en tant que 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 pour configurer Identity Service pour GKE

  1. 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 devez 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.

  2. Accordez au compte de service Google le rôle Administrateur Kubernetes Engine sur le projet:

    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:

    • Configurez les paramètres Identity Service pour GKE sur les clusters du projet.
    • Créez des liaisons de rôles 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é depuis l'extérieur du réseau VPC vers 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 ait une adresse IP publique.

  1. Dans Cloud Shell, créez une règle de pare-feu qui autorise l'accès SSH à l'aide du transfert TCP d'IAP vers toutes les instances de VM portant 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.

  2. 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'option --service-account associe le compte de service Google à l'instance de VM.

    • Le champ d'application cloud-platform est requis pour accéder à l'API Service Account Credentials.

    • Le champ d'application 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 de 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.

  3. 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 tunneliser la connexion via IAP.

  4. Connectez-vous à l'instance de VM via SSH :

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

    Les autres commandes de cette section seront exécutées à partir de la session SSH.

  5. Installez l'outil de ligne de commande kubectl et le binaire gke-gcloud-auth-plugin binaire dans l'instance de VM:

    sudo apt-get install -y kubectl google-cloud-sdk-gke-gcloud-auth-plugin
    
  6. Récupérez les identifiants du cluster GKE:

    export USE_GKE_GCLOUD_AUTH_PLUGIN=True
    gcloud container clusters get-credentials CLUSTER --zone ZONE
    
  7. Appliquez un correctif à la ressource ClientConfig par défaut:

    kubectl patch clientconfig default \
        --namespace kube-public \
        --patch-file client-config-patch.yaml \
        --type merge
    
  8. 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
    
  9. 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
    
  10. Quittez la session SSH :

    exit
    

(Facultatif) Vérifier la configuration du cluster

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

  1. Dans Cloud Shell, attribuez au compte de service le créateur de jetons d'identité OpenID Connect du compte de service 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 requise pour demander des jetons d'ID pour le compte de service à partir de l'API Service Account Credentials.

  2. Connectez-vous à l'instance de VM via SSH :

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

    Les autres commandes de cette section seront exécutées à partir de la session SSH.

  3. 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.

  4. 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 du corps de la requête JSON spécifie la revendication aud (audience) demandée du jeton d'ID.
    • Le jeton d'accès de l'étape précédente permet de s'authentifier auprès de l'API.
  5. 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.

  6. 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 des autorisations IAM aient été accordées au compte de service Google sur les clusters GKE du projet, ces autorisations ne s'appliquent pas lorsque vous vous authentifiez à l'aide d'Identity Service pour GKE. À la place, vous allez configurer l'accès à l'aide du contrôle des accès basé sur les rôles Kubernetes (RBAC).

  7. 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 de votre propre environnement, ajoutez le préfixe à la valeur de l'option --user dans cette commande.

  8. 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
    
  9. 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 porte un nom et inclut éventuellement des informations sur la 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é d'Identity Service pour le proxy GKE pour votre cluster. Vous n'ajoutez pas d'identifiants utilisateur au fichier kubeconfig.

  1. 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 depuis l'instance de VM:

    gcloud compute scp VM:~/certificateAuthorityData.pem VM:~/server.txt . \
        --tunnel-through-iap --zone ZONE
    
  2. 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.

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

    kubectl config set-cluster private-cluster \
        --certificate-authority certificateAuthorityData.pem \
        --embed-certs \
        --kubeconfig kubeconfig
    
  4. 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

  1. 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.

  2. Attribuez le rôle 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.

  3. Attribuez le créateur de jetons d'identité OpenID Connect du compte de service 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 requise pour demander des jetons d'ID pour le compte de service à partir de l'API Service Account Credentials.

  4. Connectez-vous à l'instance de VM via SSH :

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

    Les autres commandes de cette section seront exécutées à partir de la session SSH.

  5. Dans la session SSH, créez une liaison de rôle de cluster Kubernetes qui accorde 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 de nombreuses autorisations à l'échelle du cluster. Dans votre propre environnement, vous pouvez utiliser un rôle de cluster qui ne fournit que les autorisations nécessaires pour les tâches effectuées par Cloud Build. Vous pouvez également utiliser des liaisons de rôle pour n'accorder des autorisations que pour 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.

  6. Quittez la session SSH :

    exit
    

Créer un pool privé Cloud Build

  1. 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 / (barre oblique) de début.
  2. Créez une règle de pare-feu pour autoriser le trafic entrant provenant 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
    
  3. 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 les nœuds de calcul à l'aide de Service Networking. La connexion de service privé 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 de service privée peut prendre quelques minutes.

    Si vous utilisez un VPC partagé dans votre propre environnement, consultez Configurer votre environnement pour en savoir plus sur les étapes supplémentaires permettant de créer la connexion de service privée.

  4. Créez un pool privé Cloud Build dans un réseau VPC appartenant à Google et 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 propre environnement, vous pouvez supprimer cet indicateur si vous souhaitez que les nœuds de calcul du pool privé disposent d'une connexion Internet à l'aide d'adresses IP publiques.

    Pour plus d'informations 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 la section 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é.

  1. Dans Cloud Shell, créez un bucket Cloud Storage pour stocker les journaux de compilation de Cloud Build:

    gsutil mb -l REGION gs://PROJECT_ID-build-logs
    
  2. 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'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é lors de la commande précédente.

    Notez les points suivants à propos du 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 des commandes.

    • Les substitutions _KUBECONFIG et _KUBECTL_CONTEXT permettent de spécifier des fichiers kubeconfig différents et des contextes différents lorsque vous exécutez une compilation. Ces substitutions vous permettent de gérer plusieurs configurations de cluster en utilisant soit un seul fichier kubeconfig avec plusieurs contextes, soit à l'aide de plusieurs fichiers kubeconfig.

    • La substitution _SERVICE_ACCOUNT n'a pas de valeur par défaut. Vous devez fournir 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 de compilateur gcr.io/google.com/cloudsdktool/google-cloud-cli. Il s'agit d'une grande image de conteneur. Son extraction du registre vers le nœud de calcul du pool privé prend un certain temps. Pour réduire le temps nécessaire pour extraire l'image du compilateur, vous pouvez créer une image de compilateur personnalisée ne contenant 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 la section Exécuter des scripts bash.

  3. Exécutez une compilation à l'aide du fichier de configuration de compilation et des fichiers présents dans le 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 qui se trouvent dans le répertoire actuel vers Cloud Storage afin 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, vous voyez des lignes qui se présentent comme suit:

    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 d'Identity Service pour le proxy d'authentification GKE.

Dépannage

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

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

Si vous recevez le message Error from server (NotFound): clientconfigs.authentication.gke.io "default" not found lorsque vous corrigez l'objet ClientConfig par défaut sur le cluster GKE, vérifiez que vous avez 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:

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

    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:

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

    gcloud builds worker-pools delete PRIVATE_POOL_NAME --region REGION --quiet
    
  2. Supprimez la connexion de service privée à Service Networking:

    gcloud services vpc-peerings delete --network NETWORK \
      --service servicenetworking.googleapis.com --quiet --async
    
  3. Supprimez la plage d'adresses IP allouée aux pools privés Cloud Build:

    gcloud compute addresses delete RESERVED_RANGE_NAME --global --quiet
    
  4. Supprimez le bucket Cloud Storage et tout son contenu:

    gsutil rm -r gs://PROJECT_ID-build-logs
    
  5. Supprimez le cluster GKE :

    gcloud container clusters delete CLUSTER --zone ZONE --quiet --async
    
  6. Supprimez l'instance de VM Compute Engine :

    gcloud compute instances delete VM --zone ZONE --quiet
    
  7. 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
    
  8. 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
    
  9. 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

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

    Ouvrez la page Identifiants.

  2. Sélectionnez votre projet dans la liste de sélection de projet.

  3. Dans le tableau des ID client OAuth 2.0, recherchez la ligne Service Identity pour GKE, puis cliquez sur l'icône Supprimer le client OAuth.

  4. Dans la boîte de dialogue, cliquez sur Supprimer.

Étapes suivantes