Le problème des secrets en GitOps

Dans une approche GitOps, tout passe par le repo Git : les manifests Kubernetes, les configurations, et idéalement les secrets aussi. Mais comment gérer les secrets de manière sécurisée dans un repo Git ?

SOPS : Secrets OPerationS

Principe : chiffrement côté fichier

SOPS s’intègre aux KMS, par exemple sur GCP Cloud Key Management via le principe d’Envelope Encryption : il génère une clé symétrique éphémère (DEK) pour chiffrer les secrets, et délègue à GCP KMS le chiffrement de cette DEK.

Le KMS ne voit jamais les secrets eux-mêmes, et le fichier commité dans Git contient les valeurs chiffrées ainsi que la DEK chiffrée.

En local, un gcloud auth application-default login suffit alors qu’en production sur GKE il est plutot préférable d’utiliser le Workload Identity pour lier le ServiceAccount Kubernetes au compte de service GCP.

Chaque opération est enfin tracée dans Cloud Audit Logs.

Limitations

  • Nécessite une infrastructure de gestion de clés externe (KMS ou PGP/Age). Cela introduit une dépendance sur AWS KMS, GCP KMS, etc.
  • La rotation de clé implique de re-chiffrer tous les fichiers concernés (sops updatekeys).
  • SOPS ne crée pas de Secret Kubernetes directement. Il faut un outil intermédiaire : Helm Secrets, ArgoCD avec plugin, Kustomize + plugin, ou un job de déchiffrement en pipeline CI/CD.
  • Le déchiffrement se fait souvent dans le pipeline CI/CD ou sur le poste du développeur. La valeur en clair transite quelque part, ce qui élargit la surface d’attaque.
  • Contrairement à Sealed Secrets + un opérateur GitOps, SOPS seul ne met pas à jour les secrets dans le cluster automatiquement.

C’est l’outil que j’ai le plus utilisé dans un contexte professionnel, je trouve que c’est un bon compromis pour gérer les secrets en GitOps à condition d’accepter la complexité de gestion des clés et de mettre en place les bonnes pratiques pour éviter les erreurs humaines (ex: commit de secrets en clair) qui spoiler finiront par arriver

SOPS + ArgoCD

Sops s’intègre très bien avec ArgoCD via le plugin argocd-vault-plugin.

Sinon il est aussi possible d’installer Helm Secrets comme Config Management Plugin.

Exemple d’utilisation

# Chiffrer un fichier de secrets
sops -e secrets.yaml > secrets.enc.yaml
# Déchiffrer un fichier de secrets
sops -d secrets.enc.yaml > secrets.yaml
# Mettre à jour les clés de chiffrement
sops updatekeys secrets.enc.yaml
# Editer un fichier de secrets chiffré
sops edit secrets.enc.yaml

Les alternatives et leurs limites

Sealed Secrets : côté cluster, clé non portable

Les Sealed Secrets(GitHub) de Bitnami permettent de chiffrer les secrets côté cluster.

Sealed Secrets est composé en 2 parties:

  • Un controlleur côté cluster (installable via Helm)
  • Une CLI côté client : kubeseal (brew install kubeseal)

kubeseal utilise une clé asymétrique pour chiffrer les secrets que seul le contrôleur peut déchiffrer. Ces secrets chiffrés sont ensuite encodés dans une ressource SealedSecret.

Limitations

Voici selon moi les principales limitations de Sealed Secrets :

  • La clé de chiffrement est stockée dans le cluster, ce qui rend les secrets non portables entre clusters.
  • En cas de compromission du cluster, les secrets peuvent être à risque.
  • En cas de disaster recovery, la restauration du cluster doit inclure la restauration de la clé de chiffrement pour pouvoir accéder aux secrets.
  • Les secrets sont uniquement utilisable dans un contexte Kubernetes, pas de possibilité de les utiliser pour d’autres usages (CI/CD, etc).

Je n’ai pas eu l’occasion d’utiliser Sealed Secrets dans un milieu professionnel, mais j’ai pu l’expérimenter dans des projets personnels.

Vault : puissant mais lourd à opérer

Hashicorp Vault est un serveur centralisé de gestion de secrets. Ils sont stockés, chiffrés et distribués dynamiquement via une API et les applications les récupèrent au runtime.

Limitations

  • Complexité opérationnelle élevée : Vault est un service à part entière qu’il faut déployer, configurer, superviser et maintenir.
  • Single point of failure potentiel : Si Vault est down, toutes les applications qui récupèrent leurs secrets dynamiquement peuvent être impactées.
  • C’est un outil (trop) complet : Les concepts sont nombreux et nécessitent un temps de montée en compétence réel avant d’opérer Vault sereinement.

C’est un outil que j’ai eu l’occasion d’utiliser mais je n’ai jamais eu la “chance” de le déployer et l’opérer moi même de A à Z, je ne me sens pas légitime pour en parler plus en détail dans cet article.

A Retenir

SOPS est un outil de chiffrement de secrets qui peut s’intégrer dans une approche GitOps. Comme tout outil, il vient avec ses avantages et ses inconvénients, il est important de les connaître pour faire un choix éclairé en fonction de son contexte et de ses besoins.

Pour résumer très grossièrement préférez Sealed Secrets pour démarrer et les cas d’usage simples, SOPS pour les cas d’usage plus complexes et les équipes qui ont déjà une bonne maîtrise de la gestion de clés, et Vault pour les besoins les plus avancés et les équipes qui ont les ressources pour l’opérer sereinement.

Sources