Autenticazione nel server dell'API Kubernetes

Autopilot Standard

---

Questa pagina ti guida nell'autenticazione sicura al server API Kubernetes dai cluster GKE. Puoi proteggere il tuo cluster assicurandoti che solo utenti e applicazioni autorizzati accedano alle tue risorse Kubernetes. Scoprirai i metodi di autenticazione disponibili, il metodo di autenticazione consigliato e come autenticare utenti, applicazioni e sistemi legacy.

Per informazioni sull'autenticazione dei workload Kubernetes alle APIGoogle Cloud , consulta Workload Identity Federation for GKE.

Questa pagina è destinata agli esperti di sicurezza e agli operatori che devono autenticarsi in modo sicuro al server API Kubernetes dai cluster GKE. Questa pagina fornisce informazioni essenziali sui metodi di autenticazione disponibili e su come implementarli. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE Enterprise.

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

• Panoramica generale dell'autenticazione in Google Cloud
• Panoramica generale di IAM e controllo dell'accesso basato sui ruoli (RBAC) in GKE
• Panoramica generale dei metodi di autenticazione di Kubernetes

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le località predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Autenticazione degli utenti

GKE gestisce l'autenticazione degli utenti finali tramite Google Cloud CLI. Gcloud CLI autentica gli utenti su Google Cloud, configura la configurazione di Kubernetes, recupera un token di accesso OAuth per il cluster e mantiene aggiornato il token di accesso.

Tutti i cluster GKE sono configurati per accettare Google Cloud le identità di utenti e account di servizio, con la convalida delle credenziali presentate da kubectl e il recupero dell'indirizzo email associato all'identità dell'utente o del service account. Di conseguenza, le credenziali di questi account devono includere l'ambito OAuth userinfo.email per l'autenticazione.

Quando utilizzi gcloud per configurare il kubeconfig del tuo ambiente per un cluster nuovo o esistente, gcloud fornisce a kubectl le stesse credenziali utilizzate da gcloud. 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 configurare kubectl in modo che utilizzi le credenziali di un service accountGoogle 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 questo ambito in modo esplicito, ad esempio utilizzando il flag --scopes quando viene creata l'istanza Compute Engine.

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

Nota: prima dell'integrazione OAuth con GKE, l'unico metodo di autenticazione disponibile era il certificato X.509 pre-provisioning o una password statica. Questi metodi non sono più consigliati e sono disattivati per impostazione predefinita su tutti i nuovi cluster. Se utilizzi metodi di autenticazione legacy, ti consigliamo di eseguire la migrazione a metodi di autenticazione più recenti.

Autenticarsi con OAuth

Per eseguire l'autenticazione al cluster utilizzando il metodo OAuth:

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

   gcloud auth login
   

   Attenzione: non eseguire questa operazione su una VM di Compute Engine in cui tutti gli utenti hanno accesso a root. Utilizza un account di servizio per l'autenticazione. Per maggiori dettagli, consulta la sezione Applicazioni all'interno di Google Cloud.

2. Recupera le credenziali Kubernetes per un cluster specifico:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del cluster.
   • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

3. Verifica di aver eseguito l'autenticazione:

   kubectl cluster-info
   

Una volta autenticati, gli utenti o i service account devono anche essere autorizzati a eseguire qualsiasi azione su un cluster GKE. Google Cloud Per ulteriori informazioni su come configurare l'autorizzazione, consulta la sezione sul controllo dell'accesso basato sui ruoli.

Autenticare le applicazioni

Puoi anche autenticarti al server API da un'applicazione in un pod senza interazione dell'utente, ad esempio da uno script nella pipeline CI/CD. Il modo in cui raggiungere questo obiettivo dipende dall'ambiente in cui viene eseguita l'applicazione.

Applicazione nello stesso cluster

Se la tua applicazione è in esecuzione nello stesso cluster GKE, utilizza unaccount di serviziot Kubernetes per l'autenticazione.

1. Crea un account di servizio Kubernetes e collegalo al tuo pod. Se il tuo pod ha già un service account Kubernetes o se vuoi utilizzare il account di servizio predefinito dello spazio dei nomi, salta questo passaggio.

2. Utilizza Kubernetes RBAC per concedere all'account di servizio Kubernetes le autorizzazioni richieste 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 l'applicazione invia una richiesta all'API Kubernetes, il server API autentica le credenziali del account di servizio.

Applicazioni in Google Cloud

Se la tua applicazione viene eseguita all'interno di Google Cloud ma al di fuori del cluster di destinazione (ad esempio una VM Compute Engine o un altro cluster GKE), devi autenticarti al server API utilizzando le credenziali dell'account di servizio IAM disponibili nell'ambiente.

1. Assegna un account di servizio IAM al tuo ambiente. Se la tua applicazione è in esecuzione all'interno di una VM di Compute Engine, assegna un account di servizio IAM all'istanza. Se la tua applicazione è in esecuzione in un cluster GKE diverso, 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 che seguono utilizzano ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com come account di servizio IAM.

2. Concedi al account di servizio IAM l'accesso al cluster.

   L'esempio seguente concede il ruolo IAM roles/container.developer, 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 RBAC per concedere all'account di servizio IAM l'accesso al cluster. Esegui il comando kubectl create rolebinding da Applicazioni nello stesso cluster e utilizza --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 \
       --location=CONTROL_PLANE_LOCATION
   

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

Applicazioni in altri ambienti

Se la tua applicazione esegue l'autenticazione da un ambiente esterno a Google Cloud, non può accedere alle credenziali delaccount di serviziot IAM gestito. Per recuperare le credenziali del cluster, puoi creare un account di servizio IAM, scaricarne la chiave e utilizzarla in fase di runtime dal tuo servizio per recuperare le credenziali del cluster con gcloud CLI.

Attenzione :le chiavi degli account di servizio IAM sono credenziali di lunga durata. Chiunque abbia accesso alla chiave può utilizzarla per eseguire azioni autorizzate nel tuo progettoGoogle Cloud . La gestione delle chiavi può essere difficile su larga scala. Valuta la possibilità di utilizzare la federazione delle identità per i carichi di lavoro, che configura le credenziali emesse da provider di identità esterni per impersonare i service account IAM e accedere alle risorse di Google Cloud.

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

   Il seguente comando 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 al 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 utilizza --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. Rendilo disponibile per la tua applicazione durante il 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 all'interfaccia allagcloud CLId utilizzando la chiave delaccount di serviziot 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 \
       --location=CONTROL_PLANE_LOCATION
   

Ambienti senza gcloud

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

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

   Il seguente comando 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 al 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 creare un ruolo IAM personalizzato per un controllo granulare delle autorizzazioni che concedi.

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

   Nell'esempio seguente, il file delle chiavi è denominato gsa-key.json:

   gcloud iam service-accounts keys create gsa-key.json \
       --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
   

4. Se utilizzi l'endpoint basato su DNS per l'accesso al control plane, ottieni il valore di endpoint per il tuo cluster:

   gcloud container clusters describe CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --format="value(endpoint)"
   

   Se utilizzi l'endpoint basato su IP per l'accesso al control plane, recupera il valore endpoint dal comando precedente e il valore clusterCaCertificate per il tuo cluster:

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

5. Crea un file kubeconfig.yaml. Utilizza il seguente formato se utilizzi l'endpoint basato su DNS per l'accesso al control plane:

   apiVersion: v1
   kind: Config
   clusters:
   - name: CLUSTER_NAME
     cluster:
       server: https://endpoint
   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.

   Se utilizzi endpoint basati su IP per l'accesso al control plane, aggiungi il valore ottenuto per clusterCaCertificate dal passaggio precedente nel parametro cluster del file kubeconfig.yaml:

   apiVersion: v1
   kind: Config
   clusters:
   - name: CLUSTER_NAME
     cluster:
       server: https://endpoint
       certificate-authority-data: masterAuth.clusterCaCertificate
   users:
   ...
   

   Non è necessario decodificare il certificato con codifica Base64.

6. Esegui il deployment di kubeconfig.yaml e gsa-key.json insieme alla tua applicazione nel 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 comeaccount di serviziot IAM.

Aggiornare i metodi di autenticazione legacy

Nota: per i cluster GKE Autopilot, non è possibile utilizzare i metodi di autenticazione legacy.

Nota: l'autenticazione di base è deprecata ed è stata rimossa in GKE 1.19 e versioni successive.

Prima dell'integrazione di OAuth con GKE, l'unico metodo di autenticazione disponibile era il certificato X.509 pre-provisioning o una password statica, ma non sono più consigliati e devono essere disabilitati. Questi metodi presentano una superficie di attacco più ampia per la compromissione del cluster e sono disabilitati per impostazione predefinita nei cluster che eseguono GKE versione 1.12 e successive. Se utilizzi metodi di autenticazione legacy, ti consigliamo di disattivarli.

Se attivata, un utente con l'autorizzazionecontainer.clusters.getCredentials può recuperare il certificato client e la password statica. I ruoli roles/container.admin, roles/owner eroles/editor dispongono tutti di questa autorizzazione, quindi utilizzali con giudizio. Scopri di più sui ruoli IAM in GKE.

Disattivare l'autenticazione con una password statica

Una password statica è una combinazione di nome utente e password che il server API convalida. In GKE, questo metodo di autenticazione è denominato autenticazione di base.

Nota: l'autenticazione di base è deprecata ed è stata rimossa in GKE 1.19 e versioni successive.

Per aggiornare un cluster esistente e rimuovere la password statica:

gcloud container clusters update CLUSTER_NAME \
     --location=CONTROL_PLANE_LOCATION \
     --no-enable-basic-auth

Disattivare l'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 del certificato client ha implicazioni sull'autorizzazione al server dell'API Kubernetes. Se l'autorizzazione controllo dell'accesso basato su attributi (ABAC) legacy è abilitata sul cluster, per impostazione predefinita i certificati client possono autenticarsi ed eseguire qualsiasi azione sul server API. D'altra parte, con il controllo dell'accesso basato sui ruoli (RBAC) abilitato, i certificati client devono disporre di un'autorizzazione specifica per le risorse Kubernetes.

Nota: in GKE 1.8 e versioni successive, ABAC legacy è disabilitato per impostazione predefinita e al certificato client non vengono concesse autorizzazioni.

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

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
    --no-issue-client-certificate

Al momento non è possibile rimuovere un certificato client da un cluster esistente. Per interrompere l'utilizzo dell'autenticazione del certificato client su un cluster esistente, assicurati di aver abilitato RBAC sul cluster e che il certificato client non disponga di alcuna autorizzazione sul cluster.

Nota: il flag --no-issue-client-certificate disattiva solo l'emissione di certificati client GKE legacy. Non disabilita l'API Kubernetes Certificates, che viene utilizzata per il funzionamento del cluster e non può essere disabilitata.

Passaggi successivi

• Scopri di più sull'autenticazioneGoogle Cloud .
• Scopri di più sul controllo dell'accesso in GKE.
• Scopri di più sui service account Google.
• Scopri di più sulla federazione delle identità per i carichi di lavoro per GKE.
• Scopri di più su come rafforzare la sicurezza del cluster.