tools/hashicorp-vault/iac/modules

Modules

app_policy

Ce module à déclarer dans ce projet permet au projet subordonné de déclarer le module app_roles suivant.

Ce module Terraform associe un projet Git à un ensemble de ressources Vault :

• Une policy -ops pour la CI/CD du projet (dépôt Git).
• Une policy app pour le runtime applicatif (pods).
• Un groupe Vault lié au projet. (pour ajouter les utilisateurs vault associé à leur compte gitea)
• Un rôle JWT Vault lié à ton SCM (ex: Gitea).
• Les droits nécessaires pour gérer les rôles Kubernetes et Postgres associés au projet.

🚀 Usage

module "webapp_vault" {
  source = "./modules/vault_project"
  name   = "webapp"

  gitea_app_id = "my-gitea-oauth-app-id" # secret récupéré via vault dans la CI
}

app_roles

Ce module Terraform configure les rôles Vault nécessaires pour qu’une application déployée dans Kubernetes puisse :

• s’authentifier auprès de Vault via son ServiceAccount,
• obtenir des identifiants Postgres dynamiques,
• accéder à ses secrets dans Vault.

🚀 Usage

module "webapp_vault_app" {
  source = "./modules/vault_app"
  name   = "webapp"
  database = "mydb" # optionnel, par défaut = name
}

principe

                          +-----------------+
                          |   Dépôt Git     |
                          | (CI/CD Terraform|
                          +--------+--------+
                                   |
                          [Auth via Vault JWT Role]
                                   |
                        +----------v-----------+
                        | Vault (Policy -ops) |
                        |   - Peut gérer      |
                        |     - Roles K8s     |
                        |     - Roles Postgres|
                        |     - Secrets KV    |
                        +----------+-----------+
                                   |
                        [Token éphémère CI/CD]
                                   |
                  +----------------v----------------+
                  | Kubernetes API                  |
                  | - Applique CRDs / Secrets       |
                  | - Configure Longhorn / RBAC     |
                  +---------------------------------+


   --------------------------- Flux runtime ---------------------------

                          +-----------------+
                          |     Pod App     |
                          | (SA: webapp)    |
                          +--------+--------+
                                   |
                        [Auth via Vault K8s Role]
                                   |
                        +----------v-----------+
                        | Vault (Policy app)  |
                        |   - Peut lire       |
                        |     - kvv2/data/... |
                        |     - postgres/...  |
                        +---------------------+
                                   |
                        [Secrets dynamiques: PW DB, etc.]
                                   |
                          +--------v---------+
                          |   Postgres DB    |
                          +------------------+

---

documentation destinée aux dépots des applications:

🔑 Gestion des secrets avec Vault Secrets Operator (VSO)

Ce repository utilise Vault Secrets Operator pour gérer les secrets de l’application (notamment les identifiants Postgres).
L’objectif est d’éviter de stocker des credentials statiques, en déléguant la génération et la rotation à HashiCorp Vault.

---

⚙️ Architecture

1. Terraform côté admin configure Vault :

   • un backend Postgres (postgres/) connecté à la base via pgbouncer,
   • un rôle Vault webapp (postgres/roles/webapp) qui définit la manière dont les credentials dynamiques sont créés,
   • un rôle Kubernetes webapp (auth/kubernetes/role/webapp) qui autorise le ServiceAccount webapp du namespace à s’authentifier auprès de Vault.

2. L’application (dans ce repo) déclare :

   • un VaultAuth qui associe le ServiceAccount webapp au rôle Vault webapp,
   • un VaultDynamicSecret qui demande un secret dynamique (postgres/creds/webapp),
   • un Secret Kubernetes généré automatiquement par VSO (vso-db-credentials), injecté dans le Pod de l’application.

---

🛠️ Ressources déployées

VaultAuth

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: auth
  namespace: {{ .Release.Namespace }}
spec:
  method: kubernetes
  mount: kubernetes
  kubernetes:
    role: webapp
    serviceAccount: {{ include "webapp.serviceAccountName" . }}
    audiences:
      - vault

Permet à VSO (et donc à l’app) de s’authentifier auprès de Vault avec le rôle webapp.

VaultDynamicSecret

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultDynamicSecret
metadata:
  name: vso-db
  namespace: {{ .Release.Namespace }}
spec:
  mount: postgres
  path: creds/webapp   # chemin du rôle dynamique Postgres
  destination:
    create: true
    name: vso-db-credentials
  rolloutRestartTargets:
  - kind: Deployment
    name: {{ include "webapp.fullname" . }}
  vaultAuthRef: auth

Demande un secret dynamique Postgres depuis Vault et le stocke dans un Secret Kubernetes nommé vso-db-credentials. Le Deployment de l’app est redémarré automatiquement à chaque rotation de credentials.

📦 Consommation du secret Une fois VSO en place, les credentials Postgres sont disponibles dans le Secret Kubernetes :

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: app
    image: myapp:latest
    env:
      - name: DB_USERNAME
        valueFrom:
          secretKeyRef:
            name: vso-db-credentials
            key: username
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: vso-db-credentials
            key: password

🔄 Rotation Vault génère des identifiants éphémères (par défaut TTL = 1h).

VSO renouvelle ou régénère automatiquement ces credentials.

Lorsqu’un nouveau secret est émis, le Deployment ciblé est redémarré pour recharger les variables d’environnement.

✅ Résumé Pas de secrets stockés en clair dans Git ou Helm.

Rotation automatique des credentials Postgres.

Intégration fluide avec Kubernetes via ServiceAccounts.