doc-locale/fr-fr/administration/secrets_manager/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Le GitLab Secrets Manager utilise OpenBao, une solution open source de gestion des secrets. OpenBao assure le stockage sécurisé, le contrôle d'accès et la gestion du cycle de vie des secrets utilisés dans votre instance GitLab.
Les jobs GitLab CI/CD utilisant des secrets provenant du GitLab Secrets Manager doivent utiliser GitLab Runner 19.0 ou une version ultérieure.
OpenBao s'intègre à GitLab en tant que composant optionnel fonctionnant en parallèle aux services GitLab existants.
global.openbao.psql dans le chart Helm.flowchart TB
SecretStore[Secret store]
PostgreSQL[PostgreSQL]
LB[Load balancer]
OpenBao[OpenBao active node]
Rails[Rails backend]
Runner[GitLab Runner]
Workhorse[Workhorse]
Rails-- Write secrets and permissions -->LB
Runner-- Get pipeline secrets -->LB
LB-->OpenBao
OpenBao-- Get unseal key -->SecretStore
OpenBao-- Store -->PostgreSQL
OpenBao-- Audit logs -->Workhorse
Workhorse-->Rails
OpenBao fonctionne avec un seul nœud actif qui traite toutes les requêtes, et optionnellement plusieurs nœuds en veille qui prennent le relais si le nœud actif tombe en panne.
Prérequis :
Choisissez la méthode d'installation en fonction de votre déploiement GitLab :
Après l'installation, vérifiez qu'OpenBao fonctionne en suivant la documentation utilisateur du GitLab Secrets Manager.
Les besoins en ressources d'OpenBao dépendent de la taille de votre instance GitLab et des modèles d'utilisation des secrets.
Ces recommandations sont des points de départ validés. Surveillez votre déploiement et ajustez les ressources en fonction des modèles d'utilisation réels. Vos besoins varieront en fonction du nombre de jobs CI/CD qui récupèrent des secrets, et du nombre de groupes et de projets avec le Secrets Manager activé.
OpenBao fonctionne avec un seul nœud actif qui traite toutes les requêtes. Les réplicas supplémentaires assurent uniquement le basculement pour la haute disponibilité. Les nœuds en veille ne servent pas le trafic en lecture car OpenBao ne prend pas en charge la scalabilité horizontale en lecture (HRS) lorsqu'il est connecté à une base de données PostgreSQL.
| Récupérations de secrets/s | Demande CPU | Demande de mémoire | Réplicas |
|---|---|---|---|
| Jusqu'à 3 | 500m | 2 Go | 2 |
| Jusqu'à 6 | 500 m | 3 Go | 2 |
| Jusqu'à 12 | 500 m | 4 Go | 2 |
| Jusqu'à 30 | 500 m | 9 Go | 2 |
| Jusqu'à 60 | 1 000 m | 16 Go | 2 |
| Jusqu'à 150 | 2 000 m | 31 Go | 2 |
Pour déterminer quelle ligne s'applique, estimez vos récupérations de secrets par seconde :
fetches/s = Git Pull RPS × adoption rate × 3
Où :
Git Pull RPS est le débit de tirage Git (Git pull) maximal de votre instance GitLab. Vous pouvez le mesurer depuis la surveillance de votre environnement existant, consultez Extraire les métriques de trafic maximal.adoption rate est la fraction des jobs CI/CD qui utilisent le Secrets Manager (par exemple, 0,05 pour 5 %, 0,20 pour 20 %, ou 0,50 pour 50 %).3 est le nombre moyen supposé de secrets récupérés par job utilisant le Secrets Manager.Sélectionnez la ligne où Secret fetches/s atteint ou dépasse légèrement votre résultat. Par exemple, un déploiement avec 20 Git pull RPS mesurés à 20 % d'adoption : 20 × 0.20 × 3 = 12 fetches/s. Utilisez au moins la ligne Up to 12.
Après le déploiement, vérifiez vos estimations par rapport à l'utilisation réelle. Utilisez les requêtes de surveillance pour mesurer l'utilisation des ressources et passez à la ligne suivante lorsque les seuils sont dépassés.
Le CPU est déterminé par la fréquence à laquelle les jobs CI/CD récupèrent des secrets. Les opérations d'écriture de secrets (création ou mise à jour de secrets) sont rares par rapport au volume de pipeline et contribuent de manière négligeable à la charge CPU. Le tableau utilise le taux de clonage Git (Git Pull RPS) comme indicateur du taux de jobs CI, car chaque job CI/CD commence par un clonage Git. Pour la formule, consultez Estimer votre taux de récupération de secrets. Définissez la limite CPU à deux fois la demande CPU. Cela offre une marge de montée en charge pour les pics de démarrage et de provisionnement sans sur-réserver sur le nœud en régime permanent.
La Mémoire est déterminée par le nombre d'espaces de nommage OpenBao, ce qui correspond au nombre de groupes et de projets GitLab avec le Secrets Manager activé. Allouez environ 5 Mo par espace de nommage, plus une marge de sécurité de 1 Go, avec un minimum de 2 Go. Définissez la limite de mémoire égale à la demande de mémoire (classe QoS Guaranteed). OpenBao plante immédiatement lorsqu'il dépasse sa limite de mémoire, sans dégradation progressive.
Les Replicas assurent uniquement le basculement pour la haute disponibilité. Utilisez 2 réplicas pour tous les déploiements. OpenBao ne prend pas en charge la scalabilité horizontale en lecture (HRS) avec le backend de stockage PostgreSQL, donc les réplicas supplémentaires n'apportent aucun avantage en termes de débit.
OpenBao stocke ses données dans une base de données PostgreSQL séparée. Vous pouvez la coloquer sur le même serveur PostgreSQL que les bases de données GitLab. Aucune capacité de calcul de base de données supplémentaire au-delà des recommandations PostgreSQL de l'architecture de référence n'est requise.
Le chart Helm OpenBao configure ces valeurs par défaut du pool de connexions PostgreSQL :
| Paramètre | Valeur par défaut |
|---|---|
config.storage.postgresql.maxParallel | 5 |
config.storage.postgresql.maxIdleConnections | 2 |
N'augmentez pas ces valeurs sauf si vous observez un temps d'attente de connexion à la base de données dans votre surveillance.
Les besoins en stockage de la base de données dépendent principalement du nombre total de secrets. Chaque secret, y compris ses métadonnées et ses versions stockées, nécessite environ 13 Ko de stockage.
| Total des secrets | Stockage estimé |
|---|---|
| 10 000 | ~130 Mo |
| 50 000 | ~650 Mo |
| 100 000 | ~1,3 Go |
| 200 000 | ~2,6 Go |
La croissance du stockage est négligeable pour tous les niveaux d'architecture de référence. Allouer 5 à 10 Go de stockage de base de données offre une marge confortable.
Utilisez les requêtes suivantes pour vérifier que votre déploiement est correctement dimensionné et pour détecter quand une mise à l'échelle est nécessaire.
Pour mesurer l'utilisation du CPU par OpenBao :
sum(rate(container_cpu_usage_seconds_total{container="openbao-server"}[5m]))
Le résultat est exprimé en cœurs CPU. Multipliez par 1 000 pour convertir en millicœurs afin de comparer avec les valeurs de demande CPU dans le tableau de dimensionnement. Si l'utilisation du CPU dépasse constamment 50 % de la demande CPU, envisagez de passer à la ligne suivante dans le tableau de dimensionnement.
Pour mesurer l'utilisation de la mémoire par OpenBao :
sum(container_memory_working_set_bytes{container="openbao-server"})
Le résultat est exprimé en octets. La mémoire augmente à mesure que les groupes et les projets activent le Secrets Manager, d'environ 5 Mo par espace de nommage. Après un redémarrage, la mémoire se stabilise à mesure qu'OpenBao charge les métadonnées des paces de nommage depuis la base de données.
Pour calculer la demande de mémoire correcte, comptez les groupes et les projets avec le Secrets Manager activé et multipliez par 5 Mo, puis ajoutez 1 Go. Mettez à jour les ressources de votre pod si le résultat dépasse votre demande de mémoire actuelle. Si la mémoire affiche une tendance à la hausse soutenue sans provisionnement actif, recherchez des problèmes potentiels.
Pour détecter la limitation du CPU pouvant affecter la latence :
sum(rate(container_cpu_cfs_throttled_periods_total{container="openbao-server"}[5m]))
/
sum(rate(container_cpu_cfs_periods_total{container="openbao-server"}[5m]))
Un ratio de limitation supérieur à 0,25 (25 %) indique que la limite CPU est trop faible pour la charge de travail actuelle. Lorsqu'OpenBao est limité, les goroutines en attente de temps CPU entraînent une latence accrue lors de la récupération des secrets.
OpenBao fournit des points de terminaison de vérification de l'état pour la surveillance :
<your-openbao-url>/v1/sys/health : Renvoie l'état de santé d'OpenBao<your-openbao-url>/v1/sys/seal-status : Renvoie l'état de scellementVous pouvez intégrer ces points de terminaison à votre système de surveillance.
OpenBao stocke les données dans une base de données logique séparée sur PostgreSQL. Sauvegardez cette base de données en même temps que votre sauvegarde GitLab habituelle pour vous assurer que les secrets peuvent être restaurés après une défaillance.
Pour les procédures détaillées de sauvegarde et de restauration spécifiques à OpenBao, consultez la documentation de sauvegarde OpenBao.
Pour des informations sur la gestion de la clé de récupération OpenBao, notamment le stockage, la consultation et son utilisation pour générer un jeton root, consultez la gestion des clés de récupération.
OpenBao utilise une architecture à nœud actif unique. Un nœud traite toutes les requêtes, et les nœuds en veille assurent un basculement automatique si le nœud actif tombe en panne.
Les nœuds en veille chargent toutes les métadonnées des paces de nommage au démarrage, de sorte que la promotion vers le statut actif ne nécessite aucune initialisation supplémentaire. Le nombre d'espaces de nommage n'affecte pas le temps de basculement.
Pour les déploiements en production :
OpenBao ne prend pas en charge les mises à niveau sans interruption de service. Lors d'une mise à niveau, OpenBao initialise chaque space de nommage de manière séquentielle au démarrage. Chaque groupe ou projet avec le Secrets Manager activé compte comme un espace de nommage.
Pour effectuer la mise à niveau, cela prend environ 11 secondes pour 1 000 espaces de nommage, plus une base de 5 secondes.
Lorsqu'OpenBao implémentera le chargement des paces de nommage à la demande, le temps d'arrêt lors des mises à niveau sera considérablement réduit. Pour plus d'informations, consultez l'issue 595721.
OpenBao prend en charge les déploiements Geo. OpenBao est déployé sur les sites Geo primaire et secondaire, mais seul le site primaire exécute un nœud OpenBao actif.
Sur le site primaire, OpenBao s'exécute en tant que nœud actif connecté à une base de données PostgreSQL accessible en écriture. Sur le site secondaire, OpenBao s'exécute en mode veille, connecté à un réplica de lecture PostgreSQL.
La réplication en streaming PostgreSQL transporte automatiquement toutes les données OpenBao (secrets, politiques, configuration d'authentification) du site primaire vers le site secondaire.
Les deux instances GitLab (primaire et secondaire) se connectent à l'URL OpenBao primaire. Le déploiement OpenBao secondaire reste en veille, et est promu au statut actif lorsque la base de données PostgreSQL secondaire devient accessible en écriture lors d'un basculement Geo.
Sur le site secondaire, OpenBao enregistre les erreurs failed to acquire lock et cannot execute INSERT in a read-only transaction. Ces erreurs sont attendues. OpenBao ne peut pas acquérir le verrou de leader HA sur une base de données en lecture seule.
Prérequis :
L'OpenBao secondaire doit utiliser la même clé de déscellement que le primaire pour déchiffrer les données répliquées. Copiez le secret Kubernetes gitlab-openbao-unseal depuis le cluster primaire vers le cluster secondaire :
kubectl --namespace gitlab get secret gitlab-openbao-unseal -o yaml
Appliquez le secret exporté au cluster secondaire. Pour plus d'informations, consultez Sauvegarder les secrets.
Si vous prévoyez de mettre à jour l'enregistrement DNS du domaine primaire pour pointer vers le site secondaire lors du basculement, vous pouvez configurer OpenBao en conséquence à l'avance. Configurez le chart Helm et définissez url et jwt_audience sur l'URL OpenBao primaire :
global:
openbao:
enabled: true
url: https://openbao.<primary-domain>
jwt_audience: https://openbao.<primary-domain>
Pour plus d'informations sur les options de configuration du chart, consultez Configuration Geo.
Déployez le chart Helm GitLab sur le site secondaire. Les pods OpenBao démarrent et restent en mode veille. C'est le comportement attendu.
Sur le cluster secondaire, vérifiez que les pods OpenBao sont en cours d'exécution :
kubectl --namespace gitlab get pods -l app=openbao
Tous les pods doivent être à l'état Running. Les pods secondaires n'ont pas le label openbao-active: "true". C'est le comportement attendu.
Confirmez que le service actif n'a aucun point de terminaison sur le cluster secondaire :
kubectl --namespace gitlab get endpoints gitlab-openbao-active
Zéro point de terminaison sur le secondaire est attendu.
Testez le Secrets Manager en exécutant un pipeline CI qui utilise une variable Secrets Manager sur le site secondaire.
Lorsque vous travaillez avec le Secrets Manager, vous pouvez rencontrer les problèmes suivants.
| Symptôme | Cause | Résolution |
|---|---|---|
cipher: message authentication failed ou unknown key ID dans les journaux OpenBao secondaires | Discordance de clé de déscellement entre le primaire et le secondaire | Copiez gitlab-openbao-unseal depuis le cluster primaire vers le cluster secondaire et redémarrez les pods OpenBao. |
failed to acquire lock dans les journaux OpenBao secondaires | OpenBao en veille sur une base de données en lecture seule | Comportement attendu. Aucune action requise. |
cannot execute INSERT in a read-only transaction dans les journaux OpenBao secondaires | OpenBao tentant une élection de leader sur un réplica de lecture | Comportement attendu. Aucune action requise. |
| Échec de l'authentification JWT après un basculement Geo | jwt_audience ne correspond pas à boundAudiences dans OpenBao | Définissez jwt_audience sur l'URL OpenBao primaire sur les deux sites. |
Utilisez cette section lorsque les jobs CI/CD sont lents à récupérer des secrets ou que les opérations sur les secrets expirent.
Utilisez la requête suivante pour mesurer la latence moyenne des requêtes en millisecondes. La requête fonctionne à n'importe quel niveau de trafic, y compris les déploiements à faible trafic :
rate(openbao_core_handle_request_sum[5m])
/
rate(openbao_core_handle_request_count[5m])
Dans des conditions de charge normales, la latence moyenne pour tous les types de requêtes est généralement de 3 à 7 ms. Analysez si la latence moyenne dépasse constamment 20 ms.
Lorsqu'OpenBao traite activement des requêtes, utilisez la requête suivante pour la latence P99 :
openbao_core_handle_request{quantile="0.99"}
Le P99 normal est inférieur à 10 ms. Cette requête renvoie NaN lorsqu'OpenBao est inactif car la fenêtre de résumé ne contient aucune observation récente. Utilisez la requête basée sur le taux dans ce cas.
| Problème potentiel | Élément à vérifier | Requête | Seuil | Action |
|---|---|---|---|---|
| Limite CPU trop faible | Ratio de limitation CFS | Requête de limitation CPU | > 25 % | Augmenter la limite CPU |
| La demande dépasse la capacité CPU | Utilisation du CPU | Requête d'utilisation CPU | > 50 % de la demande | Passer à la ligne suivante dans le tableau de dimensionnement |
| Pic de requêtes | Requêtes en cours | openbao_core_in_flight_requests | Soutenu au-dessus de 5 | Transitoire. Surveiller les récurrences. |
| Goulot d'étranglement PostgreSQL | Latence moyenne de lecture PostgreSQL | rate(openbao_postgres_get_sum[5m]) / rate(openbao_postgres_get_count[5m]) | > 5 ms | Vérifier les ressources PostgreSQL et le pool de connexions |
| Pression mémoire | Utilisation de la mémoire | Requête d'utilisation de la mémoire | Proche de la demande de mémoire | Augmenter la mémoire en utilisant la formule de l'espace de nommage |
Si la latence PostgreSQL est élevée, vérifiez si le pool de connexions est saturé. Si toutes les connexions sont occupées, les requêtes supplémentaires sont mises en file d'attente et entraînent une latence. Pour la configuration du pool de connexions, consultez Ressources de base de données. Vérifiez le nombre de connexions dans votre surveillance PostgreSQL ou dans les journaux OpenBao.