SecretsManagement

Portée : namespaced · Requis par chaque workload

Sélectionne le backend d'identifiants pour un namespace. Les workloads du même namespace peuvent s'y rattacher via secretsRef et référencer les noms des Secrets matérialisés ; un workload sans secretsRef utilise à la place des Secrets que vous créez vous-même. Un backend par ressource. Pour le modèle de secrets complet, les providers et la matrice Azure Key Vault, voir Gestion des secrets.

Spec

Champ	Type	Description
`backend`	enum `eso` \| `sealedSecrets` (requis)	Le backend d'identifiants
`eso`	object	Configuration ESO (lorsque `backend: eso`)
`sealedSecrets`	object	Configuration Sealed Secrets (lorsque `backend: sealedSecrets`)

`eso`

Champ	Type	Description
`provider`	enum `azureKeyVault` (par défaut) \| `hashicorpVault` \| `raw`	Le provider du `SecretStore` ESO
`vaultURL`	string	URL Azure Key Vault (provider azureKeyVault)
`authType`	enum `WorkloadIdentity` (par défaut) \| `ServicePrincipal`	Méthode d'authentification Azure
`serviceAccountName`	string	SA sous laquelle ESO s'authentifie (Workload Identity). L'opérateur crée cette ServiceAccount si elle est absente (détenue par la CR, annotée depuis `clientID`/`tenantID`) ; une SA préexistante est adoptée sans modification
`clientID`	string	Client ID de l'identité managée affectée par l'utilisateur (Azure). Apposé sur la SA créée comme `azure.workload.identity/client-id`, qu'ESO lit pour échanger le token de la SA. Requis pour Workload Identity, sauf si vous créez vous-même la SA avec cette annotation
`tenantID` / `authSecretRef`	string / refs	Identifiants de Service Principal. `tenantID` est aussi apposé sur la SA Workload Identity comme `azure.workload.identity/tenant-id`
`hashicorpVault`	object	Connexion HashiCorp Vault — voir `hashicorpVault`
`providerConfig`	object	Bloc `spec.provider` ESO brut (provider `raw`)
`refreshInterval`	duration	Par défaut `1h`
`externalSecrets`	list	Les Secrets à matérialiser

`hashicorpVault`

Champ	Type	Description
`server`	string (requis)	Adresse de Vault, p. ex. `https://vault.example.internal:8200`
`path`	string	Point de montage KV, par défaut `secret`
`version`	enum `v2` (par défaut) \| `v1`	Version du moteur KV
`namespace`	string	Namespace Vault Enterprise (p. ex. `team-a`) ; vide pour Vault open source
`caSecretRef`	`{ name, key }`	Secret contenant le certificat PEM de la CA qui a signé le certificat TLS de Vault (clé par défaut `ca.crt`) — nécessaire lorsque Vault utilise une CA privée, la norme on-prem
`auth`	object (requis)	Exactement une des trois méthodes ci-dessous
`auth.kubernetes`	`{ role, mountPath, serviceAccountName }`	Authentification Kubernetes de Vault (recommandée dans le cluster). Le rôle Vault est lié à `serviceAccountName` ; l'opérateur crée cette ServiceAccount si elle est absente (une ServiceAccount existante est utilisée sans modification). Vide ⇒ la ServiceAccount propre à ESO. `mountPath` par défaut `kubernetes`
`auth.appRole`	`{ path, roleId, secretIdSecretRef }`	Authentification AppRole de Vault (courante on-prem) : l'ID de rôle plus un Secret contenant le secret ID (clé par défaut `secret-id`). `path` par défaut `approle`
`auth.tokenSecretRef`	`{ name, key }`	Un Secret contenant un token Vault (clé par défaut `token`). Les tokens expirent — préférez les méthodes ci-dessus

Avec Vault, chaque entrée de keys associe une clé du Secret Kubernetes à un chemin de secret sous le point de montage ; la clé Kubernetes est aussi le champ lu dans ce secret Vault (OPENAI_API_KEY: navique/models lit le champ OPENAI_API_KEY de secret/navique/models).

Le côté Vault — une policy en lecture seule sur le point de montage et le rôle de votre méthode d'authentification — est configuré une seule fois par votre administrateur Vault ; la console de gestion génère les commandes exactes correspondant à vos paramètres.

`externalSecrets[]`

Champ	Description
`name`	Nom du Secret Kubernetes cible
`keys`	Mapping raccourci `{ k8sKey: remoteSecretName }`
`data`	Forme `remoteRef` ESO complète (`secretKey`, `remoteKey`, `property`, `version`) pour les providers où property/version ont une importance
`findRegexp`	`dataFrom.find` en masse par expression régulière

`sealedSecrets`

Champ	Description
`controllerNamespace`	Emplacement du contrôleur Sealed Secrets ; par défaut ce namespace

Exemples

ESO — Azure Key Vault via Workload Identity (valeur par défaut en production)

yaml

apiVersion: core.navique.com/v1alpha1
kind: SecretsManagement
metadata:
  name: forge-secrets
  namespace: forge-gateway
spec:
  backend: eso
  eso:
    vaultURL: https://kvforgepltprod.vault.azure.net/
    serviceAccountName: forge-sa   # créée par l'opérateur si absente (sinon adoptée)
    clientID: 11111111-2222-3333-4444-555555555555  # client ID de l'identité managée (annotation SA)
    refreshInterval: 1h
    externalSecrets:
      - name: model-credentials
        keys:
          OPENAI_API_KEY: gateway-foundry-api-key
          ANTHROPIC_API_KEY: gateway-foundry-api-key

ESO — Service Principal (hors AKS / Kind)

yaml

spec:
  backend: eso
  eso:
    vaultURL: https://kv.vault.azure.net/
    authType: ServicePrincipal
    tenantID: <tenant-guid>
    authSecretRef:
      clientID:     { name: azure-sp, key: client-id }
      clientSecret: { name: azure-sp, key: client-secret }

ESO — HashiCorp Vault on-prem (authentification Kubernetes, CA privée)

yaml

spec:
  backend: eso
  eso:
    provider: hashicorpVault
    hashicorpVault:
      server: https://vault.example.internal:8200
      namespace: team-a            # Vault Enterprise uniquement
      caSecretRef: { name: vault-ca }
      auth:
        kubernetes: { role: navique, serviceAccountName: navique-vault }
    externalSecrets:
      - name: model-credentials
        keys: { OPENAI_API_KEY: navique/models }

ESO — HashiCorp Vault avec AppRole

yaml

spec:
  backend: eso
  eso:
    provider: hashicorpVault
    hashicorpVault:
      server: https://vault.example.internal:8200
      caSecretRef: { name: vault-ca }
      auth:
        appRole:
          roleId: 0f3c…                                 # pas un secret
          secretIdSecretRef: { name: vault-approle }    # clé secret-id
    externalSecrets:
      - name: model-credentials
        keys: { OPENAI_API_KEY: navique/models }

ESO — HashiCorp Vault avec un token (dev / hermétique)

yaml

spec:
  backend: eso
  eso:
    provider: hashicorpVault
    hashicorpVault:
      server: http://vault.vault.svc:8200
      auth:
        tokenSecretRef: { name: vault-token, key: token }
    externalSecrets:
      - name: model-credentials
        keys: { OPENAI_API_KEY: model-credentials }

ESO — n'importe quel provider (passthrough brut)

provider: raw injecte le bloc spec.provider ESO tel quel, de sorte que tous les providers ESO fonctionnent (AWS, GCP, IBM, Akeyless, 1Password, …) sans modification de l'opérateur :

yaml

spec:
  backend: eso
  eso:
    provider: raw
    providerConfig:
      aws:
        service: SecretsManager
        region: eu-central-1
        auth: { jwt: { serviceAccountRef: { name: forge-sa } } }
    externalSecrets:
      - name: model-credentials
        data:
          - { secretKey: OPENAI_API_KEY, remoteKey: prod/model, property: openai, version: AWSCURRENT }

Sealed Secrets

yaml

spec:
  backend: sealedSecrets
  sealedSecrets:
    controllerNamespace: sealed-secrets

Comportement

ESO ⇒ l'opérateur garantit la présence de l'External Secrets Operator (de manière Provenance-aware), attend que ses CRDs soient Established, puis applique un SecretStore namespaced et les ExternalSecrets configurés. Un store namespaced (et non un ClusterSecretStore) maintient l'isolation des identifiants de chaque namespace.
Sealed Secrets ⇒ l'opérateur garantit la présence du contrôleur Sealed Secrets et réconcilie les SealedSecrets référencés.

Les workloads qui renseignent secretsRef ne se réconcilient qu'une fois ce SecretsManagement prêt.

Status

{ phase, backend, storeReady, materializedSecrets[], conditions, observedGeneration }.

Pour chaque backend ESO, conditions porte SecretStoreReady : ESO peut-il joindre le magasin de secrets et s'y authentifier ? Lorsque ESO signale que ce n'est pas le cas, la condition — et Ready, puisque rien ne peut être synchronisé — passe à False avec la cause remontée par ESO, p. ex. x509: certificate signed by unknown authority (renseignez caSecretRef), permission denied (vérifiez le rôle et la policy Vault) ou un namespace Vault erroné.

Pour un backend Azure Key Vault + WorkloadIdentity, conditions porte aussi FederatedCredentialReady — le signal passif indiquant si la federated identity credential Azure existe pour le subject du ServiceAccount ESO. Voir Exploitation des secrets → la federated credential.

SecretsManagement ​

Spec ​

eso ​

hashicorpVault ​

externalSecrets[] ​

sealedSecrets ​

Exemples ​

ESO — Azure Key Vault via Workload Identity (valeur par défaut en production) ​

ESO — Service Principal (hors AKS / Kind) ​

ESO — HashiCorp Vault on-prem (authentification Kubernetes, CA privée) ​

ESO — HashiCorp Vault avec AppRole ​

ESO — HashiCorp Vault avec un token (dev / hermétique) ​

ESO — n'importe quel provider (passthrough brut) ​

Sealed Secrets ​

Comportement ​

Status ​

SecretsManagement

Spec

`eso`

`hashicorpVault`

`externalSecrets[]`

`sealedSecrets`

Exemples

ESO — Azure Key Vault via Workload Identity (valeur par défaut en production)

ESO — Service Principal (hors AKS / Kind)

ESO — HashiCorp Vault on-prem (authentification Kubernetes, CA privée)

ESO — HashiCorp Vault avec AppRole

ESO — HashiCorp Vault avec un token (dev / hermétique)

ESO — n'importe quel provider (passthrough brut)

Sealed Secrets

Comportement

Status