doc-locale/fr-fr/ci/secrets/gcp_secret_manager.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Vous pouvez utiliser les secrets stockés dans Google Cloud (GCP) Secret Manager dans vos pipelines CI/CD GitLab.
Le flux d'utilisation de GitLab avec GCP Secret Manager est le suivant :
Pour utiliser GitLab avec GCP Secret Manager, vous devez :
GCP IAM WIF doit être configuré pour reconnaître les jetons d'identification émis par GitLab et leur attribuer un principal approprié. Le principal est utilisé pour autoriser l'accès aux ressources Secret Manager :
Dans GCP Console, accédez à IAM & Admin > Workload Identity Federation.
Sélectionnez CREATE POOL et créez un nouveau pool d'identités avec un nom unique, par exemple gitlab-pool.
Sélectionnez ADD PROVIDER pour ajouter un nouveau fournisseur OIDC au pool d'identités avec un nom unique, par exemple gitlab-provider.
https://gitlab.com.aud pour le jeton d'identification CI/CD GitLab.Sous Attribute Mapping, créez les mappages suivants, où :
attribute.X est le nom de l'attribut à inclure en tant que revendication dans le jeton Google.assertion.X est la valeur à extraire de la revendication GitLab.| Attribut (sur Google) | Assertion (depuis GitLab) |
|---|---|
google.subject | assertion.sub |
attribute.gitlab_project_id | assertion.project_id |
Après avoir configuré WIF, vous devez accorder au principal WIF l'accès aux secrets dans Secret Manager.
Dans GCP Console, accédez à Sécurité > Secret Manager.
Sélectionnez le nom du secret auquel vous souhaitez accorder l'accès pour afficher les détails du secret.
Depuis l'onglet PERMISSIONS, sélectionnez GRANT ACCESS pour accorder l'accès au jeu de principaux créé via le fournisseur WIF. Le format d'identité externe est :
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.gitlab_project_id/GITLAB_PROJECT_ID
Dans cet exemple :
PROJECT_NUMBER : Le numéro de projet Google Cloud (et non l'ID) qui se trouve dans le tableau de bord du projet.POOL_ID : L'ID (et non le nom) du pool d'identités de charge de travail créé dans la première section, par exemple gitlab-pool.GITLAB_PROJECT_ID : L'ID de projet GitLab disponible sur la page de présentation du projet.Attribuez le rôle Secret Manager Secret Accessor.
Vous devez ajouter ces variables CI/CD pour fournir des informations sur votre GCP Secret Manager :
GCP_PROJECT_NUMBER : Le numéro de projet GCP.GCP_WORKLOAD_IDENTITY_FEDERATION_POOL_ID : L'ID du pool WIF, par exemple gitlab-pool.GCP_WORKLOAD_IDENTITY_FEDERATION_PROVIDER_ID : L'ID du fournisseur WIF, par exemple gitlab-provider.Vous pouvez ensuite utiliser les secrets stockés dans GCP Secret Manager dans des jobs CI/CD en les définissant avec le mot-clé gcp_secret_manager :
job_using_gcp_sm:
id_tokens:
GCP_ID_TOKEN:
# `aud` must match the audience defined in the WIF Identity Pool.
aud: https://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_FEDERATION_POOL_ID}/providers/${GCP_WORKLOAD_IDENTITY_FEDERATION_PROVIDER_ID}
secrets:
DATABASE_PASSWORD:
gcp_secret_manager:
name: my-project-secret # This is the name of the secret defined in GCP Secret Manager
version: 1 # optional: default to `latest`.
token: $GCP_ID_TOKEN
{{< history >}}
{{< /history >}}
Les noms de secrets dans GCP sont propres à chaque projet. Par défaut, le secret nommé dans gcp_secret_manager:name est lu depuis le projet spécifié dans GCP_PROJECT_NUMBER.
Pour lire un secret depuis un projet différent de celui contenant le pool WIF, utilisez le nom de secret complet formaté comme suit : projects/<project-number>/secrets/<secret-name>.
Par exemple, si my-project-secret se trouve dans le projet GCP numéro 123456789, vous pouvez accéder au secret avec :
job_using_gcp_sm:
# ... as previously configured ...
secrets:
DATABASE_PASSWORD:
gcp_secret_manager:
name: projects/123456789/secrets/my-project-secret # fully-qualified name of the secret defined in GCP Secret Manager
version: 1 # optional: defaults to `latest`.
token: $GCP_ID_TOKEN
google.subject dépasse la limite de 127 octets {#error-the-size-of-mapped-attribute-googlesubject-exceeds-the-127-bytes-limit}Les chemins de branche longs peuvent entraîner l'échec d'un job avec cette erreur, car l'attribut assertion.sub dépasse 127 caractères :
ERROR: Job failed (system failure): resolving secrets: failed to exchange sts token: googleapi: got HTTP response code 400 with body:
{"error":"invalid_request","error_description":"The size of mapped attribute google.subject exceeds the 127 bytes limit.
Either modify your attribute mapping or the incoming assertion to produce a mapped attribute that is less than 127 bytes."}
Les chemins de branche longs peuvent être causés par :
Par exemple, pour une branche gitlab-org/gitlab, le payload est project_path:gitlab-org/gitlab:ref_type:branch:ref:{branch_name}. Pour que la chaîne reste inférieure à 127 caractères, le nom de la branche doit comporter 76 caractères ou moins. Cette limite est imposée par Google Cloud IAM, suivie dans le ticket Google n° 264362370.
La seule solution à ce problème est d'utiliser des noms plus courts pour votre branche et votre dépôt.
The secrets provider can not be found. Check your CI/CD variables and try again. {#the-secrets-provider-can-not-be-found-check-your-cicd-variables-and-try-again-message}Vous pourriez recevoir cette erreur lorsque vous tentez de démarrer un job configuré pour accéder à GCP Secret Manager :
The secrets provider can not be found. Check your CI/CD variables and try again.
Le job ne peut pas être créé car une ou plusieurs des variables requises ne sont pas définies :
GCP_PROJECT_NUMBERGCP_WORKLOAD_IDENTITY_FEDERATION_POOL_IDGCP_WORKLOAD_IDENTITY_FEDERATION_PROVIDER_IDWARNING: Not resolved: no resolver that can handle the secret {#warning-not-resolved-no-resolver-that-can-handle-the-secret-warning}L'intégration Google Cloud Secret Manager nécessite au minimum GitLab 16.8 et GitLab Runner 16.8. Cet avertissement s'affiche si le job est exécuté par un runner utilisant une version antérieure à 16.8.