SecretsManagement

Geltungsbereich: namespaced · Erforderlich für jeden Workload

Wählt das Anmeldedaten-Backend für einen Namespace aus. Workloads im selben Namespace können es über secretsRef binden und die Namen der materialisierten Secrets referenzieren; ein Workload ohne secretsRef verwendet stattdessen Secrets, die Sie selbst anlegen. Ein Backend pro Ressource. Zum vollständigen Secrets-Modell, den Providern und der Key-Vault-Matrix siehe Secrets Management.

Spec

Feld	Typ	Beschreibung
backend	enum eso | sealedSecrets (erforderlich)	Das Anmeldedaten-Backend
eso	object	ESO-Konfiguration (bei backend: eso)
sealedSecrets	object	Sealed-Secrets-Konfiguration (bei backend: sealedSecrets)

eso

Feld	Typ	Beschreibung
provider	enum azureKeyVault (Standard) | hashicorpVault | raw	Der ESO-SecretStore-Provider
vaultURL	string	Azure-Key-Vault-URL (azureKeyVault-Provider)
authType	enum WorkloadIdentity (Standard) | ServicePrincipal	Azure-Authentifizierungsmethode
serviceAccountName	string	SA, als die sich ESO authentifiziert (Workload Identity). Der Operator erstellt diese ServiceAccount, falls sie fehlt (im Besitz der CR, aus clientID/tenantID annotiert); eine bereits vorhandene SA wird unverändert übernommen
clientID	string	Client-ID der benutzerseitig zugewiesenen Azure Managed Identity. Wird als azure.workload.identity/client-id auf die erstellte SA gesetzt und von ESO gelesen, um das SA-Token zu tauschen. Für Workload Identity erforderlich, sofern Sie die SA nicht selbst mit dieser Annotation anlegen
tenantID / authSecretRef	string / refs	Service-Principal-Anmeldedaten. tenantID wird zusätzlich als azure.workload.identity/tenant-id auf die Workload-Identity-SA gesetzt
hashicorpVault	object	HashiCorp-Vault-Verbindung — siehe hashicorpVault
providerConfig	object	Roher ESO-spec.provider-Block (Provider raw)
refreshInterval	duration	Standard 1h
externalSecrets	list	Die zu materialisierenden Secrets

hashicorpVault

Feld	Typ	Beschreibung
server	string (erforderlich)	Vault-Adresse, z. B. https://vault.example.internal:8200
path	string	KV-Mount, Standard secret
version	enum v2 (Standard) | v1	Version der KV-Engine
namespace	string	Vault-Enterprise-Namespace (z. B. team-a); leer für Open-Source-Vault
caSecretRef	{ name, key }	Secret mit dem PEM-Zertifikat der CA, die Vaults TLS-Zertifikat signiert hat (Schlüssel standardmäßig ca.crt) — nötig, wenn Vault eine private CA verwendet, wie on-prem üblich
auth	object (erforderlich)	Genau eine der drei folgenden Methoden
auth.kubernetes	{ role, mountPath, serviceAccountName }	Vault-Kubernetes-Authentifizierung (im Cluster empfohlen). Die Vault-Rolle ist an serviceAccountName gebunden; der Operator erstellt diese ServiceAccount, falls sie fehlt (eine vorhandene wird unverändert verwendet). Leer ⇒ die eigene ServiceAccount von ESO. mountPath standardmäßig kubernetes
auth.appRole	{ path, roleId, secretIdSecretRef }	Vault-AppRole-Authentifizierung (on-prem verbreitet): die Rollen-ID plus ein Secret mit der Secret-ID (Schlüssel standardmäßig secret-id). path standardmäßig approle
auth.tokenSecretRef	{ name, key }	Ein Secret mit einem Vault-Token (Schlüssel standardmäßig token). Tokens laufen ab — bevorzugen Sie die obigen Methoden

Bei Vault ordnet jeder keys-Eintrag einen Schlüssel des Kubernetes-Secrets einem Secret-Pfad unterhalb des Mounts zu; der Kubernetes-Schlüssel ist zugleich das Feld, das aus diesem Vault-Secret gelesen wird (OPENAI_API_KEY: navique/models liest das Feld OPENAI_API_KEY aus secret/navique/models).

Die Vault-Seite — eine Nur-Lese-Policy auf den Mount und die Rolle für Ihre Authentifizierungsmethode — richtet Ihr Vault-Administrator einmalig ein; die Management-Konsole erzeugt die genauen Befehle für Ihre Einstellungen.

externalSecrets[]

Feld	Beschreibung
name	Name des Ziel-Kubernetes-Secrets
keys	{ k8sKey: remoteSecretName }-Kurzschreibweise für die Zuordnung
data	Vollständige ESO-remoteRef-Form (secretKey, remoteKey, property, version) für Provider, bei denen property/version relevant sind
findRegexp	Massenabruf dataFrom.find per Regexp

sealedSecrets

Feld	Beschreibung
controllerNamespace	Wo der Sealed-Secrets-Controller liegt; standardmäßig dieser Namespace

Beispiele

ESO — Azure Key Vault über Workload Identity (Produktionsstandard)

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   # vom Operator erstellt, falls fehlend (sonst übernommen)
    clientID: 11111111-2222-3333-4444-555555555555  # Client-ID der Managed Identity (SA-Annotation)
    refreshInterval: 1h
    externalSecrets:
      - name: model-credentials
        keys:
          OPENAI_API_KEY: gateway-foundry-api-key
          ANTHROPIC_API_KEY: gateway-foundry-api-key

ESO — Service Principal (Nicht-AKS / Kind)

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 (Kubernetes-Authentifizierung, private CA)

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

ESO — HashiCorp Vault mit AppRole

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

ESO — HashiCorp Vault mit einem Token (Entwicklung / hermetisch)

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 — beliebiger Provider (Raw-Durchreichung)

provider: raw injiziert den ESO-spec.provider-Block wortgetreu, sodass jeder ESO-Provider funktioniert (AWS, GCP, IBM, Akeyless, 1Password, …) ohne Änderungen am Operator:

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

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

Verhalten

• ESO ⇒ der Operator stellt den External Secrets Operator sicher (Provenance-bewusst), wartet darauf, dass dessen CRDs Established sind, und wendet anschließend einen namespaced SecretStore sowie die konfigurierten ExternalSecrets an. Ein namespaced Store (kein ClusterSecretStore) hält die Anmeldedaten jedes Namespace isoliert.
• Sealed Secrets ⇒ der Operator stellt den Sealed-Secrets-Controller sicher und reconciled die referenzierten SealedSecrets.

Workloads, die secretsRef setzen, reconcilen erst, sobald diese SecretsManagement bereit ist.

Status

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

Bei jedem ESO-Backend enthält conditions SecretStoreReady: ob ESO den Secret-Store erreichen und sich dort anmelden kann. Meldet ESO, dass das nicht möglich ist, sind die Condition — und Ready, da nichts synchronisiert werden kann — False mit der von ESO gemeldeten Ursache, z. B. x509: certificate signed by unknown authority (caSecretRef setzen), permission denied (Vault-Rolle und -Policy prüfen) oder ein falscher Vault-Namespace.

Bei einem Azure-Key-Vault-Backend mit WorkloadIdentity enthält conditions zusätzlich FederatedCredentialReady — das passive Signal dafür, ob die Azure Federated Identity Credential für das ESO-ServiceAccount-Subject existiert. Siehe Secrets-Betrieb → die Federated Credential.