Autenticazione nel server dell'API Kubernetes

Autopilot Standard

---

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 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 Google Cloud CLI. Gcloud CLI autentica gli utenti su Google Cloud, configura 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 di servizio e degli utenti Google Cloud, convalidando le credenziali presentate dakubectl e recuperando l'indirizzo email associato all'identità dell'account di servizio o dell'utente. 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 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 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.

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 aprirà un browser web per completare la procedura di autenticazione a 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 in 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 gli account di servizio Google Cloud 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.

Autenticazione delle 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 modello 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 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 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 account di servizio 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'applicazione esegue l'autenticazione da un ambiente esterno a Google Cloud, non può accedere alle credenziali dell'account di servizio IAM gestito. 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 progetto Google Cloud. La gestione delle chiavi può essere difficile su larga scala. Valuta la possibilità di utilizzare la federazione delle identità dei 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 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 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 alla 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

Ti consigliamo di utilizzare l'interfaccia alla gcloud CLI 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 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 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 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 ottenuto per clusterCaCertificate dal passaggio precedente (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 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.

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

Disattivazione 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 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ù sull'autenticazione Google Cloud.
• 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