OVHcloud ESO Provider pour secrets Kubernetes — guide ESO v2.3

OVHcloud ESO Provider pour secrets Kubernetes — guide ESO v2. 3 Intégration du fournisseur OVHcloud ESO avec l'External Secrets Operator pour gérer les secrets Kubernetes via le Secret Manager. Le fournisseur OVHcloud ESO s'intègre à l'External Secrets Operator pour orchestrer les secrets Kubernetes via le Secret Manager.

Le fournisseur OVHcloud ESO s'intègre à l'External Secrets Operator pour orchestrer les secrets Kubernetes via le Secret Manager. Cette approche, associant ESO et le provider OVHcloud, permet d'exposer des valeurs externes comme des Kubernetes Secrets et de les synchroniser automatiquement lorsque les sources externes changent.

Qu'est-ce que l'External Secrets Operator et le fournisseur OVHcloud ESO ?

L'External Secrets Operator (ESO) est un projet sandbox CNCF lancé en 2022. Il lit des données depuis des API externes et injecte les valeurs correspondantes dans un secret Kubernetes. Si une valeur évolue dans la source externe, ESO met à jour le secret dans le cluster. Le fournisseur OVHcloud ESO permet de connecter ESO au Secret Manager d'OVHcloud via un (Cluster)SecretStore, puis à travers un ExternalSecret on précise les secrets à récupérer et à créer commeSecret Kubernetes dans le cluster.

Pour aller plus loin, il faut consulter la documentation officielle d'ESO et les guides du fournisseur OVHcloud.

Prérequis et configuration

• Compte OVHcloud et accès au Secret Manager via OKMS.
• Domaine OKMS et identifiant OKMS correspondant.
• Utilisateur IAM local pour générer un PAT (token).
• OVHcloud CLI installé et configuré.
• opérationnel pour déployer ESO et le Secret Store.

Le provider OVHcloud ESO prend en charge l’authentification par token ou par mTLS. Dans cet article, l’authentification par token est utilisée, avec génération d’un PAT via l’interface CLI et stockage sous forme de secret Kubernetes.

Déployer et connecter ESO au Secret Manager

Pour commencer, installez ou mettez à jour ESO via Helm et assurez-vous d’utiliser une version ≥ 2.3.0. Une fois ESO en place, créez un ClusterSecretStore qui connecte ESO au Secret Manager d’OVHcloud. Le fichier de déploiement référence le serveur KMS, l’OKMS ID et le token obtenu précédemment.

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: secret-store-ovh
spec:
  provider:
    ovh:
      server: "${KMS_ENDPOINT}"  # ex: "https://eu-west-rbx.okms.ovh.net"
      okmsid: "${OKMS_ID}"
      auth:
        token:
          tokenSecretRef:
            name: ovh-token
            namespace: external-secrets
            key: token

Le token est stocké dans un Secret Kubernetes nommé ovh-token dans l’espace external-secrets, et le SecretStore pointe vers ce token pour authentifier les appels au Secret Manager OVHcloud.

apiVersion: v1
kind: Secret
metadata:
  name: ovh-token
  namespace: external-secrets
data:
  token: <TOKEN_BASE64>

Après avoir généré le cluster secret store, appliquez-le dans le cluster :

kubectl apply -f clustersecretstore.yaml

Vérifiez l’état du stockage :

kubectl get clustersecretstore.external-secrets.io/secret-store-ovh

Création d’un ExternalSecret et obtention du secret

Créez un ExternalSecret qui indique où récupérer le secret dans le Secret Manager et comment le mapper dans une secret Kubernetes. Exemple simplifié :

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: docker-config-secret
  namespace: external-secrets
spec:
  refreshInterval: 30m
  secretStoreRef:
    name: secret-store-ovh
    kind: ClusterSecretStore
  data:
    - secretKey: .dockerconfigjson
      remoteRef:
        key: prod/eu-west-par/dockerconfigjson

Lorsque l’opération est réussie, Kubernetes crée l’objet Secret nommé ovhregistrycred dans l’espace external-secrets avec les données récupérées du Secret Manager.

Ce que cela change et les limites

Cette approche offre une synchronisation continue entre les secrets externes et les clusters Kubernetes, sans exposition manuelle des valeurs sensibles. Elle centralise la gestion des secrets et réduit les erreurs de configuration. Cependant, elle dépend de la stabilité du provider OVHcloud et des accès réseau au OKMS. La rotation des tokens et la gestion des permissions restent essentielles, tout comme la surveillance des droits accordés par le Secret Manager et les scopes IAM.

Deux points à garder à l’esprit : l’authentification par token nécessite une rotation régulière du PAT, et l’utilisation du mode mTLS reste optionnelle si l’organisation le souhaite pour des exigences de sécurité renforcées.

Pour terminer

Avec le fournisseur OVHcloud ESO et le Secret Manager, l’intégration des secrets Kubernetes gagne en fluidité et en sécurité. L’éco-système évolue, et il sera utile de suivre les évolutions des versions ESO et du provider OVHcloud pour tirer parti des améliorations et des éventuelles nouvelles capacités, comme le support de scénarios de récupération de secrets plus complexes.