doc-locale/fr-fr/ci/secrets/secrets_manager/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
secrets_manager et ci_tanukey_ui. Désactivé par défaut.ci_tanukey_ui a été supprimé dans GitLab 18.4.group_secrets_manager.{{< /history >}}
Les secrets représentent des informations sensibles dont vos jobs CI/CD ont besoin pour fonctionner. Les secrets peuvent être des jetons d'accès, des identifiants de base de données, des clés privées ou autres éléments similaires.
Contrairement aux variables CI/CD, qui sont toujours disponibles par défaut pour les jobs, les secrets doivent être explicitement demandés par un job.
Utilisez le Gestionnaire de secrets GitLab pour stocker et gérer de manière sécurisée les secrets et les identifiants de vos projets et groupes.
La bêta publique du Gestionnaire de secrets GitLab est disponible pour les clients GitLab Premium and Ultimate. Vous pouvez participer à la bêta publique sur GitLab.com ou sur une instance self-managed.
Sur GitLab.com, un propriétaire de groupe principal peut activer le Gestionnaire de secrets GitLab pour son groupe. La participation au niveau du groupe principal le rend disponible pour tous les sous-groupes et projets au sein de ce groupe.
Prérequis :
Pour participer :
Après avoir participé, les propriétaires de groupes et de projets peuvent activer indépendamment le Gestionnaire de secrets pour leurs sous-groupes et projets. Pour les instructions, consultez Activer pour un groupe ou un projet.
Sur une instance self-managed, un administrateur doit d'abord activer le Gestionnaire de secrets GitLab au niveau de l'instance. Après avoir participé, les propriétaires peuvent l'activer pour leurs groupes et projets.
Prérequis :
Pour participer :
Après avoir participé, les propriétaires de groupes et de projets peuvent activer le Gestionnaire de secrets pour leurs espaces de nommage. Pour les instructions, consultez Activer pour un groupe ou un projet.
Prérequis :
Pour activer ou désactiver le Gestionnaire de secrets GitLab pour un projet :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
Dans la barre latérale gauche, sélectionnez Paramètres > Général.
Développez Visibilité, fonctionnalités du projet, autorisations.
Activez le bouton Gestionnaire de secrets et attendez que le gestionnaire de secrets soit provisionné.
[!warning] Si vous désactivez ultérieurement le Gestionnaire de secrets pour le projet, tous les secrets du projet sont définitivement supprimés. Ces secrets ne peuvent pas être récupérés.
Les secrets définis pour un projet ne sont accessibles que par les pipelines du même projet.
Prérequis :
Pour activer ou désactiver le Gestionnaire de secrets GitLab pour un groupe :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre groupe.
Dans la barre latérale gauche, sélectionnez Paramètres > Général.
Développez Permissions et fonctionnalités du groupe.
Activez le bouton Gestionnaire de secrets et attendez que le gestionnaire de secrets soit provisionné.
[!warning] Si vous désactivez ultérieurement le Gestionnaire de secrets pour le groupe, tous les secrets du groupe sont définitivement supprimés. Ces secrets ne peuvent pas être récupérés.
Les secrets définis pour un groupe ne sont accessibles que par les pipelines d'un projet directement sous le groupe ou dans sa hiérarchie de sous-groupes.
Vous pouvez ajouter des secrets au gestionnaire de secrets afin qu'il puisse être utilisé pour des pipelines CI/CD et des workflows sécurisés.
*)*).Après avoir créé un secret, vous pouvez l'utiliser dans la configuration du pipeline ou dans les scripts de job.
[!warning] La valeur d'un secret est accessible à tous les jobs de pipeline CI/CD s'exécutant pour l'environnement ou la branche spécifique défini lors de la création ou de la mise à jour du secret. Assurez-vous que seuls les utilisateurs autorisés à accéder à la valeur de ces secrets peuvent exécuter des jobs pour l'environnement ou la branche spécifiés.
Prérequis :
Pour accéder aux secrets définis avec le Gestionnaire de secrets, utilisez les mots-clés secrets et gitlab_secrets_manager.
Similairement aux variables de type fichier, le secret est mis à disposition en tant que variable d'environnement avec :
Par exemple :
job:
secrets:
KUBE_CA_PEM:
gitlab_secrets_manager:
name: kube-cert
script:
- kubectl config set-cluster e2e --server="https://example.com" --certificate-authority="$KUBE_CA_PEM"
Si un job affiche la valeur d'un secret, par exemple en exécutant cat $KUBE_CA_PEM, GitLab remplace la valeur dans le job log par [MASKED].
Prérequis :
Pour accéder aux secrets de groupe :
secrets et gitlab_secrets_manager.source au format group/<full-path-to-group>.Par exemple :
job:
secrets:
TEST_SECRET:
gitlab_secrets_manager:
name: foo
source: group/<full-path-to-group>
script:
- cat $TEST_SECRET
Prérequis :
Pour mettre à jour les autorisations des secrets pour un projet :
Prérequis :
Pour mettre à jour les autorisations des secrets pour un groupe :
Les utilisateurs avec le rôle Owner pour le groupe ont toujours les autorisations pour effectuer toutes les opérations dans le Gestionnaire de secrets.
Lorsque vous supprimez un projet ou supprimez un groupe avec des secrets :
Lorsque vous transférez un projet ou transférez un groupe avec des secrets :
Les utilisateurs avec le rôle Owner dans le projet reçoivent une notification par e-mail pour effectuer la rotation d'un secret le jour spécifié dans la configuration du secret.
Le Gestionnaire de secrets GitLab est gratuit pendant la bêta ouverte, mais consommera des GitLab Credits lors de sa disponibilité générale. Pour éviter une interruption de service, nous vous notifierons avant la disponibilité générale afin de vous donner le temps d'opter pour la facturation à la demande des GitLab Credits.
Pour partager des commentaires ou signaler des problèmes pendant la bêta publique, utilisez le Gestionnaire de secrets GitLab : ticket Customer Feedback in Public Beta.
reading from Vault: api error: status code 403 {#error-reading-from-vault-api-error-status-code-403}Lorsqu'un job de pipeline CI/CD tente de récupérer un secret, il peut renvoyer cette erreur :
ERROR: Job failed (system failure): resolving secrets: getting secret: get secret data: reading from Vault: api error: status code 403: 1 error occurred: * permission denied
Cette erreur se produit lorsqu'un job tente de récupérer un secret qui n'existe pas ou qui a été supprimé.
inline auth JWT is required {#error-inline-auth-jwt-is-required}Lorsqu'un job de pipeline CI/CD tente de récupérer un secret, il peut renvoyer cette erreur :
ERROR: Job failed (system failure): resolving secrets: creating vault client: configuring inline auth: inline auth JWT is required
Cette erreur se produit lorsque l'instance du gestionnaire de secrets n'a pas encore été provisionnée pour le projet ou le groupe auquel le secret est censé appartenir. Le runner ne peut pas configurer l'authentification car aucun rôle de gestionnaire de secrets n'existe encore.
Pour résoudre cette erreur, activez le Gestionnaire de secrets pour votre projet ou groupe.
Attendez que le provisionnement soit terminé et créez le secret avant de relancer le pipeline.