Authentifizierung beim Kubernetes API-Server

Auf dieser Seite werden die unterstützten Authentifizierungsmethoden beim Herstellen einer Verbindung zum Kubernetes API-Server in Google Kubernetes Engine (GKE) 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:

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project project-id
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
    gcloud config set compute/zone compute-zone
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
    gcloud config set compute/region compute-region
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Nutzer authentifizieren

GKE verwaltet die Endnutzerauthentifizierung für Sie über das gcloud-Befehlszeilentool. Das gcloud-Tool 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. Sie können den Zugriff auf die Cluster über Cloud Identity and Access Management (Cloud IAM) oder die rollenbasierte Zugriffssteuerung von Kubernetes (RBAC) steuern.

Vor der Einbindung von GKE in OAuth waren das vorinstallierte x509-Zertifikat oder statische Passwörter die einzigen verfügbaren Authentifizierungsmethoden. Seit Version 1.12 werden diese Methoden jedoch nicht für neue Cluster empfohlen und sind standardmäßig deaktiviert. Wenn Sie alte Authentifizierungsmethoden verwenden, empfehlen wir, dass sie diese Methoden ablösen.

Authentifizierung mit OAuth

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

  1. Melden Sie sich mit Ihren Anmeldedaten im gcloud-Tool an. Dadurch wird ein Webbrowser geöffnet, um den Authentifizierungsvorgang bei Google Cloud abzuschließen:

    gcloud auth login
    
  2. Rufen Sie die Kubernetes-Anmeldedaten für einen bestimmten Cluster ab:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --zone=COMPUTE_ZONE
    
  3. Sie sind jetzt authentifiziert. Prüfen Sie die Ergebnisse mit dem folgenden kubectl-Befehl:

    kubectl cluster-info
    

Dienste authentifizieren

Manchmal müssen Sie sich über einen Dienst ohne Nutzerinteraktion bei einem API-Server eines GKE-Clusters authentifizieren, z. B. über ein CI/CD-Pipelineskript. Wie Sie dies erreichen, hängt von der Umgebung ab, in der Ihr Dienst ausgeführt wird.

Dienst innerhalb desselben GKE-Clusters

Wenn Ihr Dienst in einem Pod innerhalb des GKE-Clusters ausgeführt wird, zu dem Sie eine Verbindung herstellen möchten, verwenden Sie zur Authentifizierung ein Kubernetes-Dienstkonto.

  1. Erstellen Sie ein Kubernetes-Dienstkonto und hängen Sie es an Ihren Pod an. Wenn Ihr Pod bereits ein Kubernetes-Dienstkonto hat, können Sie diesen Schritt überspringen.

    In unserem Beispiel verwenden wir ein Kubernetes-Dienstkonto namens cicd im Namespace cicd-ns.

  2. Gewähren Sie dem Kubernetes-Dienstkonto mithilfe von Kubernetes RBAC die richtigen Berechtigungen.

    In unserem Beispiel weisen wir die Rolle edit in einem prod-Namespace zu. In der Praxis sollten Sie jedoch eine Rolle zuweisen, die Ihren Anforderungen entspricht.

    kubectl create rolebinding cicd \
        --clusterrole=edit \
        --serviceaccount=cicd-ns:cicd \
        --namespace=prod
    
  3. Während der Laufzeit ruft der Dienst kubectl die von Ihnen konfigurierten Anmeldedaten ab.

Dienst innerhalb von Google Cloud

Wenn Ihr Dienst in Google Cloud ausgeführt wird (z. B. eine Compute Engine-VM oder ein anderer GKE-Cluster), sollten Sie sich mit den in der Umgebung verfügbaren Anmeldedaten des Google-Dienstkontos beim API-Server authentifizieren.

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

    In unserem Beispiel verwenden wir ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com als Google-Dienstkonto.

  2. Gewähren Sie dem Google-Dienstkonto Zugriff auf den gewünschten Cluster.

    In unserem Beispiel weisen wir die IAM-Rolle roles/container.developer zu, 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
    
  3. Rufen Sie die Clusteranmeldedaten ab:

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

    Ihr Dienst wird automatisch mit dem für die Umgebung festgelegten Google-Dienstkonto authentifiziert.

Dienst in anderen Umgebungen

Wenn Ihr Dienst von einer Umgebung außerhalb der Google Cloud authentifiziert wird, hat er keinen Zugriff auf die Anmeldedaten des verwalteten Google-Dienstkontos. Zum Abrufen von Clusteranmeldedaten müssen Sie ein Google-Dienstkonto erstellen, seinen Schlüssel herunterladen und den Schlüssel zur Laufzeit von Ihrem Dienst verwenden, um Clusteranmeldedaten mit dem Tool gcloud abzurufen.

  1. Erstellen Sie ein Google-Dienstkonto für Ihren Dienst. Wenn Sie bereits ein Google-Dienstkonto haben, können Sie diesen Schritt überspringen.

    In unserem Beispiel erstellen wir ein Dienstkonto mit dem Namen ci-cd-pipeline:

    gcloud iam service-accounts create ci-cd-pipeline
    
  2. Gewähren Sie dem Google-Dienstkonto Zugriff auf Ihren Cluster.

    In unserem Beispiel verwenden wir ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com als Google-Dienstkonto und die Cloud IAM-Rolle roles/container.developer, 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
    

    Wir haben Zugriff auf IAM gewährt. Sie können diesen Zugriff auch mit Kubernetes RBAC gewähren, um eine detailgenauere Steuerung zu erreichen.

  3. Erstellen Sie einen Schlüssel für Ihr Google-Dienstkonto und laden Sie ihn herunter. Machen Sie diesen für Ihren Dienst zur Laufzeit verfügbar:

    gcloud iam service-accounts keys create gsa-key.json \
        --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
    
  4. Zur Laufzeit in der Umgebung, in der Ihr Dienst ausgeführt wird, müssen Sie sich mit Ihrem Google-Dienstkontoschlüssel beim gcloud-Tool authentifizieren:

    gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
        --key-file=gsa-key.json
    

    Dazu muss das gcloud-Tool in Ihrer Umgebung installiert sein. Informationen zum Installieren des gcloud-Tools finden Sie unter Cloud SDK installieren. Wenn Sie das gcloud-Tool nicht in Ihrer Umgebung installieren können, lesen Sie den Abschnitt Umgebungen ohne gcloud.

  5. Rufen Sie mit dem gcloud-Tool 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 dem gcloud-Tool abzurufen, da diese Methode für Clusterereignisse wie die IP-Rotation oder die Rotation von Anmeldedaten resistent ist. Wenn Sie das Tool gcloud jedoch nicht in Ihrer Umgebung installieren können, können Sie eine statische kubeconfig-Datei erstellen, um sich beim Cluster zu authentifizieren:

  1. Erstellen Sie ein Google-Dienstkonto für Ihren Dienst. Wenn Sie bereits ein Google-Dienstkonto haben, können Sie diesen Schritt überspringen.

    In unserem Beispiel erstellen wir ein Dienstkonto mit dem Namen ci-cd-pipeline:

    gcloud iam service-accounts create ci-cd-pipeline
    
  2. Gewähren Sie dem Google-Dienstkonto Zugriff auf Ihren Cluster.

    In unserem Beispiel verwenden wir ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com als Google-Dienstkonto und die Cloud IAM-Rolle roles/container.developer, 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
    

    Wir haben Zugriff auf IAM gewährt. Sie können diesen Zugriff auch mit Kubernetes RBAC gewähren, um eine detailgenauere Steuerung zu erreichen.

  3. Erstellen Sie einen Schlüssel für Ihr Google-Dienstkonto und laden Sie ihn herunter.

    In unserem 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
    
  4. 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)"
    
  5. 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:
        auth-provider:
          name: gcp
    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.
  6. Stellen Sie kubeconfig.yaml und gsa-key.json zusammen mit Ihrem Dienst in Ihrer Umgebung bereit. Legen Sie zur Laufzeit in der Umgebung, in der Ihr Dienst ausgeführt wird, diese Umgebungsvariablen fest:

    export KUBECONFIG=path/to/kubeconfig.yaml
    export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
    
  7. Ihr Dienst kann jetzt kubectl aufrufen und als Google-Dienstkonto authentifiziert werden.

Alte Authentifizierungsmethoden

Vor der Einbindung von GKE in OAuth waren einmalig generierte x509-Zertifikate oder statische Passwörter die einzigen verfügbaren Authentifizierungsmethoden. Diese sind jedoch nicht mehr empfehlenswert uns sollten und deaktiviert werden. Diese Methoden bieten eine größere Angriffsfläche zur Manipulation von Clustern und sind seit GKE-Version 1.12 standardmäßig deaktiviert. Wenn Sie Legacy-Authentifizierungsmethoden verwenden, empfehlen wir, sie zu deaktivieren. Die Authentifizierung mit einem statischen Passwort ist veraltet und wurde seit der GKE-Version 1.19 entfernt.

Wenn diese Option aktiviert ist, können das Clientzertifikat und das statische Passwort von einem Nutzer mit der Berechtigung container.clusters.getCredentials abgerufen werden. Beachten Sie, dass den Rollen roles/container.admin, roles/owner und roles/editor diese Berechtigung jeweils zugewiesen ist. 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 werden Clientzertifikate von der Stammzertifizierungsstelle des Clusters signiert.

Die Clientzertifikatsauthentifizierung hat Auswirkungen auf die Autorisierung beim Kubernetes API-Server. Wenn eine alte 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