HashiCorp Vault Secret Manager¶

Vue d'ensemble¶

La solution HashiCorp Vault a été déployée sur le nouveau projet GCP gke-vault-464615 dans le cluster GKE-vault. L'infrastructure est entièrement terraformée, incluant la création des accès, la gestion des moyens de connexion, les rôles et les politiques.

URL d'accès : https://vault.glamuse.net/

Ajout d'une nouvelle application¶

Configuration Terraform¶

Pour ajouter une nouvelle application, il suffit d'ajouter une ligne dans le bloc suivant du projet Terraform :

apps = [
  # glamuse-site environments
  { env = "staging", app_name = "glamuse-site" },
  { env = "uat1", app_name = "glamuse-site" },
  { env = "uat2", app_name = "glamuse-site" },
  { env = "prod", app_name = "glamuse-site" },
  { env = "marketing", app_name = "glamuse-site" },
  { env = "dev1", app_name = "glamuse-site" },
  { env = "dev2", app_name = "glamuse-site" },
]

Ressources créées automatiquement¶

Une fois l'application ajoutée et le Terraform appliqué, les ressources suivantes sont créées automatiquement pour chaque environnement :

1. Composants cryptographiques¶

Clé privée TLS : Paire de clés RSA 2048 bits pour la signature JWT
Clé publique : Utilisée par Vault pour la vérification des signatures JWT

2. Ressources Vault¶

Backend d'authentification JWT : jwt-{env}-{app_name} - méthode d'authentification dédiée
Politique Vault : policy-{env}-{app_name} - permissions pour l'accès aux secrets
Rôle JWT : role-{env}-{app_name} - lie le backend d'authentification à la politique
Secret KV : Stocke la clé privée dans secret/jwt-key/{env}/{app_name}

3. Fichiers locaux¶

Clé privée PEM : secrets/{env}/{app_name}-private.pem
Clé privée Base64 : secrets/{env}/{app_name}-private.pem.b64

4. Permissions accordées¶

Chaque application obtient l'accès à : - CRUD complet sur secret/data/{env}/{app_name}/* - Lecture/Liste sur secret/metadata/{env}/{app_name}/* - Opérations de cycle de vie (delete/undelete/destroy)

5. Isolation de sécurité¶

Backend d'authentification JWT séparé par application
Accès aux secrets limité à l'environnement
TTL de token de 1 heure
Clés privées spécifiques à l'application

Récupération de la clé secrète¶

Une fois créée, la clé secrète se trouve dans Vault à l'emplacement :

https://vault.glamuse.net/ui/vault/secrets/secret/kv/list/jwt-key/{env}/{app_name}

Pour utiliser cette clé : 1. Déclarez la clé dans les secrets CI/CD du projet 2. Générez un JWT dans l'application pour communiquer avec Vault 3. Récupérez les secrets via l'API Vault

Authentification et gestion des secrets¶

Accès et groupes autorisés¶

L'accès à Vault est contrôlé par des groupes Google spécifiques. Seules les personnes ajoutées à ces groupes pourront automatiquement accéder à Vault :

Groupes DevOps (accès complet)¶

- it.ops@glamuse.com
- it.manager@glamuse.com
- it.security@glamuse.com

Groupes Dev (accès développement uniquement)¶

- it.apps@glamuse.com
- it.web@glamuse.com
- it.ops@glamuse.com (accès aussi au rôle dev)
- it.manager@glamuse.com (accès aussi au rôle dev)
- it.security@glamuse.com (accès aussi au rôle dev)

Note : Les personnes ajoutées à ces groupes Google obtiendront automatiquement l'accès à Vault selon leur rôle. Aucune configuration manuelle supplémentaire n'est nécessaire.

Connexion à l'interface¶

URL de connexion : https://vault.glamuse.net/ui/vault/auth

Sélectionnez la méthode OIDC
Dans l'onglet Role, indiquez votre rôle :
Équipe dev : dev
Équipe devops : devops

Rôles et permissions¶

Équipe Dev¶

Les développeurs ont accès en lecture/écriture uniquement aux secrets des environnements de développement : - dev1, dev2, marketing, staging, uat1, uat2

Équipe DevOps¶

Les DevOps ont un accès complet à tous les environnements, y compris la production.

Organisation des secrets¶

Les secrets doivent respecter la structure de path suivante :

{env}/{app_name}/{FRONT/BACK/BACKOFFICE...}/{SERVICE}

Note : La partie {FRONT/BACK/BACKOFFICE...} est obligatoire seulement s'il y a une distinction entre les composants de l'application (front-end, back-end, back-office, etc.).

Exemples : - Path avec composant : dev2/glamuse-site/front/cloudflare - Path sans composant : staging/mobile-apps/appstore - Keys : CLOUDFLARE_API_TOKEN, APP_STORE_CONNECT_API_KEY

Une fois configurés, les applications peuvent récupérer leurs secrets via l'API Vault en utilisant leur JWT d'authentification.

Intégration et exemples de code¶

Utilisation dans glamuse-site¶

Sur glamuse-site, les secrets sont rapatriés automatiquement lors de la phase de build et sont accessibles directement via l'objet Config :

Config::get('MON_SECRET')

Exemple de code d'accès direct au Vault¶

Pour un exemple de code d'accès direct au Vault, consulter secretsgenerate.class.php

Références¶

Pour plus d'informations sur l'API Vault et les méthodes d'authentification disponibles, consultez la documentation officielle :

Documentation API HashiCorp Vault : https://developer.hashicorp.com/vault/api-docs

Sauvegardes¶

Des sauvegardes automatiques de Vault sont effectuées quotidiennement pour la récupération en cas d'incident.

Configuration des sauvegardes¶

Fréquence : Tous les jours à 2h00 UTC
Mécanisme : Cronjob Kubernetes vault-backup-daily dans le namespace vault du cluster gke-vault
Image : hashicorp/vault:1.20.0
Service Account : vault (avec authentification automatique GCP)
Stockage : Bucket Google Cloud Storage gke-vault-464615-vault-backups

Format et organisation¶

Les snapshots sont organisés selon la structure suivante :

gke-vault-464615-vault-backups/snapshots/YYYY/MM/DD/vault-backup-YYYYMMDD-HHMMSS.snap

Exemple :

gke-vault-464615-vault-backups/snapshots/2025/08/19/vault-backup-20250819-020001.snap

Authentification et sécurité¶

Token d'authentification : Token Vault restreint stocké dans le secret Kubernetes vault-backup-token
Permissions : Token avec droits limités pour les opérations de snapshot uniquement
Service Account GCP : Authentification automatique via le service account Kubernetes pour l'accès à GCS

Rétention et historique¶

Jobs réussis : Conservation de 3 exécutions dans l'historique Kubernetes
Jobs échoués : Conservation de 3 exécutions pour diagnostic

Infrastructure de sauvegarde¶

Cluster : gke-vault
Namespace : vault
Type : Cronjob Kubernetes (vault-backup-daily)
Destination : Google Cloud Storage
Vérification : Contrôle d'intégrité automatique des snapshots

Surveillance des sauvegardes¶

Une sonde Grafana est configurée pour vérifier la fraîcheur des sauvegardes : - Métriques : Vérification de l'âge du dernier backup dans le bucket GCS - Seuil d'alerte : Dernière sauvegarde datant de plus de 24 heures - Notification : Alerte automatique en cas de backup manquant

Cette stratégie garantit une rétention historique des données et permet une restauration rapide en cas de besoin.

Monitoring et surveillance¶

Sondes Kuma¶

Deux sondes Kuma Uptime sont configurées pour surveiller Vault :

1. Sonde Health Check¶

Type : HTTP(s)
URL : https://vault.glamuse.net
Méthode : GET
Intervalle : 60 secondes
Vérification : Code de statut 200
Objectif : Vérifier la disponibilité générale du service Vault

2. Sonde Test Secret¶

Type : HTTP(s)
URL : https://vault.glamuse.net/v1/secret/data/kuma/KEY
Méthode : GET
Headers : Token d'authentification Vault configuré
Intervalle : 60 secondes
Vérification : Code de statut 200
Objectif : Vérifier l'authentification et l'accès aux secrets

Ces sondes permettent de détecter rapidement les problèmes de disponibilité ou d'authentification sur Vault.