Faciliter l’utilisation de Workload Identity pour GKE grâce à des outils à code source libre

15 septembre, 2023

Glen Yu, directeur principal, Ingénierie infonuagique – Innovateur expert Google

Google Cloud propose une façon ingénieuse de permettre aux charges de travail de Google Kubernetes Engine (GKE) de se connecter en toute sécurité aux interfaces de programmation de Google, tout en limitant l’exposition aux authentifiants. Je montrerai cette méthode au moyen d’un outil appelé kaniko.

Qu’est-ce que kaniko?

L’outil à code source libre kaniko permet de créer et d’envoyer des images de conteneurs à partir de pods Kubernetes lorsque vous n’avez pas facilement accès à un démon Docker et que vous ne disposez pas des droits « superutilisateur » de l’appareil sous-jacent. L’outil kaniko exécute les commandes de création dans l’espace utilisateur et ne dépend pas du démon Docker. C’est pourquoi il s’agit d’un outil populaire dans les trousses de pipeline d’intégration continue.

Le dilemme

Disons que vous souhaitez accéder à un service Google Cloud à partir de votre charge de travail GKE, comme un secret dans Secret Manager ou, comme dans notre exemple, que vous souhaitez créer et envoyer une image de conteneur à l’outil Artifact Registry de Google. Cependant, cette opération nécessite l’autorisation d’un compte de service Google régi par Cloud Identity and Access Management (IAM). Ce compte diffère d’un compte de service Kubernetes, qui identifie les pods et est régi par ses propres règles de contrôle des accès basé sur les rôles Kubernetes. Comment pouvez-vous donner accès à vos charges de travail GKE aux services Google Cloud en toute sécurité?

1. Utiliser un compte de service Compute Engine

La première option consiste à utiliser le compte de service IAM utilisé par les pools de nœuds. Par défaut, il s’agirait du compte de service Compute Engine. Cette méthode comporte un inconvénient : les permissions du compte de service sont partagées par toutes les charges de travail, ce qui contrevient au principe de moindre privilège. Pour cette raison, il est recommandé d’utiliser un compte de service personnalisé qui dispose du moindre privilège et d’accorder des droits d’accès plus précis aux charges de travail.

2. Utiliser des clés de compte de service en tant que secrets Kubernetes

La deuxième option, plus sécuritaire, est une méthode éprouvée qui consiste à générer des clés de compte de service Google avec les autorisations dont vous avez besoin et à les monter dans votre pod en tant que secrets Kubernetes. Le fichier manifeste de création et d’envoi d’une image à l’outil Artifact Registry de Google ressemblerait à ce qui suit :

apiVersion: v1
kind: Pod
metadata:
  name: kaniko-k8s-secret
spec:
  containers:
    - name: kaniko
      image: gcr.io/kaniko-project/executor:v1.9.1
      args: ["--dockerfile=Dockerfile",
             "--context=gs://${GCS_BUCKET}/path/to/context.tar.gz",
             "--destination=${LOCATION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/${IMAGE}:${TAG}",
             "--cache=true"]
      volumeMounts:
        - name: kaniko-secret
          mountPath: /secret
      env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /secret/kaniko-secret.json
  restartPolicy: Never
  volumes:
    - name: kaniko-secret
      secret:
        secretName: kaniko-secret

La variable d’environnement GOOGLE_APPLICATION_CREDENTIALS contient un chemin d’accès vers un fichier JSON contenant les authentifiants Google Cloud, monté au niveau du chemin d’accès ou du secret dans le pod. C’est grâce à cette clé de compte de service que le pod Kubernetes peut accéder aux fichiers de contexte de la version et transmettre l’image à l’outil Artifact Registry.

Par contre, cette méthode laisse circuler des clés actives, qui n’expirent pas et qui risquent constamment de faire l’objet d’une fuite, d’un vol ou d’une publication accidentelle dans un registre public.

3. Utiliser l’outil Workload Identity

La troisième option consiste à utiliser l’outil Workload Identity pour faire un lien entre les comptes de service Google et Kubernetes. Ainsi, le compte de service Kubernetes peut agir en tant que compte de service Google au moment d’interagir avec les services et les ressources de Google Cloud. Cette méthode permet un accès ciblé à partir du service IAM sans qu’il soit nécessaire de créer de clé de compte de service. Les lacunes sont donc comblées.

Configuration

Vous devrez activer Workload Identity dans votre cluster GKE et configurer le serveur de métadonnées pour vos pools de nœuds. Vous aurez également besoin d’un compte de service Google (j’ai nommé le mien kaniko-wi-gsa) et devrez lui attribuer les rôles nécessaires :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
 --role roles/artifactregistry.writer \
 --member "serviceAccount:kaniko-wi-gsa@${PROJECT_ID}.iam.gserviceaccount.com"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
 --role roles/storage.objectViewer \
 --member "serviceAccount:kaniko-wi-gsa@${PROJECT_ID}.iam.gserviceaccount.com"

Du côté de Kubernetes, créez un compte de service Kubernetes (j’ai nommé le mien kaniko-wi-ksa) et attribuez-lui le lien suivant, qui lui permet d’imiter le compte de service Google qui peut accéder aux services Google Cloud dont vous avez besoin :

gcloud iam service-accounts add-iam-policy-binding kaniko-wi-gsa@${PROJECT_ID}.iam.gserviceaccount.com \
 --role roles/iam.workloadIdentityUser \
 --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/kaniko-wi-ksa]"

Enfin, vous devrez ajouter à votre compte de service Kubernetes l’adresse courriel complète de votre compte de service Google :

kubectl annotate serviceaccount kaniko-wi-ksa \
 iam.gke.io/gcp-service-account=kaniko-wi-gsa@${PROJECT_ID}.iam.gserviceaccount.com

Voici le fichier manifeste du pod pour la même tâche de création d’images, mais avec l’outil Workload Identity :

apiVersion: v1
kind: Pod
metadata:
  name: kaniko-wi
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:v1.9.1
    args: ["--dockerfile=Dockerfile",
           "--context=gs://${GCS_BUCKET}/path/to/context.tar.gz",
           "--destination=${LOCATION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/${IMAGE}:${TAG}",
           "--cache=true"]
  restartPolicy: Never
  serviceAccountName: kaniko-wi-ksa
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"

Bien que l’outil Workload Identity nécessite une configuration initiale un peu plus poussée, vous n’aurez plus besoin de créer ou de transférer de clés de sécurité.

Et si vous voulez accéder aux services à partir d’un autre projet Google Cloud?

Parfois, vous devez envoyer vos images à un répertoire centralisé d’artefacts dans un projet Google Cloud autre que celui dans lequel se trouve votre cluster GKE. Dans cette situation, pouvez-vous utiliser l’outil Workload Identity?

Tout à fait! Votre compte de service Google et les liens IAM nécessaires sont créés dans votre projet Google Cloud externe, mais vous faites toujours référence au pool Workload Identity et au compte de service Kubernetes à partir desquels votre charge de travail GKE est exécutée.

Prochaines étapes

En utilisant kaniko, nous avons fait une démonstration de Workload Identity et de la façon dont cet outil permet un accès plus sécurisé aux interfaces de programmation de Google. Utilisez les pratiques de sécurité recommandées pour renforcer votre cluster GKE et cessez d’utiliser des comptes de service de nœuds ou d’exporter des clés de compte de service en tant que secrets Kubernetes.

Pour en savoir plus sur l’outil Workload Identity pour GKE et la façon dont nous pouvons vous aider, communiquez avec nous.