Fehlerbehebung bei der Clustersicherheit

Auf dieser Seite wird beschrieben, wie Sie Probleme im Zusammenhang mit Sicherheitskonfigurationen in Ihren Autopilot- und Standardclustern in Google Kubernetes Engine (GKE) beheben.

RBAC und IAM

Authentifizierte IAM-Konten können keine Aktionen im Cluster ausführen

Das folgende Problem tritt auf, wenn Sie versuchen, eine Aktion im Cluster auszuführen, GKE aber keine RBAC-Richtlinie finden kann, die die Aktion autorisiert. GKE versucht, eine IAM-Richtlinie zu finden, die dieselbe Berechtigung gewährt. Wenn dies fehlschlägt, wird eine Fehlermeldung wie die folgende angezeigt:

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.iam.gserviceaccount.com" cannot list resource "roles" in
API group "rbac.authorization.k8s.io" in the namespace "kube-system": requires
one of ["container.roles.list"] permission(s).

Verwenden Sie zum Beheben dieses Problems eine RBAC-Richtlinie, um die Berechtigungen für die versuchte Aktion zu erteilen. Um das Problem im vorherigen Beispiel zu beheben, weisen Sie eine Rolle mit der Berechtigung list für roles-Objekte im Namespace kube-system zu. Eine Anleitung finden Sie unter Aktionen in Clustern mit rollenbasierter Zugriffssteuerung autorisieren.

Workload Identity

Pod kann sich nicht bei Google Cloud authentifizieren

Wenn Ihre Anwendung sich nicht bei Google Cloud authentifizieren kann, prüfen Sie, ob die folgenden Einstellungen ordnungsgemäß konfiguriert sind:

Achten Sie darauf, dass die IAM Service Account Credentials API in dem Projekt aktiviert ist, das den GKE-Cluster enthält.

IAM Credentials API aktivieren
Workload Identity muss im Cluster aktiviert sein. Prüfen Sie dazu, ob der Workload Identity-Pool festgelegt ist:
```
gcloud container clusters describe CLUSTER_NAME \
    --format="value(workloadIdentityConfig.workloadPool)"
```
Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.

Der GKE-Metadatenserver muss im Knotenpool, in dem Ihre Anwendung ausgeführt wird, konfiguriert sein:

gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"

Prüfen Sie, ob das Kubernetes-Dienstkonto richtig annotiert ist:

kubectl describe serviceaccount \
    --namespace NAMESPACE KSA_NAME

Die Ausgabe enthält eine Annotation ähnlich der folgenden:

iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Prüfen Sie, ob das IAM-Dienstkonto richtig konfiguriert ist.

gcloud iam service-accounts get-iam-policy \
    GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

Die Ausgabe enthält eine Bindung, die etwa so aussieht:

- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser

Wenn Sie eine Cluster-Netzwerkrichtlinie haben, muss ausgehender Traffic zu 127.0.0.1/32 an Port 988 für Cluster mit GKE-Versionen vor 1.21.0-gke.1000 oder zu 169.254.169.252/32 an Port 988 für Cluster mit GKE-Version 1.21.0-gke.1000 und höher zugelassen werden. Bei Clustern, in denen GKE Dataplane V2 ausgeführt wird, muss ausgehender Traffic an 169.254.169.254/32 an Port 80 zugelassen werden.
```
kubectl describe networkpolicy NETWORK_POLICY_NAME
```

Zeitüberschreitungsfehler beim Starten des Pods

Der GKE-Metadatenserver benötigt einige Sekunden, bevor er Anfragen von einem neuen Pod annehmen kann. Daher können Versuche, sich mithilfe von Workload Identity innerhalb der ersten Sekunden der Lebensdauer eines Pods zu authentifizieren, bei Anwendungen und Google Cloud-Clientbibliotheken, die nur mit einem kurzen Zeitlimit konfiguriert sind, fehlschlagen.

Wenn Zeitüberschreitungsfehler auftreten, versuchen Sie Folgendes:

Google Cloud-Clientbibliotheken aktualisieren, die von Ihren Arbeitslasten verwendet werden.
Ändern Sie den Anwendungscode nach einigen Sekunden und versuchen Sie es noch einmal.

Stellen Sie einen initContainer bereit, der wartet, bis der GKE-Metadatenserver bereit ist, bevor der Hauptcontainer des Pods ausgeführt wird.

Das folgende Manifest gilt beispielsweise für einen Pod mit einem initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: KSA_NAME
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -sS -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 60 --connect-timeout 3 --fail --retry-all-errors > /dev/null && exit 0 || echo 'Retry limit exceeded. Failed to wait for metadata server to be available. Check if the gke-metadata-server Pod in the kube-system namespace is healthy.' >&2; exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

Workload Identity schlägt aufgrund der Nichtverfügbarkeit der Steuerungsebene fehl

Der Metadatenserver kann die Workload Identity nicht zurückgeben, wenn die Steuerungsebene des Clusters nicht verfügbar ist. Aufrufe an den Metadatenserver geben den Statuscode 500 zurück.

Der Logeintrag kann im Log-Explorer etwa so aussehen:

dial tcp 35.232.136.58:443: connect: connection refused

Dies führt zu einer erwarteten Nichtverfügbarkeit von Workload Identity.

Die Steuerungsebene ist möglicherweise in zonalen Clustern bei Clusterwartungen wie dem Rotieren von IPs, dem Upgrade von Steuerungsebenen-VMs oder der Größenanpassung von Clustern oder Knotenpools nicht verfügbar. Weitere Informationen zur Verfügbarkeit der Steuerungsebene finden Sie unter Regionale oder zonale Steuerungsebene auswählen. Durch den Wechsel zum regionalen Cluster wird dieses Problem behoben.

Workload Identity schlägt fehl

Wenn der GKE-Metadatenserver blockiert wird, schlägt Workload Identity fehl.

Wenn Sie Istio verwenden, sollten Sie allen Arbeitslasten, die Workload Identity verwenden, die folgende Annotation auf Anwendungsebene hinzufügen:

"traffic.sidecar.istio.io/excludeOutboundIPRanges=169.254.169.254/32"

Alternativ können Sie dafür den Schlüssel Istio ConfigMap von global.proxy.excludeIPRanges ändern.

`gke-metadata-server`-Pod stürzt ab

Der gke-metadata-server-System-DaemonSet-Pod ermöglicht Workload Identity auf Ihren Knoten. Der Pod verwendet Arbeitsspeicherressourcen, die proportional zur Anzahl der Kubernetes-Dienstkonten in Ihrem Cluster sind.

Das folgende Problem tritt auf, wenn die Ressourcennutzung des Pods gke-metadata-server die Limits überschreitet. Das Kubelet entfernt den Pod mit einem Fehler aufgrund fehlenden Arbeitsspeichers. Dieses Problem kann auftreten, wenn Ihr Cluster mehr als 3.000 Kubernetes-Dienstkonten hat.

So erkennen Sie das Problem:

Suchen Sie nach abstürzenden gke-metadata-server-Pods im Namespace kube-system:

kubectl get pods -n=kube-system | grep CrashLoopBackOff

Die Ausgabe sieht etwa so aus:

NAMESPACE     NAME                        READY     STATUS             RESTARTS   AGE
kube-system   gke-metadata-server-8sm2l   0/1       CrashLoopBackOff   194        16h
kube-system   gke-metadata-server-hfs6l   0/1       CrashLoopBackOff   1369       111d
kube-system   gke-metadata-server-hvtzn   0/1       CrashLoopBackOff   669        111d
kube-system   gke-metadata-server-swhbb   0/1       CrashLoopBackOff   30         136m
kube-system   gke-metadata-server-x4bl4   0/1       CrashLoopBackOff   7          15m

Beschreiben Sie den abstürzenden Pod, um zu bestätigen, dass die Ursache eine Bereinigung Fehler aufgrund fehlenden Arbeitsspeichers war:
```
kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled
```

Wenn Sie die Funktion auf dem GKE-Metadatenserver wiederherstellen möchten, reduzieren Sie die Anzahl der Dienstkonten in Ihrem Cluster auf weniger als 3.000.

Workload Identity kann nicht mit der Fehlermeldung „PatchPatch fehlgeschlagen“ aktiviert werden

GKE verwendet den von Google Cloud verwalteten Kubernetes Engine-Dienst-Agent, um Workload Identity in Ihren Clustern zu verwenden. Google Cloud weist diesem Dienst-Agent automatisch die Rolle des Kubernetes Engine-Dienst-Agents (roles/container.serviceAgent) für Ihr Projekt zu, wenn Sie die Google Kubernetes Engine API aktivieren.

Wenn Sie versuchen, Workload Identity für Cluster in einem Projekt zu aktivieren, in dem der Dienst-Agent nicht die Rolle „Kubernetes Engine-Dienst-Agent“ hat, schlägt der Vorgang mit einer Fehlermeldung wie der folgenden fehl:

Error waiting for updating GKE cluster workload identity config: DeployPatch failed

Versuchen Sie Folgendes, um dieses Problem zu beheben:

Prüfen Sie, ob der Dienst-Agent in Ihrem Projekt vorhanden und korrekt konfiguriert ist:
```
gcloud projects get-iam-policy PROJECT_ID \
    --flatten=bindings \
    --filter=bindings.role=roles/container.serviceAgent \
    --format="value[delimiter='\\n'](bindings.members)"
```
Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID.

Wenn der Dienst-Agent ordnungsgemäß konfiguriert ist, zeigt die Ausgabe die vollständige Identität des Dienst-Agents an:
```
serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
```
Wenn in der Ausgabe der Dienst-Agent nicht angezeigt wird, müssen Sie ihm die Rolle „Kubernetes Engine-Dienst-Agent“ zuweisen.

Rufen Sie Ihre Google Cloud-Projektnummer ab:

gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

Die Ausgabe sieht in etwa so aus:

123456789012

Gewähren Sie dem Dienst-Agent die Rolle:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/container.serviceAgent \
    --condition=None

Ersetzen Sie PROJECT_NUMBER durch Ihre Google Cloud-Projektnummer.

Versuchen Sie noch einmal, Workload Identity zu aktivieren.