Authentifizierung beim Kubernetes API-Server

Autopilot Standard

Auf dieser Seite werden die unterstützten Authentifizierungsmethoden beim Herstellen einer Verbindung zum Kubernetes API-Server in GKE-Clustern (Google Kubernetes Engine) beschrieben.

Informationen zur Authentifizierung von Kubernetes-Arbeitslasten bei Google Cloud APIs finden Sie unter Workload Identity.

Übersicht

Es gibt mehrere Methoden zur Authentifizierung bei einem Kubernetes API-Server. In GKE wird die OAuth-Authentifizierung für die Clusterauthentifizierung empfohlen und automatisch für Sie konfiguriert.

Vorbereitung

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.
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.

Nutzer authentifizieren

GKE verwaltet die Endnutzerauthentifizierung für Sie über Google Cloud CLI. Die gcloud CLI authentifiziert Nutzer bei Google Cloud, richtet die Kubernetes-Konfiguration ein, ruft ein OAuth-Zugriffstoken für den Cluster ab und hält das Zugriffstoken auf dem neuesten Stand.

Alle GKE-Cluster sind so konfiguriert, dass sie die Identitäten von Google Cloud-Nutzern und -Dienstkonten akzeptieren. Dabei werden die von kubectl bereitgestellten Anmeldedaten validiert und die mit der Nutzer- oder Dienstkontoidentität verknüpfte E-Mail-Adresse abgerufen. Die Anmeldedaten dieser Konten müssen daher für die Authentifizierung den OAuth-Bereich userinfo.email enthalten.

Wenn Sie gcloud zum Einrichten der kubeconfig Ihrer Umgebung für einen neuen oder bestehenden Cluster verwenden, weist gcloud kubectl die gleichen Anmeldedaten wie für gcloud zu. Wenn Sie beispielsweise gcloud auth login verwenden, werden kubectl Ihre persönlichen Anmeldedaten einschließlich des Bereichs userinfo.email bereitgestellt. Der GKE-Cluster kann dadurch den kubectl-Client authentifizieren.

Alternativ können Sie festlegen, dass kubectl während der Ausführung auf einer Compute Engine-Instanz die Anmeldedaten eines Google Cloud-Dienstkontos verwendet. Der userinfo.email-Bereich ist jedoch nicht standardmäßig in den von Compute Engine-Instanzen erstellten Anmeldedaten enthalten. Sie müssen diesen Bereich daher explizit einfügen. Beim Erstellen der Compute Engine-Instanz können Sie dies beispielsweise mit dem Flag --scopes tun.

Sie können Aktionen in Ihrem Cluster mit Identity and Access Management (IAM) oder Role Based Access Control (RBAC) von Kubernetes autorisieren.

Authentifizierung mit OAuth

So authentifizieren Sie sich bei Ihrem Cluster mithilfe der OAuth-Methode:

Melden Sie sich mit Ihren Anmeldedaten in der gcloud CLI an. Dadurch wird ein Webbrowser geöffnet, um den Authentifizierungsvorgang bei Google Cloud abzuschließen:
```
gcloud auth login
```
Achtung: Führen Sie dies nicht auf einer Compute Engine-VM aus. Verwenden Sie ein Dienstkonto zur Authentifizierung. Weitere Informationen finden Sie im Abschnitt Dienst innerhalb von Google Cloud.

Rufen Sie die Kubernetes-Anmeldedaten für einen bestimmten Cluster ab:

gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE

Prüfen Sie, ob Sie authentifiziert sind:
```
kubectl cluster-info
```

Authentifizierte Nutzer oder Google Cloud-Dienstkonten müssen außerdem autorisiert werden, um Aktionen an GKE-Clustern ausführen zu können. Weitere Informationen zum Konfigurieren der Autorisierung finden Sie unter Rollenbasierte Zugriffssteuerung.

Anwendungen authentifizieren

Sie können sich auch über eine Anwendung in einem Pod ohne Nutzerinteraktion beim API-Server authentifizieren, z. B. über ein Skript in Ihrer CI/CD-Pipeline. Wie Sie dies erreichen, hängt von der Umgebung ab, in der Ihre Anwendung ausgeführt wird.

Anwendung im selben Cluster

Wenn Ihre Anwendung im selben GKE-Cluster ausgeführt wird, verwenden Sie zur Authentifizierung ein Kubernetes-Dienstkonto.

Erstellen Sie ein Kubernetes-Dienstkonto und hängen Sie es an Ihren Pod an. Wenn Ihr Pod bereits ein Kubernetes-Dienstkonto hat oder Sie das Standarddienstkonto des Namespace verwenden möchten, überspringen Sie diesen Schritt.
Verwenden Sie Kubernetes RBAC, um dem Kubernetes-Dienstkonto die Berechtigungen zu erteilen, die Ihre Anwendung benötigt.

Im folgenden Beispiel werden view-Berechtigungen für Ressourcen im prod-Namespace zu einem Dienstkonto mit dem Namen cicd im cicd-ns-Namespace gewährt:
```
kubectl create rolebinding cicd-secret-viewer \
    --namespace=prod \
    --clusterrole=view \
    --serviceaccount=cicd-ns:cicd
```
Zur Laufzeit, wenn Ihre Anwendung eine Kubernetes API-Anfrage sendet, authentifiziert der API-Server die Anmeldedaten des Dienstkontos.

Anwendungen in Google Cloud

Wenn Ihre Anwendung in Google Cloud, jedoch außerhalb des Zielclusters ausgeführt wird (z. B. eine Compute Engine-VM oder ein anderer GKE-Cluster), sollten Sie sich mit den Anmeldedaten des IAM-Dienstkontos, die in der Umgebung verfügbar sind, beim API-Server authentifizieren.

Weisen Sie Ihrer Umgebung ein IAM-Dienstkonto zu. Wenn Ihre Anwendung in einer Compute Engine-VM ausgeführt wird, weisen Sie der Instanz ein IAM-Dienstkonto zu. Wenn Ihre Anwendung in einem anderen GKE-Cluster ausgeführt wird, konfigurieren Sie Ihren Pod mit Workload Identity für die Ausführung als IAM-Dienstkonto.

In den folgenden Beispielen wird ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com als IAM-Dienstkonto verwendet.
Gewähren Sie dem IAM-Dienstkonto Zugriff auf den gewünschten Cluster.

Im folgenden Beispiel wird die IAM-Rolle roles/container.developer zugewiesen, die Zugriff auf Kubernetes API-Objekte in Clustern ermöglicht:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
Alternativ können Sie das RBAC-Dienstkonto verwenden, um dem IAM-Dienstkonto Zugriff auf den Cluster zu gewähren. Führen Sie den Befehl kubectl create rolebinding aus Anwendungen im selben Cluster aus und verwenden Sie --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com anstelle des Flags --service-account.
Rufen Sie die Clusteranmeldedaten ab:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE
```
Ihre Anwendung wird automatisch mit dem für die Umgebung festgelegten IAM-Dienstkonto authentifiziert.

Anwendungen in anderen Umgebungen

Wenn Ihre Anwendung von einer Umgebung außerhalb von Google Cloud authentifiziert wird, kann sie nicht auf verwaltete IAM-Dienstkonto-Anmeldedaten zugreifen. Zum Abrufen von Clusteranmeldedaten können Sie ein IAM-Dienstkonto erstellen, den zugehörigen Schlüssel herunterladen und den Schlüssel zur Laufzeit von Ihrem Dienst verwenden, um Clusteranmeldedaten mit der gcloud CLI abzurufen.

Erstellen Sie ein IAM-Dienstkonto für Ihre Anwendung. Wenn Sie bereits ein IAM-Dienstkonto haben, überspringen Sie diesen Schritt.

Mit dem folgenden Befehl wird ein IAM-Dienstkonto mit dem Namen ci-cd-pipeline erstellt:
```
gcloud iam service-accounts create ci-cd-pipeline
```
Gewähren Sie dem IAM-Dienstkonto Zugriff auf Ihren Cluster.

Mit dem folgenden Befehl wird dem IAM-Dienstkonto ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com die IAM-Rolle roles/container.developer zugewiesen:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
Sie können RBAC auch verwenden, um dem IAM-Dienstkonto Zugriff auf den Cluster zu gewähren. Führen Sie den Befehl kubectl create rolebinding aus Anwendungen im selben Cluster aus und verwenden Sie --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com anstelle des Flags --service-account.
Erstellen Sie einen Schlüssel für Ihr IAM-Dienstkonto und laden Sie ihn herunter. Machen Sie ihn für die Anwendung zur Laufzeit verfügbar:
```
gcloud iam service-accounts keys create gsa-key.json \
    --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
```
Zur Laufzeit in der Umgebung, in der Ihre Anwendung ausgeführt wird, müssen Sie sich mit Ihrem IAM-Dienstkontoschlüssel bei der gcloud CLI authentifizieren:
```
gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --key-file=gsa-key.json
```

Rufen Sie mit der gcloud CLI die Clusteranmeldedaten ab:

gcloud config set project PROJECT_ID
gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=COMPUTE_ZONE

Umgebungen ohne gcloud

Es wird empfohlen, Clusteranmeldedaten mit der gcloud CLI abzurufen, da diese Methode für Clusterereignisse wie die IP-Rotation auf Steuerebene oder die Rotation von Anmeldedaten resistent ist. Wenn Sie die gcloud CLI jedoch nicht in Ihrer Umgebung installieren können, erstellen Sie eine statische kubeconfig-Datei, um sich beim Cluster zu authentifizieren:

Erstellen Sie ein IAM-Dienstkonto für Ihre Anwendung. Wenn Sie bereits ein IAM-Dienstkonto haben, überspringen Sie diesen Schritt.

Mit dem folgenden Befehl wird ein IAM-Dienstkonto mit dem Namen ci-cd-pipeline erstellt:
```
gcloud iam service-accounts create ci-cd-pipeline
```
Gewähren Sie dem IAM-Dienstkonto Zugriff auf Ihren Cluster.

Mit dem folgenden Befehl wird dem IAM-Dienstkonto ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com die IAM-Rolle roles/container.developer zugewiesen:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
Sie können auch eine benutzerdefinierte IAM-Rolle erstellen, um die Berechtigungen, die Sie gewähren, genau zu steuern.
Erstellen Sie einen Schlüssel für Ihr IAM-Dienstkonto und laden Sie ihn herunter.

Im folgenden Beispiel heißt die Schlüsseldatei gsa-key.json:
```
gcloud iam service-accounts keys create gsa-key.json \
    --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
```

Rufen Sie die endpoint- und clusterCaCertificate-Werte für Ihren Cluster ab:

gcloud container clusters describe CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
     --format="value(endpoint)"

gcloud container clusters describe CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --format="value(masterAuth.clusterCaCertificate)"

Erstellen Sie eine kubeconfig.yaml-Datei, die Folgendes enthält:

apiVersion: v1
kind: Config
clusters:
- name: CLUSTER_NAME
  cluster:
    server: https://endpoint
    certificate-authority-data: masterAuth.clusterCaCertificate
users:
- name: ci-cd-pipeline-gsa
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - --use_application_default_credentials
      command: gke-gcloud-auth-plugin
      installHint: Install gke-gcloud-auth-plugin for kubectl by following
        https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin
      provideClusterInfo: true
contexts:
- context:
    cluster: CLUSTER_NAME
    user: ci-cd-pipeline-gsa
  name: CLUSTER_NAME-ci-cd
current-context: CLUSTER_NAME-ci-cd

Ersetzen Sie dabei Folgendes:

CLUSTER_NAME: Der Name Ihres Clusters.
endpoint: Der Wert, den Sie im vorherigen Schritt für endpoint erhalten haben.
masterAuth.clusterCaCertificate: Der Wert, den Sie im vorherigen Schritt für clusterCaCertificate erhalten haben. Sie müssen das base64-codierte Zertifikat nicht decodieren.

Stellen Sie kubeconfig.yaml und gsa-key.json zusammen mit Ihrer Anwendung in Ihrer Umgebung bereit. Legen Sie zur Laufzeit in der Umgebung, in der Ihre Anwendung ausgeführt wird, diese Umgebungsvariablen fest:
```
export KUBECONFIG=path/to/kubeconfig.yaml
export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
```
Ihre Anwendung kann jetzt Anfragen an die Kubernetes API senden und wird als IAM-Dienstkonto authentifiziert.

Alte Authentifizierungsmethoden

Vor der OAuth-Integration in GKE waren das vorinstallierte X.509-Zertifikat oder ein statisches Passwort die einzigen verfügbaren Authentifizierungsmethoden. Diese sind jedoch nicht mehr empfehlenswert und sollten deaktiviert werden. Diese Methoden bieten eine größere Angriffsfläche zur Manipulation von Clustern und sind standardmäßig auf Clustern mit GKE-Version 1.12 und höher deaktiviert. Wenn Sie Legacy-Authentifizierungsmethoden verwenden, sollten Sie diese deaktivieren.

Bei Aktivierung kann ein Nutzer mit der Berechtigung container.clusters.getCredentials das Clientzertifikat und das statische Passwort abrufen. Die Rollen roles/container.admin, roles/owner und roles/editor haben alle diese Berechtigung. Verwenden Sie diese Rollen daher mit Bedacht. Weitere Informationen zu IAM-Rollen in GKE

Authentifizierung mit einem statischen Passwort deaktivieren

Ein statisches Passwort ist eine Kombination aus Nutzername und Passwort, die vom API-Server validiert wird. In GKE wird diese Authentifizierungsmethode als grundlegende Authentifizierung bezeichnet.

So aktualisieren Sie einen vorhandenen Cluster und entfernen das statische Passwort:

gcloud container clusters update CLUSTER_NAME --no-enable-basic-auth

Authentifizierung mit einem Clientzertifikat deaktivieren

Bei der Zertifikatauthentifizierung stellt ein Client ein Zertifikat bereit, das der API-Server bei der angegebenen Zertifizierungsstelle überprüft. In GKE signiert die Stammzertifizierungsstelle des Clusters Clientzertifikate.

Die Clientzertifikatsauthentifizierung hat Auswirkungen auf die Autorisierung beim Kubernetes API-Server. Wenn eine Legacy-Autorisierungsmethode über attributbasierte Zugriffssteuerung (ABAC) für den Cluster aktiviert ist, können sich Clientzertifikate standardmäßig authentifizieren und Aktionen auf dem API-Server ausführen. Wenn jedoch die rollenbasierte Zugriffssteuerung (RBAC) aktiviert ist, muss Clientzertifikaten spezifische Autorisierung für Kubernetes-Ressourcen gewährt werden.

Verwenden Sie zum Erstellen eines Clusters ohne Erzeugen eines Clientzertifikats die Option --no-issue-client-certificate:

gcloud container clusters create CLUSTER_NAME \
    --no-issue-client-certificate

Derzeit gibt es keine Möglichkeit, ein Clientzertifikat aus einem vorhandenen Cluster zu entfernen. Wenn Sie die Clientzertifikatauthentifizierung in einem vorhandenen Cluster nicht mehr verwenden möchten, müssen Sie sicherstellen, dass RBAC für den Cluster aktiviert ist und das Clientzertifikat keine Autorisierung für den Cluster hat.

Nächste Schritte

Weitere Informationen zur Google Cloud-Authentifizierung
Weitere Informationen zur Zugriffssteuerung in GKE
Weitere Informationen zu Google-Dienstkonten
Weitere Informationen zu Workload Identity
Weitere Informationen zur Härtung Ihrer Cluster-Sicherheit