Autenticazione nel server dell'API Kubernetes


Questa pagina descrive i metodi di autenticazione supportati per la connessione al server API Kubernetes nei cluster Google Kubernetes Engine (GKE).

Per informazioni sull'autenticazione dei carichi di lavoro Kubernetes alle API Google Cloud, consulta Workload Identity Federation for GKE.

Panoramica

Esistono diversi metodi per autenticarsi in un server dell'API Kubernetes. In GKE, l'autenticazione OAuth è consigliata per l'autenticazione del cluster e viene configurata automaticamente.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Autenticazione degli utenti

GKE gestisce l'autenticazione degli utenti finali tramite la CLI Google Cloud. gcloud CLI autentica gli utenti Google Cloud, imposta la configurazione di Kubernetes, ottiene un accesso OAuth il token di accesso per il cluster e lo mantiene aggiornato.

Tutti i cluster GKE sono configurati per accettare Google Cloud le identità degli account utente e di servizio, convalidando le credenziali kubectl e recupero dell'indirizzo email associato all'utente o al servizio e l'identità dell'account. Di conseguenza, le credenziali di questi account devono includere l'ambito OAuth userinfo.email per eseguire l'autenticazione.

Quando utilizzi gcloud per configurare kubeconfig del tuo ambiente per un cluster nuovo o esistente, gcloud fornisce a kubectl le stesse credenziali utilizzate da gcloud stesso. Ad esempio, se utilizzi gcloud auth login, le tue credenziali personali vengono fornite a kubectl, incluso l'ambito userinfo.email. In questo modo, il cluster GKE può autenticare il client kubectl.

In alternativa, puoi scegliere di configurare kubectl in modo da utilizzare le credenziali di un account di servizio Google Cloud durante l'esecuzione su un'istanza Compute Engine. Tuttavia, per impostazione predefinita, l'ambito userinfo.email non è incluso nelle credenziali create dalle istanze Compute Engine. Pertanto, devi aggiungere per questo ambito in modo esplicito, ad esempio utilizzando il flag --scopes quando Viene creata l'istanza Compute Engine.

Puoi autorizzare azioni nel cluster utilizzando Identity and Access Management (IAM) o controllo degli accessi basato su ruoli (RBAC) di Kubernetes.

Autenticazione tramite OAuth

Per autenticarti al cluster utilizzando il metodo OAuth, svolgi i seguenti passaggi:

  1. Accedi a gcloud CLI utilizzando le tue credenziali. Si apre un browser web per completare il processo di autenticazione in Google Cloud:

    gcloud auth login
    
  2. Recupera le credenziali Kubernetes per un cluster specifico:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --zone=COMPUTE_ZONE
    
  3. Verifica di aver eseguito l'autenticazione:

    kubectl cluster-info
    

Una volta autenticati, gli utenti o gli account di servizio Google Cloud devono essere autorizzato a eseguire qualsiasi azione su un cluster GKE. Per ulteriori informazioni su come configurare l'autorizzazione, consulta controllo degli accessi basato sui ruoli.

Autenticazione delle applicazioni

Puoi anche eseguire l'autenticazione nel server API da un'applicazione in un pod senza interazione dell'utente, ad esempio da uno script nella pipeline CI/CD. La modalità di ottenimento dipende dall'ambiente in cui è in esecuzione l'applicazione.

Applicazione nello stesso cluster

Se la tua applicazione è in esecuzione nello stesso cluster GKE, e usare un account di servizio Kubernetes per l'autenticazione.

  1. Crea un Account di servizio Kubernetes e collegarlo al pod. Se il tuo pod ha già un servizio Kubernetes o se vuoi usare l'account di servizio predefinito dello spazio dei nomi, saltare questo passaggio.

  2. Utilizzare Kubernetes RBAC per concedere all'account di servizio Kubernetes le autorizzazioni richiesti dalla tua applicazione.

    L'esempio seguente concede le autorizzazioni view alle risorse nello spazio dei nomi prod a un account di servizio denominato cicd nello spazio dei nomi cicd-ns:

    kubectl create rolebinding cicd-secret-viewer \
        --namespace=prod \
        --clusterrole=view \
        --serviceaccount=cicd-ns:cicd
    
  3. In fase di runtime, quando la tua applicazione invia una richiesta API Kubernetes, l'API autentica le credenziali dell'account di servizio.

Applicazioni all'interno di Google Cloud

Se la tua applicazione viene eseguita all'interno di Google Cloud, ma al di fuori della destinazione (ad esempio, una VM di Compute Engine o un altro cluster GKE ), devi eseguire l'autenticazione sul server API utilizzando il cluster IAM con le credenziali dell'account di servizioo disponibili nell'ambiente.

  1. Assegna un account di servizio IAM al tuo ambiente. Se le tue è eseguita all'interno di una VM di Compute Engine, assegnare un account di servizio IAM all'istanza. Se la tua applicazione è in esecuzione in un altro cluster GKE, utilizza la federazione delle identità per i carichi di lavoro per GKE per configurare il pod in modo che venga eseguito come account di servizio IAM.

    Gli esempi riportati di seguito utilizzano ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com come account di servizio IAM.

  2. Concedi al service account IAM l'accesso al cluster.

    L'esempio seguente concede roles/container.developer ruolo IAM, che fornisce l'accesso agli oggetti API di Kubernetes all'interno dei cluster:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/container.developer
    

    In alternativa, puoi utilizzare il controllo degli accessi basato su ruoli (RBAC) per concedere all'account di servizio IAM l'accesso al cluster. Esegui il comando kubectl create rolebinding da applicazioni nello stesso cluster e utilizzano --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com anziché il flag --service-account.

  3. Recupera le credenziali del cluster:

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

    L'applicazione viene autenticata automaticamente utilizzando l'account di servizio IAM impostato nell'ambiente.

Applicazioni in altri ambienti

Se l'applicazione viene eseguita da un ambiente esterno Google Cloud, non può accedere all'account di servizio IAM gestito e credenziali. Per recuperare le credenziali del cluster, puoi creare un account di servizio IAM, scaricare la relativa chiave e utilizzarla in fase di esecuzione dal tuo servizio per recuperare le credenziali del cluster con gcloud CLI.

  1. Crea un account di servizio IAM per l'applicazione. Se hai già un account di servizio IAM, salta questo passaggio.

    Il comando seguente crea un account di servizio IAM denominato ci-cd-pipeline:

    gcloud iam service-accounts create ci-cd-pipeline
    
  2. Concedi all'account di servizio IAM l'accesso al tuo cluster.

    Il seguente comando concede il ruolo IAM roles/container.developer all'account di servizio IAM ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/container.developer
    

    Puoi anche utilizzare RBAC per concedere all'account di servizio IAM l'accesso al cluster. Esegui il comando kubectl create rolebinding da applicazioni nello stesso cluster e utilizzano --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com anziché il flag --service-account.

  3. Crea e scarica una chiave per il tuo account di servizio IAM. Marca disponibile per la tua applicazione in fase di runtime:

    gcloud iam service-accounts keys create gsa-key.json \
        --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
    
  4. In fase di runtime, nell'ambiente in cui viene eseguita l'applicazione, esegui l'autenticazione nel gcloud CLI utilizzando la chiave del tuo account di servizio IAM:

    gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
        --key-file=gsa-key.json
    
  5. Utilizza gcloud CLI per recuperare le credenziali del cluster:

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

Ambienti senza gcloud

È consigliabile utilizzare gcloud CLI per recuperare le credenziali del cluster perché questo metodo è resiliente agli eventi del cluster come una rotazione IP del piano di controllo o rotazione delle credenziali. Se invece non riesci a installare gcloud CLI nel tuo ambiente, puoi comunque creare un file kubeconfig statico per l'autenticazione nel cluster:

  1. Crea un account di servizio IAM per la tua applicazione. Se hai già un account di servizio IAM, salta questo passaggio.

    Il comando seguente crea un account di servizio IAM denominato ci-cd-pipeline:

    gcloud iam service-accounts create ci-cd-pipeline
    
  2. Concedi all'account di servizio IAM l'accesso al tuo cluster.

    Il seguente comando concede l'roles/container.developer al ruolo IAM ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com Account di servizio IAM:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/container.developer
    

    Puoi anche creare un ruolo IAM personalizzato per e un controllo granulare sulle autorizzazioni concesse.

  3. Crea e scarica una chiave per il tuo account di servizio IAM.

    Nell'esempio seguente, il file della chiave è denominato gsa-key.json:

    gcloud iam service-accounts keys create gsa-key.json \
        --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
    
  4. Ottieni i valori endpoint e clusterCaCertificate per il tuo cluster:

    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. Crea un file kubeconfig.yaml contenente quanto segue:

    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
    

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • endpoint: il valore ottenuto per endpoint nel passaggio precedente.
    • masterAuth.clusterCaCertificate: il valore che ottenuti per clusterCaCertificate dal passaggio precedente (non devono decodificare il certificato con codifica base64).
  6. Esegui il deployment di kubeconfig.yaml e gsa-key.json insieme alla tua applicazione in del tuo ambiente. In fase di runtime, nell'ambiente in cui viene eseguita l'applicazione, imposta queste variabili di ambiente:

    export KUBECONFIG=path/to/kubeconfig.yaml
    export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
    
  7. Ora la tua applicazione può inviare richieste all'API Kubernetes e verrà autenticata come account di servizio IAM.

Metodi di autenticazione precedenti

Prima dell'integrazione di OAuth con GKE, Il certificato X.509 o una password statica erano l'unica autenticazione disponibile ma non sono più consigliati e devono essere disattivati. Questi metodi rappresentano una superficie di attacco più ampia per la compromissione del cluster e sono disattivati per impostazione predefinita nei cluster che eseguono GKE versione 1.12 e successive. Se utilizzi metodi di autenticazione precedenti, ti consigliamo di disattivarli.

Se questa opzione è attiva, un utente con l'autorizzazione container.clusters.getCredentials può recuperando il certificato client e la password statica. roles/container.admin, I ruoli roles/owner e roles/editor hanno tutti questa autorizzazione, quindi usali i ruoli in modo saggio. Scopri di più sui ruoli IAM in GKE.

Disabilitazione dell'autenticazione con una password statica

Una password statica è una combinazione di nome utente e password convalidata dal server API. In GKE, questo metodo di autenticazione è definito come autenticazione di base.

Per aggiornare un cluster esistente e rimuovere la password statica:

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

Disabilitazione dell'autenticazione con un certificato client

Con l'autenticazione tramite certificato, un client presenta un certificato che il server API verifica con l'autorità di certificazione specificata. In GKE, l'autorità di certificazione (CA) radice del cluster firma i certificati client.

L'autenticazione dei certificati client ha implicazioni sull'autorizzazione al il server API Kubernetes. Se nel cluster è abilitata l'autorizzazione Controllo dell'accesso basato su attributi (ABAC) precedente, per impostazione predefinita i certificati client possono autenticarsi ed eseguire qualsiasi azione sul server API. D'altra parte, con Controllo degli accessi basato su ruoli (RBAC) abilitato. È necessario concedere i certificati client un'autorizzazione specifica alle risorse Kubernetes.

Per creare un cluster senza generare un certificato client, utilizza --no-issue-client-certificate flag:

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

Al momento non è possibile rimuovere un certificato client da un cluster esistente. Per interrompere l'utilizzo dell'autenticazione dei certificati client in un cluster esistente, assicurati che RBAC sia abilitato nel cluster e che il certificato client non ha alcuna autorizzazione sul cluster.

Passaggi successivi