Clustermetadaten schützen

Standard

---

Google Kubernetes Engine (GKE) verwendet Instanzmetadaten, um virtuelle Knotenmaschinen (VMs) zu konfigurieren. Einige dieser Metadaten sind jedoch möglicherweise vertraulich und sollten vor Arbeitslasten geschützt werden, die auf dem Cluster ausgeführt werden.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Knotendienstkonto konfigurieren

Die Dienstkonto-Anmeldedaten jedes Knotens sind weiterhin für Arbeitslasten verfügbar. Standardmäßig verwenden Ihre Knoten das Compute Engine-Standarddienstkonto. Sie sollten für Ihre Knoten ein Dienstkonto mit minimalen Berechtigungen konfigurieren, das anstelle des Standarddienstkontos der Compute Engine verwendet wird. Hängen Sie dann dieses Dienstkonto an Ihre Knoten an, damit ein Angreifer den GKE-Metadatenschutz nicht umgehen kann, indem er die Compute Engine API für den direkten Zugriff auf die zugrunde liegenden VM-Instanzen verwendet.

Weitere Informationen finden Sie unter Dienstkonten mit minimalen Berechtigungen verwenden.

Achtung: Verwenden Sie kein Dienstkonto mit der Berechtigung compute.instances.get, der Rolle Compute-Instanzadministrator oder ähnlichen Berechtigungen. Sie ermöglichen dadurch potenziellen Angreifern, Instanzmetadaten über die Compute Engine API abzurufen. Schränken Sie die Berechtigungen einer Knoten-VM ein. Verwenden Sie dazu Dienstkontoberechtigungen und keine Zugriffsbereiche. Weitere Informationen finden Sie unter Von Legacy-Zugriffsbereichen migrieren.

Führen Sie die folgenden Schritte aus, um ein Dienstkonto mit minimalen Berechtigungen zu erstellen:

1. Erstellen Sie ein neues IAM-Dienstkonto (Identity and Access Management) und speichern Sie die E-Mail-Adresse in einer Umgebungsvariablen:

   gcloud iam service-accounts create NODE_SA_NAME \
       --display-name="DISPLAY_NAME"
   export NODE_SA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
       --filter='displayName:DISPLAY_NAME')
   

   Dabei gilt:

   • NODE_SA_NAME ist der Name des neuen Knotendienstkontos.
   • DISPLAY_NAME: der Anzeigename des neuen Dienstkontos.

   Die E-Mail-Adresse des Knotendienstkontos hat das Format NODE_SA_NAME@PROJECT_ID.iam.gserviceaccount.com.

2. Konfigurieren Sie Ihr Dienstkonto mit den Mindestrollen und -berechtigungen, um Ihre GKE-Knoten auszuführen:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/monitoring.metricWriter
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/monitoring.viewer
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/logging.logWriter
   

   Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

   Wenn Ihr Cluster private Images aus Artifact Registry abruft, fügen Sie außerdem die Rolle roles/artifactregistry.reader hinzu:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/artifactregistry.reader
   

Metadatenverbergung

Warnung: Die Workload Identity Federation for GKE ersetzt die Notwendigkeit der Metadatenverbergung. Die beiden Ansätze sind nicht kompatibel. Wir empfehlen die Verwendung von Workload Identity Federation for GKE anstelle der Metadatenverbergung. Die Metadatenverbergung wird zu gegebener Zeit verworfen und entfernt.

Beta

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Die GKE-Metadatenverbergung schützt einige potenziell vertrauliche Systemmetadaten vor Nutzerarbeitslasten, die in Ihrem Cluster ausgeführt werden.

Sie können die Metadatenverbergung aktivieren, um zu verhindern, dass Nutzer-Pods auf bestimmte VM-Metadaten in Ihren Clusterknoten zugreifen, z. B. auf Kubelet-Anmeldedaten und VM-Instanzinformationen. Die Metadatenverbergung schützt insbesondere vor dem Zugriff auf kube-env, das Kubelet-Anmeldedaten enthält, sowie auf das Instanzidentitätstoken der VM.

Die Metadatenverbergung schirmt den Clustermetadatenserver mit einer Firewall vor Traffic von Nutzer-Pods ab. Diese Pods werden nicht auf HostNetwork ausgeführt. Dadurch sind nur sichere Abfragen möglich. Die Firewall verhindert, dass Nutzer-Pods Kubelet-Anmeldedaten für Berechtigungsausweitungsangriffe oder die VM-Identität für Instanzausweitungsangriffe verwenden.

Sie können die Metadatenverbergung nur aktivieren, wenn Sie einen neuen Cluster erstellen oder einem vorhandenen Cluster einen neuen Knotenpool hinzufügen.

Beschränkungen

• Die Metadatenverbergung schützt nur den Zugriff auf kube-env und die Instanzidentitätstoken des Knotens.
• Mit der Metadatenverbergung wird nicht der Zugriff auf das Dienstkonto des Knotens beschränkt.
• Mit der Metadatenverbergung wird nicht der Zugriff auf andere zugehörige Instanzmetadaten beschränkt.
• Mit der Metadatenverbergung wird nicht der Zugriff auf andere Legacy-Metadaten-APIs beschränkt.
• Mit der Metadatenverbergung wird nicht der Traffic von Pods beschränkt, die im Hostnetzwerk ausgeführt werden (hostNetwork: true in der Pod-Spezifikation).

Neuen Cluster oder Knotenpool mit Metadatenverbergung erstellen

Nachdem Sie ein Dienstkonto erstellt haben, können Sie mit dem Google Cloud CLI einen neuen Cluster oder Knotenpool mit aktivierter Metadatenverbergung erstellen.

Neuen Cluster erstellen

Führen Sie den folgenden Befehl aus, um einen Cluster mit aktivierter Metadatenverbergung zu erstellen:

gcloud beta container clusters create CLUSTER_NAME \
  --workload-metadata-from-node=SECURE \
  --service-account=$NODE_SA_EMAIL

Ersetzen Sie dabei CLUSTER_NAME durch den Namen des neuen Clusters.

Das Flag --workload-metadata-from-node hat folgende Werte:

• SECURE: Metadatenverbergung aktivieren.
• EXPOSED oder UNSPECIFIED: Metadatenverbergung deaktivieren.

Einen neuen Knotenpool erstellen

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit aktivierter Metadatenverbergung zu erstellen:

gcloud beta container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata-from-node=SECURE \
  --service-account=$NODE_SA_EMAIL

Ersetzen Sie NODE_POOL_NAME durch den Namen des neuen Knotenpools.

Metadaten eines Identitätstokens prüfen, die vor der Arbeitslast eines Clusters verborgen sind

Wenn Sie Metadaten verbergen, sollte es nicht möglich sein, über das Instanzidentitätstoken des Knotens eine Signatur anzufordern. So prüfen Sie, ob Nutzer bei Anfragen ausdrücklich über verborgene Metadaten informiert werden:

1. Öffnen Sie eine Shell-Sitzung in einem neuen Pod:

   kubectl run metadata-concealment -it --image=google/cloud-sdk:slim -- /bin/bash
   

2. Versuchen Sie im Pod, einen verborgenen Endpunkt abzurufen:

   curl -H "Metadata-Flavor: Google" \
   'http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://www.example.com'
   

   Die Ausgabe sieht in etwa so aus:

   This metadata endpoint is concealed.
   

Legacy-Metadaten-APIs deaktivieren und davon umstellen

Die Compute Engine-Metadatenserver-Endpunkte v0.1 und v1beta1 wurden verworfen und am 30. September 2020 eingestellt.

Informationen zum Zeitplan für die Einstellung finden Sie unter Einstellung der Metadatenserver-Endpunkte v0.1 und v1beta1.

Nächste Schritte

• Identitätsföderation von Arbeitslasten für GKE in Ihren Clustern aktivieren