Aller au contenu

Simplifier la gestion des secrets avec Vault Secret Operator

Dans cet article, nous allons explorer comment configurer et utiliser Vault Secret Operator pour synchroniser des secrets Vault dans Kubernetes.

Des clés, des cadenas et des secrets dans un tourbillon de flux de donnée
Vault Secret Operator

Introduction

Dans le monde du développement et des opérations, la sécurité et la gestion des secrets sont des préoccupations majeures. Vault est une solution puissante qui permet de gérer de manière sécurisée les secrets et de les distribuer à des applications. Avec l'émergence des environnements Kubernetes, Vault Secret Operator simplifie encore plus ce processus en automatisant la synchronisation des secrets entre Vault et les applications Kubernetes.

Qu'est-ce que Vault ?

Vault est un outil open-source pour la gestion des secrets. Il permet de stocker, gérer et contrôler l'accès aux tokens, mots de passe, certificats et autres données sensibles.

Qu'est-ce que le Vault Secret Operator ?

Le Vault Secret Operator est un opérateur Kubernetes qui permet de synchroniser les secrets stockés dans Vault avec les secrets de votre cluster Kubernetes. Il simplifie l'accès aux secrets et automatise leur propagation, améliorant ainsi la sécurité et la gestion des configurations.

Pourquoi utiliser Vault pour la gestion des secrets ?

Les secrets sont souvent nécessaires pour accéder à des bases de données, des API externes, et d'autres services sensibles. Utiliser Vault pour gérer ces secrets offre plusieurs avantages :

  • Sécurité renforcée : Les secrets sont stockés de manière sécurisée et chiffrée.
  • Intégration : Vault supporte plusieurs plateformes et types d'authentification (Cloud, Kubernetes, JWT/OIDC, etc.).
  • Flexibilité : Vault permet de gérer différents types de secrets et d'automatiser la génération de certains secrets.

Installation de Vault sur Kubernetes

Pour installer Vault sur Kubernetes, nous utilisons le chart Helm officiel.

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault --set server.dev.enabled=true
💡
Nous utilisons le mode de developpement pour faciliter le déploiement. Ce mode n'est pas recommandé en production.

Configuration du secret engine KV dans Vault

Une fois Vault installé, nous devons configurer un secret engine de type KV. Cela peut être fait en utilisant l'interface CLI de Vault ou l'UI

vault secrets enable -path=kvv2 kv-v2

Création d'un secret

Créons un secret simple pour notre application.

vault kv put kvv2/my-app/config username="user1" password="passw0rd"

Installation de Vault Secret Operator sur un cluster Kubernetes

⚠️
Avant de déployer Vault Secret Operator, assurez-vous que Vault est correctement configuré et accessible depuis votre cluster Kubernetes.
helm install vault-secrets-operator hashicorp/vault-secrets-operator -n vault-secrets-operator-system --create-namespace

Authentification du cluster Kubernetes à Vault

Vault

Nous créons une policy pour autoriser la lecture des secrets.

vault policy write my-policy - << EOF

path "kvv2/data/*" {
  capabilities = ["list", "read"]
}

path "kvv2/metadata/*" {
  capabilities = ["list", "read"]
}
EOF

Ensuite, on configure une authentification Kubernetes pour notre cluster avec des short lived token

# Création d'une auth
vault auth enable -path demo-auth-mount kubernetes

# Update de la config 
KUBERNETES_CA=$(kubectl config view --raw --minify --flatten --output 'jsonpath={.clusters[].cluster.certificate-authority-data}' | base64 --decode)
KUBERNETES_HOST=$(kubectl config view --raw --minify --flatten --output 'jsonpath={.clusters[].cluster.server}')

vault write auth/demo-auth-mount/config \
kubernetes_host="${KUBERNETES_HOST}" \
kubernetes_ca_cert="${KUBERNETES_CA}" \
disable_local_ca_jwt="true"

# Création d'un role
vault write auth/demo-auth-mount/role/demo \
bound_service_account_names=default \
bound_service_account_namespaces=my-ns \
policies=my-policy

Vault Secret Operator

On commence par créer un namespace dédié pour notre application et nos secrets :

kubectl create namespace my-ns

Ensuite, nous créons 2 ressources pour la connexion à Vault :

  • VaultConnection
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultConnection
metadata:
  namespace: my-ns
  name: my-vault-connection
spec:
  address: $VAULT_ADDR # replace with your Vault address
  • VaultAuth
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: my-vault-auth
  namespace: my-ns
spec:
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: demo
    serviceAccount: default
  vaultConnectionRef: my-vault-connection

Il faut s'assurer que le service account utilisé possède le ClusterRole system:auth-delegator

kubectl create clusterrolebinding vault-client-auth-delegator \
    --clusterrole=system:auth-delegator \
    --serviceaccount=my-ns:default 

Synchronisation des secrets

La ressource VaultStaticSecret permet de synchroniser un path Vault avec un secret Kubernetes.

---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: vault-static-secret
  namespace: my-ns
spec:
  vaultAuthRef: my-vault-auth # Nom de la VaultAuth utilisé
  mount: kvv2 # Mount path
  type: kv-v2
  path:  my-app/config # Path to synchronize
  refreshAfter: 10s # Delai before refresh
  destination: 
    create: true
    name: my-secret # secret name

Utilisation du secret

Il ne reste plus qu'a utiliser le secret dans notre déploiement.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-ns
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: alpine
        env:
        - name: USERNAME
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: username
        - name: PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: password
        command: ["/bin/sleep"]
        args: ["infinity"]

Mise à jour des secrets et actualisation de l'application

Vault Secret Operator peut détecter les modifications et mettre à jour les secrets dans notre application sans nécessiter de redéploiement en déclenchant un rollout d'une ressource de type DeploymentReplicaSet  ou StatefulSet.

Il faut ajouter le bloc rolloutRestartTargets afin d'identifier les ressources à redémarrer en cas de changement du secret.

---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: vault-static-secret
  namespace: my-ns
spec:
  vaultAuthRef: my-vault-auth # Nom de la VaultAuth utilisé
  mount: kvv2 # Mount path
  type: kv-v2
  path:  my-app/config # Path to synchronize
  refreshAfter: 10s # Delai before refresh
  destination: 
    create: true
    name: my-secret # secret name
  rolloutRestartTargets: # TO ADD
      - kind: Deployment # TO ADD
        name: my-app      # TO ADD

Quand une modification du secret est détecté (cf refreshAfter), un rollout du déploiement est déclenché afin que notre application prenne en compte la nouvelle valeur du secret.

💡
Il faut s'assurer que les probes de notre deployment soient bien configurés pour éviter l'interruption de service.
0:00
/0:43

Avantages de cette approche en termes de sécurité et de gestion des configurations

  • Réduction du risque d'erreurs humaines : Les mises à jour des secrets sont automatiques et ne nécessitent pas d'intervention manuelle.
  • Amélioration de la sécurité : Les secrets sont gérés et propagés de manière sécurisée.
  • Gain de temps : Les administrateurs peuvent se concentrer sur d'autres tâches critiques sans se soucier de la gestion manuelle des secrets.

Conclusion

En résumé, Vault Secret Operator révolutionne la gestion des secrets dans Kubernetes en automatisant leur synchronisation avec Vault. Cette approche renforce non seulement la sécurité des environnements de développement et de production, mais réduit également le risque d'erreurs humaines et améliore l'efficacité opérationnelle. Les administrateurs peuvent se concentrer sur des tâches plus critiques, assurés que les secrets sont gérés de manière sécurisée et automatique.

Dans un prochain article, nous verrons comment utiliser le secret engine base de données pour une gestion encore plus sécurisée des credentials de base de données. Stay tuned 😃 !

Dernier