Gouvernance de la sécurité : comment bien la gérer sur Google Cloud Plateform

Les questions liées à la sécurité et à l’authentification sont essentielles pour toutes les plateformes. Google Cloud Platform n’y échappe pas. Comment bien gérer la gouvernance de la sécurité et accéder aux ressources Google à partir d’environnements externes tels que Gitlab via CI/CD, et sans avoir à gérer des informations d’identification à long terme ? Nos réponses dans cet article…

La génération de clés JSON n’est pas suffisante

La manière habituelle d’authentification aux API cloud de Google consiste à générer des clés JSON qui sont similaires aux mots de passe pour un compte de service puis les stocker dans un endroit « sûr ».

Mes expériences m’ont appris qu’aucun endroit n’est suffisamment sûr… Surtout, quand un matin tu reçois un mail « Réunion Urgent : Mot de passe d’un compte de service a été piraté ». De surcroît, la sécurisation, le stockage, la distribution, la rotation et la surveillance de ces clés peuvent être une tâche fastidieuse, c’est pourquoi cette méthode n’est pas recommandée.

Google recommande une meilleure façon d’authentifier via « Workload Identity Federation« . Je vais donc vous expliquer la méthode la plus sûre à utiliser à mon avis pour améliorer la sécurité et simplifier la gestion des accès aux ressources Google Cloud. Enfin, nous vous guiderons à travers l’intégration OpenID Connect (OIDC) de GitLab CI. Pour cela, je vous montrerai les scénarios de sécurisation des interactions entre les pipelines Gitlab CI/CD et la ressource « Workload Identity federation » de Google. Afin d’éviter de stocker des clés de compte de service Google Cloud dans les variables CI de Gitlab.

Miser sur l’authentification via Workload Identity Federation

Pour commencer, nous allons implémenter un pipeline CI/CD Gitlab avec Google Cloud via Wordkload Identity Federation pour accéder aux ressources Google Cloud.

Ce qui va suivre est donc pour tous ceux qui souhaitent gérer des versions de ses applications sous Git et/ou mettre en place (IAC) par Terraform pour un déploiement d’une infrastructure tel que Google Cloud.

En résumé, ce que vous allez trouver :

• Explication concernant le concept de Workload Identity Federation ainsi que les interactions entre les composants GCP et les applications externes.
• Configuration de workload identity federation pour accéder aux ressources GCP.
• Création d’un pipeline CI sous Gitlab pour lister tous les Buckets de Cloud Storage.

1. Workload Identity concepts

Wordload identity est un mécanisme qui est proposé par Google et qui vise à améliorer la sécurité. Pour y parvenir, il offre la possibilité de s’authentifier auprès d’autre services tels que Gitlab/GitHub/Cloud. Cela permet d’accéder aux services Google en utilisant les services Identity et Access Management.

• Ce mécanisme permet d’éliminer le besoin d’information d’indentification à longue durée (comme c’est le cas de clés traditionnelles qui sont stockées dans des variables).
• Amélioration de la sécurité globale en s’appuyant sur l’emprunt de l’utilisation de comptes de service.
• Fine-grained scoping : Entre Google et des applications externes qui peuvent définir des mappages d’attributs précis entre le jeton et les autorisations disponibles.
• Short-lived credentials : Utilisation de jeton a durée de vie limitée (les informations d’identification expirent automatiquement une heure après leur création).
• Minimal Management Overhead : Il n’y a pas de secret à stocker ou gérer.

Workload Identity Pools et Providers

• Workload Identity Pool : Comme un conteneur qui se lie aux projets Google Cloud spécifiques et regroupe tous les comptes de service Account et les identités externes comme un système d’identité.
• Workload Identity Provider(AWS provider, GiLab provider, GitHub Provider) : il s’agit d’un fournisseur d’identité qui contient plusieurs règles de sécurité, afin d’établir une connexion entre les identités des utilisateurs des services externes avec des compte de service Google Cloud. Cela facilite la gestion de qui a accès à quoi.

Autrement dit, Workload Identity Provider est un (IDP) pour Workload Identity Pool Google destinée à l’intégration des applications externes sur Google Cloud.

• Security Token service : Est un service qui génère un jeton de courte durée pour accéder aux ressources Google Cloud contre les informations d’indentification de google.
• Service Account : Un compte de service, identifié par son adresse e-mail unique, utilisé par une application ou une charge de travail « «workload » , telle qu’une instance Compute Engine (plutôt d’utiliser un compte particulier , c’est préférable d’utiliser un compte de service).
• Google Cloud Resources : Est un ensemble de composants, tels que des ordinateurs, des disques dure et des ressources virtuelles telles que des machine VM, les ressources Google Cloud incluent des projets, les trousseaux de clés, le stockage, des outils, etc.

• La charge de travail (Workloads) est estimée par votre fournisseur d’identité (Identity Provider).
• (Identity Provider) transmet les informations d’identification du compte.
• WorkLoad transmet les informations d’identification au service Goole (Security Token).
• Validation des informations si celles-ci sont dans le pool (Workload identity Pool).
• Réponse indiquant si les informations d’indentification sont valides.
• Transmission d’un jeton (courte dure) d’accès au Google qui peut emprunter l’identité d’un compte service Account.
• Emprunter l’identité d’un compte de service à l’aide d’un jeton temporaire.
• Accéder aux ressources Google Cloud.

Configuration Workload Identity Federation

Étape 1 : Creation Workload Identity Pool

Workload identity federation permet d’organiser et de gérer les identités externes.

Un projet GCP peut avoir plusieurs pools, chacun permettant d’intégrer avec plusieurs Identity Provider externe. Cela vous permet de créer ainsi une collection d’identités et de contrôler pour chaque projet.

gcloud iam workload-identity-pools create \
–project= » » \
–location= »global » \
–display-name= »Workload identity pool for GitLab project ID »

• <your_google_cloud_project_id> : l’ID de votre projet Google Cloud. Pour améliorer la sécurité, utilisez un projet dédié à la gestion des identités, distinct des ressources et des projets CI/CD.
• <your_identity_pool_id> : l’ID à utiliser pour le pool

Étape 2 : Créations pool Providers

Providers : est une entité qui décrit la relation entre Google Cloud et votre Identity provider. Par exemple, Gitlab est l’IDP de Workload Identity Pool. Pour l’intégrer sur Google Cloud,  il faut configurer le Providers au niveau des mappage des attributs « attribute-mapping » du côté de Google pour avoir l’autorisation IAM nécessaire de déployer votre Workloads vers Google Cloud.

gcloud iam workload-identity-pools providers create-oidc \
–workload-identity-pool=\
–issuer-uri= \ # example « https://gitlab.com » \
–project= »
–location= »global » \
–display-name= »My OIDC Provider » \
–attribute-mapping= »google.subject=assertion.sub »

attribute-mapping :  Cela permet de mapper les  attributs des informations d’authentification qui sont transmises par Identity provider vers Google Cloud. Il s’agit ici de la règle de mappage d’attributs.

google.subjet est l’attribut standard utilisé par google cloud et assertion.sub

Compte de service

Création d’un compte de service, définition des rôles nécessaires et des autorisations pour accéder aux ressources souhaitées

Création d’un compte service :

gcloud iam service-accounts create »my-service-account »\
–project= »MY_PROJECT »

Nous allons donc accorder le rôle d’administrateur de stockage « storage.admin » qui sera nécessaire pour notre démonstration Gitlab CI/CD.

gcloud projects add-iam-policy-binding « MY_PROJECT »\
–member= »serviceAccount:my-service-account@MY_PROJECT.iam.gserviceaccount.com »\
–role= »roles/storage.admin »

Enfin, nous allons utiliser l’emprunt d’identité du compte de service pour autoriser la charge de travail (Workload) afin d’accéder aux ressources google car cela est plus sécurise qu’une clé de compte de service.

gcloud iam service-accounts add-iam-policy-binding « my-service-account@MY_PROJECT.iam.gserviceaccount.com »\
–project= »MY_PROJECT »\
–role= »roles/iam.workloadIdentityUser »\
— member= »principalSet://iam.googleapis.com/projects/MY_PROJECT_number/locations/global/workloadIdentityPools/MY_POOL/* »

Exemple : Création d’un pipeline CI dans Gitlab qui s’exécute en dehors de Google Cloud

Certains développeurs souhaitent exécuter et déployer leur code Terraform  afin de créer des ressources sur Google Cloud. D’autres, en revanche,  ont seulement besoin d’effectuer certaines configurations « gcloud« . Les deux font appel à des API GCP. Celles-ci ont besoin d’une authentification et d’une autorisation.

Ce pipeline permet d’intégrer des projets d’infrastructure et de déployer des ressources ou des projets data pour l’industrialisation

 Dans notre démonstration, nous avons choisi une solution d’utiliser gcloud afin d’afficher les informations d’un Bucket existant dans une plateforme Google Cloud via la commande gsutil ls en passant par CI/CD Gitlab

Dans les étapes précédentes, nous avons configuré dans notre Workload identity Federation :

• workload-identity-pools
• workload-identity-pools providers
• service-account avec les rôles nécessaires

Étape 1 : Créer un projet Gitlab vide ou utilisez un projet existant.

Étape 2 : Créer un fichier .gitlab.yml.

Des informations concernant votre environnement Google :

Ajoutez des id_tokens à votre Pipeline :

Obtenez des informations d’identification temporaires à l’aide d’un jeton d’identification :

Vous pouvez ensuite utiliser le jeton fédéré résultant pour emprunter l’identité du compte de service créé dans la section précédente :

Puis, vous pouvez accéder aux ressources de Google Cloud via la commande gcloud storage ls pour consulter les buckets dans Cloud Storage :

Le résultat après exécution de notre pipeline :

Google Worklad Identity  Federation est donc une solution recommandée et sécurisée. Elle permet de réduire la charge de travail d’exploitation et d’éviter les risques de sécurité liés aux Clés JSON qui sont l’une des principales sources d’attaques informatique dans le Cloud.

En intégrant Worklad Federation Identity, j’ai obtenu une meilleure gouvernance de sécurité. J’ai surtout pu déployer une stratégie de déploiement robuste, sécurisée et évolutive Cela concerne tout le processus de déploiement, et garantit aussi la cohérence et la fiabilité dans différents environnements.