Autenticazione nel server dell'API Kubernetes

Autopilota Standard

---

Questa pagina descrive la procedura di autenticazione sicura al server dell'API Kubernetes dai cluster GKE. Puoi proteggere il tuo cluster assicurandoti che solo gli utenti e le applicazioni autorizzati accedano alle 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 Google Cloud API, consulta Workload Identity Federation for GKE.

Questa pagina è rivolta a operatori e addetti alla sicurezza 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 Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

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

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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente 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 posizioni 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 la CLI Google Cloud. L'interfaccia a riga di comando gcloud autentica gli utenti inGoogle Cloud, configura la configurazione di Kubernetes, ottiene un token di accesso OAuth per il cluster e mantiene aggiornato il token di accesso.

Tutti i cluster GKE sono configurati per accettare le identità degli account utente e di servizio Google Cloud, convalidando le credenziali presentate dakubectl e recuperando l'indirizzo email associato all'identità dell'account utente o di servizio. Di conseguenza, le credenziali di questi account devono includere l'ambito OAuth userinfo.email per 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 servizioGoogle 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 esplicitamente, ad esempio utilizzando il flag --scopes al momento della creazione dell'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 di OAuth con GKE, il certificato X.509 preprovisioned o una password statica erano gli unici metodi di autenticazione disponibili. Questi metodi non sono più consigliati e sono disattivati per impostazione predefinita su tutti i nuovi cluster. Se utilizzi metodi di autenticazione precedenti, ti consigliamo di eseguire la migrazione a metodi di autenticazione più recenti.

Eseguire l'autenticazione con OAuth

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

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

   gcloud auth login
   

   Attenzione: non eseguire questa operazione su una VM 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 \
       --zone=COMPUTE_ZONE
   

3. Verifica di aver eseguito l'autenticazione:

   kubectl cluster-info
   

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

Autentica le applicazioni

Puoi anche autenticarti al server API da un'applicazione in un pod senza interazione 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, utilizza un account di servizio Kubernetes per l'autenticazione.

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

2. Utilizza il RBAC di Kubernetes 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 esecuzione, quando l'applicazione invia una richiesta all'API Kubernetes, il server API autentica le credenziali dell'account di servizio.

Applicazioni in Google Cloud

Se l'applicazione viene eseguita all'interno 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 Compute Engine, assegna un account di servizio IAM all'istanza. Se la tua applicazione è in esecuzione in un altro cluster GKE, utilizza 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 assegna 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 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 utilizza --user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com invece del 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'autenticazione dell'applicazione avviene da un ambiente esterno Google Cloud, non può accedere alle credenziali degli account di servizio IAM gestiti. 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.

Attenzione: le chiavi degli account di servizio IAM sono credenziali permanenti. Chiunque abbia accesso alla chiave può utilizzarla per eseguire azioni autorizzate nel tuo Google Cloud progetto. 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 gli account di servizio IAM e accedere alle risorse 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 service account 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 invece del flag --service-account.

3. Crea e scarica una chiave per il tuo account di servizio IAM. Rendilo disponibile alla 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 esecuzione, nell'ambiente in cui è in esecuzione l'applicazione, esegui l'autenticazione all'interfaccia a riga di comando gcloud 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

Ti consigliamo di utilizzare l'interfaccia a riga di comando gcloud per recuperare le credenziali del cluster perché questo metodo è resiliente agli eventi del cluster, come la rotazione degli IP o la rotazione delle credenziali del piano di controllo. Tuttavia, se non riesci a installare il client gcloud CLI nel tuo ambiente, puoi comunque creare un file kubeconfig statico per autenticarti 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 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 service account 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 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. Se utilizzi l'endpoint basato su DNS per l'accesso al piano di controllo, ottieni il valore endpoint per il tuo cluster:

   gcloud container clusters describe CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
        --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 cluster:

   gcloud container clusters describe CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --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 piano di controllo, 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 codificato in base64.

6. Esegui il deployment di kubeconfig.yaml e gsa-key.json insieme alla tua applicazione nel tuo ambiente. In fase di esecuzione, 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.

Aggiornare i metodi di autenticazione precedenti

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

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

Prima dell'integrazione di OAuth con GKE, il certificato X.509 preprovisioned o una password statica erano gli unici metodi di autenticazione disponibili, 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 abilitata, 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 saggezza. 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 convalidata dal server API. In GKE, questo metodo di autenticazione è indicato come 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 --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 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 il controllo dell'accesso basato sui ruoli (RBAC) abilitato, ai certificati client deve essere concessa un'autorizzazione specifica alle risorse Kubernetes.

Nota: in GKE 1.8 e versioni successive, il modello ABAC precedente è 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 \
    --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 attivato RBAC sul cluster e che il certificato client non abbia autorizzazioni sul cluster.

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

Passaggi successivi

• Scopri di più su Google Cloud Authentication.
• Scopri di più sul controllo dell'accesso in GKE.
• Scopri di più sugli account di servizio Google.
• Scopri di più su Workload Identity Federation per GKE.
• Scopri di più sul rafforzamento della sicurezza del cluster