External Secrets Operator verwenden

Auf dieser Seite wird beschrieben, wie Sie den External Secrets Operator (ESO) verwenden, um Secrets aus Secret Manager mit Ihren mit Google Distributed Cloud Connected verbundenen Clustern zu synchronisieren.

External Secrets Operator ist ein Open-Source-Kubernetes-Operator, der externe Secret-Verwaltungssysteme einbindet. Der Operator liest Informationen aus externen APIs und fügt die Werte automatisch in ein Kubernetes-Secret ein.

Vorbereitung

Bevor Sie External Secrets Operator verwenden können, müssen Sie Folgendes tun:

  • Erstellen Sie einen funktionalen Distributed Cloud Connected-Cluster.
  • Prüfen Sie, ob die folgenden APIs in Ihrem Projekt Google Cloud aktiviert sind. Informationen zum Aktivieren von APIs finden Sie unter Dienste aktivieren:
    • secretmanager.googleapis.com
    • iamcredentials.googleapis.com

  • Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:

    • Die neueste Version der Google Cloud CLI, die gcloud, das Befehlszeilentool für die Interaktion mit Google Cloud, enthält.
    • kubectl

    Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mitGoogle Cloudverwenden, sind diese Tools für Sie installiert.

  • Achten Sie darauf, dass die gcloud CLI für die Verwendung mit Ihrem Projekt initialisiert wurde.

  • Aktivieren Sie Workload Identity Federation im Cluster. Der Workload Identity-Pool ist automatisch verfügbar und hat das Format PROJECT_ID.svc.id.goog.

  • Installieren Sie den External Secrets Operator in Ihrem Cluster. Eine Installationsanleitung finden Sie in der Dokumentation zum External Secrets Operator. Wir empfehlen, den Operator in einem dedizierten Namespace wie external-secrets zu installieren. Installieren Sie sie nicht in vom System verwalteten Namespaces wie kube-system oder gke-system.

Distributed Cloud-Cluster werden automatisch in einer Flotte in dem Projekt registriert, in dem sie erstellt werden.

Authentifizierung

Für den Zugriff auf Secret Manager ist eine Authentifizierung für den External Secrets Operator erforderlich. Distributed Cloud Connected verwendet die Workload Identity-Föderation der Flotte, damit sich Arbeitslasten beiGoogle Cloud -APIs authentifizieren können.

So konfigurieren Sie die Authentifizierung für External Secrets Operator:

  1. Richten Sie die Vertrauensstellung zwischen Ihrem Cluster und Google Cloud ein, indem Sie der Anleitung unter Workload Identity-Clusterauthentifizierung folgen.

  2. Weisen Sie dem Kubernetes-Dienstkonto, das vom External Secrets Operator verwendet wird, die Rolle „Zugriffsperson für Secret Manager-Secret“ (roles/secretmanager.secretAccessor) für das Secret zu:

    gcloud secrets add-iam-policy-binding SECRET_NAME \
    --project=PROJECT_ID \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/OPERATOR_NAMESPACE/sa/KUBERNETES_SERVICEACCOUNT" \
    --role="roles/secretmanager.secretAccessor" \
    --condition=None

    Ersetzen Sie die folgenden Werte:

    • SECRET_NAME: Der Name des Secrets im Secret Manager.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID
    • PROJECT_NUMBER: Ihre numerische Google CloudProjektnummer
    • OPERATOR_NAMESPACE: der Namespace, in dem Sie den Operator installiert haben
    • KUBERNETES_SERVICEACCOUNT: der Name des Kubernetes-Dienstkontos, das vom Operator verwendet wird

  3. Konfigurieren Sie den External Secrets Operator-Pod für die Verwendung der Workload Identity-Föderation und stellen Sie die Konfigurationsdatei für Anmeldedaten für den Operator-Pod bereit, indem Sie der Anleitung unter Arbeitslast konfigurieren folgen.

ESO-Ressourcen zum Synchronisieren von Secrets erstellen

Nachdem Sie die Authentifizierung konfiguriert haben, können Sie External Secrets Operator-Ressourcen erstellen, um Secrets zu synchronisieren.

SecretStore erstellen

Ein SecretStore gibt an, wie auf das externe Secret-Verwaltungssystem zugegriffen wird. Sie können SecretStore-Ressourcen im selben Namespace wie External Secrets Operator oder in Anwendungs-Namespaces erstellen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter SecretStore.

  1. Erstellen Sie eine Datei mit dem Namen secret-store.yaml und dem folgendem Inhalt:

    apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gcp-store
  namespace: NAMESPACE
spec:
  provider:
    gcpsm:
      projectID: PROJECT_ID

    Ersetzen Sie die folgenden Werte:

    • NAMESPACE: der Namespace, in dem Sie die SecretStore erstellen möchten
    • PROJECT_ID: Ihre Google Cloud Projekt-ID, in der Secrets gespeichert sind

  2. Wenden Sie das Manifest mit dem Befehl kubectl apply an:

    kubectl apply -f secret-store.yaml

ClusterSecretStore erstellen

Ein ClusterSecretStore ist eine clusterbezogene Ressource, die von ExternalSecret-Ressourcen in jedem Namespace verwendet werden kann. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter ClusterSecretStore.

  1. Erstellen Sie eine Datei mit dem Namen cluster-secret-store.yaml und dem folgendem Inhalt:

    apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: gcp-cluster-store
spec:
  provider:
    gcpsm:
      projectID: PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID Ihres Projekts in Google Cloud , in dem die Secrets gespeichert sind.

  2. Wenden Sie das Manifest an:

    kubectl apply -f cluster-secret-store.yaml

ExternalSecret erstellen

In einem ExternalSecret wird deklariert, welche Daten abgerufen und wo sie im Cluster gespeichert werden sollen. Erstellen Sie ExternalSecret-Ressourcen im Namespace, in dem die Anwendungs-Pods das resultierende Kubernetes Secret verwenden. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter ExternalSecret.

  1. Erstellen Sie eine Datei mit dem Namen external-secret.yaml und dem folgendem Inhalt:

    apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: EXTERNAL_SECRET
  namespace: NAMESPACE
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: gcp-store
  target:
    name: K8S_SECRET_NAME
    creationPolicy: Owner
  data:
  - secretKey: K8S_SECRET_KEY
    remoteRef:
      key: SECRET_NAME

    Ersetzen Sie die folgenden Werte:

    • EXTERNAL_SECRET ist der Name der ExternalSecret-Ressource.
    • NAMESPACE: der Namespace, in dem Sie den SecretStore erstellt haben.
    • K8S_SECRET_NAME: Der Name des Kubernetes-Secrets, das von ESO erstellt werden soll.
    • K8S_SECRET_KEY: der Schlüssel in den Kubernetes-Secret-Daten.
    • SECRET_NAME: Der Name des Secrets imGoogle Cloud Secret Manager.

    Wenn Sie ClusterSecretStore verwenden, legen Sie kind: ClusterSecretStore fest und aktualisieren Sie name in secretStoreRef.

  2. Wenden Sie das Manifest an:

    kubectl apply -f external-secret.yaml

Mehrere Schlüssel aus einem JSON-Secret synchronisieren

Wenn Ihr Secret in Secret Manager einen JSON-String enthält, können Sie alle Schlüssel als einzelne Einträge im Kubernetes-Secret extrahieren.

  1. Erstellen Sie eine Datei mit dem Namen external-secret-json.yaml und dem folgendem Inhalt:

    apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: EXTERNAL_SECRET
  namespace: NAMESPACE
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: gcp-store
  target:
    name: K8S_SECRET_NAME
    creationPolicy: Owner
  dataFrom:
  - extract:
      key: SECRET_NAME

  2. Wenden Sie das Manifest an:

    kubectl apply -f external-secret-json.yaml

Jedes Schlüssel/Wert-Paar im JSON-Secret wird einem Schlüssel/Wert-Paar im resultierenden Kubernetes-Secret zugeordnet.

Fehlerbehebung

Wenn Ihre vertraulichen Daten nicht synchronisiert werden, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

  1. Prüfen Sie mit dem Befehl kubectl get den Status der ExternalSecret-Ressource:

    kubectl get externalsecret EXTERNAL_SECRET -n NAMESPACE -o yaml

    Sehen Sie sich den Abschnitt status an, um nach Fehlermeldungen oder fehlgeschlagenen Bedingungen zu suchen.

  2. Mit dem Befehl kubectl logs können Sie die Logs des Controller-Pods des External Secrets Operator aufrufen:

    kubectl logs -l app.kubernetes.io/name=external-secrets -n OPERATOR_NAMESPACE

  3. Prüfen Sie, ob das vom Operator verwendete Kubernetes-Dienstkonto die Rolle „Secret Manager Secret Accessor“ (roles/secretmanager.secretAccessor) hat und ob die Identitätsföderation von Arbeitslasten für den Operator-Pod richtig konfiguriert ist. Weitere Informationen finden Sie unter Identitätsföderation von Arbeitslasten im Cluster.

Nächste Schritte