Autenticazione nel server dell'API Kubernetes

Autopilot Standard

---

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

Per informazioni sull'autenticazione dei carichi di lavoro Kubernetes nelle API Google Cloud, consulta Federazione delle identità per i carichi di lavoro per GKE.

Panoramica

Esistono diversi metodi per l'autenticazione su un server API Kubernetes. In GKE, l'autenticazione OAuth è consigliata per l'autenticazione del cluster ed è configurata automaticamente.

Prima di iniziare

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

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Autenticazione degli utenti

GKE gestisce l'autenticazione degli utenti finali per te tramite Google Cloud CLI. gcloud CLI autentica gli utenti in Google Cloud, imposta la configurazione di Kubernetes, riceve 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 da kubectl 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 poter eseguire correttamente l'autenticazione.

Quando usi gcloud per configurare il 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. Ciò consente al cluster GKE di autenticare il client kubectl.

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

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

Nota: prima dell'integrazione di OAuth con GKE, gli unici metodi di autenticazione disponibili erano il certificato X.509 di cui è stato eseguito il pre-provisioning o una password statica. Questi metodi non sono più consigliati e sono disabilitati 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 eseguire l'autenticazione nel cluster utilizzando il metodo OAuth, segui questi passaggi:

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

   gcloud auth login
   

   Attenzione: non eseguire questa operazione su una VM di Compute Engine. Utilizza un account di servizio per l'autenticazione. Per maggiori dettagli, consulta la sezione Servizio in Google Cloud.

2. Recupera le credenziali Kubernetes per un cluster specifico:

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

3. Verifica l'autenticazione:

   kubectl cluster-info
   

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

Autenticazione delle applicazioni

Puoi anche eseguire l'autenticazione al server API da un'applicazione in un pod senza interazione dell'utente, ad esempio da uno script nella pipeline CI/CD. I metodi per ottenere questo risultato dipendono dall'ambiente in cui viene eseguita l'applicazione.

Applicazione nello stesso cluster

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

1. Crea un account di servizio Kubernetes e collegalo 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 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 API Kubernetes, il server API autentica le credenziali dell'account di servizio.

Applicazioni all'interno di Google Cloud

Se l'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 sul 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 viene eseguita all'interno di una VM di Compute Engine, assegna 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 all'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 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 l'accesso al cluster all'account di servizio IAM. 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 \
       --zone=COMPUTE_ZONE
   

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

Applicazioni in altri ambienti

Se la tua applicazione viene autenticata 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 utilizzare la chiave 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 progetto Google Cloud. La gestione delle chiavi può essere difficile su larga scala. Prendi in considerazione l'utilizzo della federazione delle identità per i carichi di lavoro, che configura le credenziali emesse da provider di identità esterni per assumere l'identità degli account di servizio IAM e accedere alle risorse Google Cloud.

1. Creare un account di servizio IAM per l'applicazione. Se disponi già di 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 cluster.

   Il comando seguente 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 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 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 che esegue la tua applicazione, esegui l'autenticazione a gcloud CLI utilizzando la chiave dell'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

Si consiglia di utilizzare gcloud CLI per recuperare le credenziali del cluster perché questo metodo è resiliente agli eventi del cluster, come la rotazione 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 l'autenticazione nel cluster:

1. Creare un account di servizio IAM per l'applicazione. Se disponi già di 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 cluster.

   Il comando seguente 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 inoltre creare un ruolo IAM personalizzato per avere un controllo granulare sulle autorizzazioni concesse.

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

   Nell'esempio seguente, il file di 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 all'applicazione nel tuo ambiente. In fase di runtime, nell'ambiente che esegue la tua applicazione, imposta queste variabili di ambiente:

   export KUBECONFIG=path/to/kubeconfig.yaml
   export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
   

7. La tua applicazione ora 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 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, gli unici metodi di autenticazione disponibili erano il certificato X.509 di cui è stato eseguito il pre-provisioning o una password statica, ma non sono più consigliati e dovrebbero essere disabilitati. Questi metodi presentano una superficie di attacco più ampia per la compromissione dei cluster e sono disabilitati per impostazione predefinita sui cluster che eseguono GKE versione 1.12 e successive. Se utilizzi metodi di autenticazione precedenti, ti consigliamo di disattivarli.

Se l'opzione è abilitata, un utente con l'autorizzazione container.clusters.getCredentials può recuperare il certificato client e la password statica. I ruoli roles/container.admin, roles/owner eroles/editor dispongono di questa autorizzazione, perciò usali con attenzione. Scopri di più sui ruoli IAM in GKE.

Disattivazione 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 è noto 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 dei certificati, 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 API Kubernetes. Se nel cluster è abilitata l'autorizzazione legacy di Controllo degli accessi basato su attributi (ABAC), per impostazione predefinita i certificati client possono autenticare ed eseguire qualsiasi azione sul server API. Con il controllo degli accessi basato su ruoli (RBAC) abilitato, invece, è necessario concedere ai certificati client 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 \
    --no-issue-client-certificate

Attualmente, non è possibile rimuovere un certificato client da un cluster esistente. Per interrompere l'utilizzo dell'autenticazione dei certificati client su un cluster esistente, assicurati che RBAC sia abilitato nel cluster e che il certificato client non disponga di autorizzazioni sul cluster.

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

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ù sulla Federazione delle identità per i carichi di lavoro per GKE.
• Scopri di più su come proteggere la sicurezza del cluster