Sichere Verwaltung von Geheimnissen in Kubernetes mit 1Password

Die sichere Verwaltung von Geheimnissen in Kubernetes ist eine entscheidende Herausforderung für moderne Cloud-native Umgebungen. Anmeldedaten für Anwendungen, Zertifikate, private Schlüssel und Passwörter müssen auf eine Weise verwaltet werden, die sicher, nachvollziehbar und betrieblich flexibel ist – insbesondere wenn eine regelmäßige Rotation erforderlich ist.

Durch die Integration von 1Password mit Kubernetes mithilfe des External Secrets Operator (ESO)können Teams die Verwaltung vertraulicher Daten zentralisieren und gleichzeitig sicherstellen, dass sensible Daten nicht in Git-Repositorys und Kubernetes-Manifesten gespeichert werden.

Dieser Ansatz ermöglicht es Kubernetes-Workloads, Geheimnisse sicher zu nutzen und gleichzeitig strenge Zugriffskontrollen und Rotationsverfahren einzuhalten.

Architekturübersicht: 1Password + Kubernetes

Die Integration von 1Password in Kubernetes funktioniert durch die Einführung einer Abstraktionsschicht zwischen Kubernetes und der 1Password-Cloud-API.

Anstatt dass Kubernetes direkt mit dem Cloud-Dienst von 1Password kommuniziert, läuft innerhalb des Clusters ein 1Password Connect Server. Diese Architektur bietet mehr Sicherheit, höhere Leistung und bessere Kontrolle.

Der Ablauf sieht wie folgt aus:

1. Kubernetes kommuniziert mit dem External Secrets Operator
2. Die ESO kommuniziert mit dem 1Password Connect Server innerhalb des Clusters
3. Der Connect-Server authentifiziert sich bei 1Password mithilfe eines Tokens
4. Die angeforderten Geheimnisse werden abgerufen und an Kubernetes zurückgegeben

Diese Architektur ermöglicht die sichere Synchronisierung von Geheimnissen in Kubernetes-native Secret-Objekte.

Schritt 1: Installieren Sie den „External Secrets Operator“ und konfigurieren Sie den „ClusterSecretStore“

Zunächst müssen Sie den External Secrets Operator in Ihrem Kubernetes-Cluster installieren. Der ESO stellt die Custom Resource Definitions (CRDs) bereit, die erforderlich sind, um festzulegen, wie Kubernetes eine Verbindung zu externen Secret-Anbietern herstellt.

Das wichtigste CRD in dieser Konfiguration ist der „ClusterSecretStore“. Dabei handelt es sich um eine clusterweite Ressource, die festlegt, wie Kubernetes die Authentifizierung durchführt und mit 1Password kommuniziert.

Beispielkonfiguration:

kubectl get ClusterSecretStore/ie-onepassword -o yaml
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
spec:
  conditions:
  - namespaceSelector:
      matchLabels:
        bango.com/dept: Engineering
  provider:
    onepassword:
      auth:
        secretRef:
          connectTokenSecretRef:
            key: token
            name: onepassword-connect-token-ie
            namespace: ns-dev-external-secrets
      connectHost: http://onepassword-connect.ns-dev-1password-connect-server.svc.cluster.local:8080
      vaults:
        Engineering DevTest: 1

Diese Konfiguration weist ESO an, statt mit der öffentlichen 1Password-API mit dem 1Password Connect-Server zu kommunizieren. Der Connect-Pod authentifiziert sich mithilfe eines Tokens und ruft Geheimnisse aus dem angegebenen Tresor ab.

Schritt 2: „ExternalSecret“-Ressourcen für Anwendungen erstellen

Um Geheimnisse innerhalb einer Anwendung zu nutzen – beispielsweise bei einem Dienst, der sich mithilfe eines Client-Zertifikats bei einem Remote-Endpunkt authentifiziert –, müssen Sie eine „ExternalSecret“-Ressource definieren.

Beispiel:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  labels:
    env: dev
  name: dev-cert-external-secrets-even
  namespace: ns-dev-engineering-korek
spec:
  data:
  - remoteRef:
      key: CERT Engineering|endpoint|Cert|dev 20260626
      property: endpoint_dev_CERT_PUBLIC.pem
    secretKey: CERT_PEM
  - remoteRef:
      key: CERT Engineering|endpoint|Key|dev 20260626
      property: endpoint_dev_KEY.key
    secretKey: CERT_PRIVKEY
  target:
    name: dev-external-secrets-even
    creationPolicy: Owner
    deletionPolicy: Retain

Erläuterung der wichtigsten Begriffe

• remoteRef.property gibt den genauen Eintrag in 1Password an, der abgerufen werden soll.
• Anwendungen dürfen nicht direkt auf „ExternalSecret “-Objekte verweisen.
• Die target In diesem Abschnitt wird das Kubernetes-Secret definiert, das ESO erstellt und synchronisiert.

Dieses Zielgeheimnis wird letztendlich von den Anwendungen genutzt.

Unterstützung der Zertifikatsrotation mit geraden/ungeraden Geheimnissen

Um eine sichere Zertifikats- und Schlüsselrotation zu gewährleisten, wird empfohlen, zwei „ExternalSecrets“ zu verwalten:

• dev-externe-Geheimnisse-sogar
• dev-external-secrets-odd

Dieser Ansatz ermöglicht:

• Nahtlose Zertifikatsrotation
• Updates ohne Ausfallzeiten
• Einfaches Zurücksetzen durch Wechseln der Referenzen

Wenn sich ein Rotationszyklus nähert, können neue Zertifikate zu 1Password hinzugefügt und mit dem inaktiven „ExternalSecret“ synchronisiert werden, ohne dass dies Auswirkungen auf die laufende Anwendung hat.

Erläuterung von „creationPolicy“ und „deletionPolicy“

Zwei Bereiche erfordern besondere Aufmerksamkeit:

creationPolicy: Eigentümer

• ESO erstellt das Kubernetes-Secret, falls es noch nicht vorhanden ist.
• ESO aktualisiert den „Secret“, sobald sich der externe Wert ändert
• Durch das Löschen des „ExternalSecret“ wird das Ziel-Secret gelöscht.

Alternativ kann „Merge“ verwendet werden, wenn mehrere Controller dasselbe Secret verwalten.

Löschrichtlinie: Aufbewahren

• Wenn ein Secret versehentlich aus 1Password gelöscht wird, bleibt das Kubernetes-Secret bestehen
• Verhindert unbeabsichtigte Ausfälle aufgrund menschlicher Fehler
• Empfohlen für Produktions-Workloads

Schritt 3: Überprüfung des Zustands von „ExternalSecret“

Ein fehlerfreies und synchronisiertes „ExternalSecret“ sieht wie folgt aus:

kubectl -n ns-dev-app get externalsecret
NAME                             STORETYPE            STORE            REFRESH INTERVAL   STATUS         READY
dev-app-external-secrets-even    ClusterSecretStore   ie-onepassword   5m                SecretSynced   True
dev-app-external-secrets-odd     ClusterSecretStore   ie-onepassword   5m                SecretSynced   True

Durch die Aktualisierung von Geheimnissen in 1Password wird das entsprechende Kubernetes-Geheimnis automatisch aktualisiert, ohne dass es zu Unterbrechungen im Betrieb der Anwendung kommt.

Schritt 4: Mehrere Secrets mithilfe von projizierten Volumes einbinden

Um beide Zertifikatssätze im selben Verzeichnis innerhalb eines Containers verfügbar zu machen, können Sie ein projiziertes Volume verwenden. Auf diese Weise lassen sich mehrere Secrets unter einem einzigen Pfad einbinden.

Beispiel unter Verwendung von Flux und Kustomize:

patch: |-
- op: add
  path: "/spec/template/spec/volumes/-"
  value:
    name: app-keystore-cert
    projected:
      sources:
      - secret:
          name: dev-app-external-secrets-odd
          items:
          - key: TEST_PEM
            path: app_keystore-odd.pem
          - key: TEST_PRIVKEY
            path: app_keystore-private-odd.pem
      - secret:
          name: dev-app-external-secrets-even
          items:
          - key: TEST_PEM
            path: app_keystore-even.pem
          - key: TEST_PRIVKEY
            path: app_keystore-private-even.pem

Der letzte Schritt besteht lediglich darin, die Anwendung so zu konfigurieren, dass sie auf die entsprechende Datei innerhalb des Containers verweist.

Abschließende Überlegungen

Die Nutzung von 1Password mit Kubernetes über den „External Secrets Operator“ bietet einen sicheren, flexiblen und produktionsreifen Ansatz für die Verwaltung von Geheimnissen.

Diese Konfiguration ermöglicht Folgendes:

• Zentralisierte Speicherung von Geheimnissen
• Sichere Zertifikatsrotation
• Geringerer Explosionsradius aufgrund menschlicher Fehler
• Kubernetes-native Nutzung von Secrets

Für Teams, die in großem Maßstab arbeiten, verbessert dieser Ansatz sowohl die Sicherheitslage als auch die Betriebssicherheit erheblich.

Weitere Blogbeiträge findest duhier.