Zum Hauptinhalt springen

External Secrets

External Secrets Operator (ESO) ist ein Kubernetes-Operator, der entwickelt wurde, um sich in verschiedene externe Secret-Managementsysteme wie AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, IBM Cloud Secrets Manager und CyberArk Conjur zu integrieren. Dieser Operator ruft Informationen von externen APIs ab und injiziert die Werte automatisch in Kubernetes Secrets.

Verfügbarkeit​

External Secrets ist als optionaler Dienst für NKE verfügbar. Es kann auf einem bestehenden NKE-Cluster über Cockpit oder die Nine Self Service API bereitgestellt werden.

Überblick​

ESO besteht aus benutzerdefinierten API-Ressourcen: ExternalSecret, SecretStore und ClusterSecretStore, die eine benutzerfreundliche Abstraktion für die Verwaltung und Synchronisierung von Secrets über externe APIs bieten. Der SecretStore verweist auf eine Sammlung von Key/Value-Paaren, die verschiedenen externen APIs entsprechen können, wie einer Azure KeyVault-Instanz oder einem AWS Secrets Manager in einem bestimmten AWS-Konto und einer bestimmten Region. Ein ExternalSecret definiert die abzurufenden Daten und dient auch als Vorlage für die Erstellung von Kubernetes Secrets. Das Ressourcenmodell kann wie folgt visualisiert werden:

SecretStore​

Die Ressource SecretStore soll zwischen Authentication/Access-Problemen und den eigentlichen Secret und Konfigurationen, die für Workloads benötigt werden, unterscheiden. Das ExternalSecret definiert, welche Daten abgerufen werden sollen, während der SecretStore angibt, wie auf diese Daten zugegriffen werden soll. Der SecretStore enthält Verweise auf Anmeldeinformationen, die erforderlich sind, um auf die externe API zuzugreifen. Diese Ressource ist Namespace-basiert.

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: secretstore-sample
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-central-2
      auth:
        secretRef:
          accessKeyIDSecretRef:
            name: awssm-secret
            key: access-key
          secretAccessKeySecretRef:
            name: awssm-secret
            key: secret-access-key

ExternalSecret​

Ein ExternalSecret spezifiziert die abzurufenden Daten und enthält einen Verweis auf einen SecretStore, der weiss, wie auf die Daten zugegriffen werden kann. Der Controller verwendet das ExternalSecret als Vorlage zur Erstellung des Kubernetes Secret.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: example
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: secretstore-sample
    kind: SecretStore
  target:
    name: secret-to-be-created
    creationPolicy: Owner
  data:
    - secretKey: secret-key-to-be-managed
      remoteRef:
        key: mymap
        property: foo
  # Oder verwenden Sie `dataFrom`, um alle Key-Properties automatisch auf das K8s-Secret abzubilden.
  dataFrom:
    - extract:
        key: mymap

ClusterSecretStore​

Der ClusterSecretStore ist ein cluster-weiter SecretStore, der von jedem Namespace aus referenziert werden kann. Er fungiert als zentrales Gateway zum Secret-Anbieter für den gesamten Cluster.

Verwendung​

Die Implementierungsdetails und der Umfang der unterstützten Funktionen variieren je nach ausgewähltem Backend-Anbieter. Für eine umfassende Liste der derzeit unterstützten Anbieter, einen Überblick über die Funktionsunterstützung bei verschiedenen Anbietern und fortgeschrittene Beispiele lesen Sie bitte die Stabilitäts- und Unterstützungsdokumentation.

Beispiel für HashiCorp Vault Provider​

External Secrets Operator integriert sich mit HashiCorp Vault für das Secret-Management. Die KV Secrets Engine ist die einzige, die von diesem Anbieter unterstützt wird.

Erstellen Sie zuerst einen SecretStore mit einem Vault-Backend. Der Einfachheit halber verwenden wir ein statisches Token root:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "http://my.vault.server:8200"
      path: "secret"
      # Version ist die Vault KV secret engine Version.
      # Dies kann entweder "v1" oder "v2" sein, Standard ist "v2"
      version: "v2"
      auth:
        # verweist auf ein Secret, das ein Vault-Token enthält
        # https://www.vaultproject.io/docs/auth/token
        tokenSecretRef:
          name: "vault-token"
          key: "token"
---
apiVersion: v1
kind: Secret
metadata:
  name: vault-token
data:
  token: cm9vdA== # "root"
note

Im Falle eines ClusterSecretStore, stellen Sie sicher, dass Sie namespace für tokenSecretRef mit dem Namespace des gerade erstellten Secrets angeben.

Erstellen Sie dann ein einfaches Key/Value-Paar unter dem Pfad secret/foo:

vault kv put secret/foo my-value=s3cr3t

Sie können die kv-Version mit dem folgenden Befehl überprüfen und die Spalte Options überprüfen. Sie sollte [version:2] anzeigen:

vault secrets list -detailed

Wenn Sie Version 1 verwenden, denken Sie daran, Ihr SecretStore-Manifest entsprechend zu aktualisieren.

Erstellen Sie nun ein ExternalSecret, das den obigen SecretStore verwendet:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: vault-example
spec:
  refreshInterval: "15s"
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: example-sync
  data:
    - secretKey: foobar
      remoteRef:
        key: foo
        property: my-value

---
# erstellt ein Secret mit:
kind: Secret
metadata:
  name: example-sync
data:
  foobar: czNjcjN0

Für zusätzliche HashiCorp Vault-Beispiele und fortgeschrittene Nutzungshinweise lesen Sie bitte die offizielle Provider-Dokumentation.