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
.
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.
Eseguire l'autenticazione con OAuth
Per autenticarti al cluster utilizzando il metodo OAuth, svolgi i seguenti passaggi:
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
Recupera le credenziali Kubernetes per un cluster specifico:
gcloud container clusters get-credentials CLUSTER_NAME \ --zone=COMPUTE_ZONE
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.
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.
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 nomiprod
a un account di servizio denominatocicd
nello spazio dei nomicicd-ns
:kubectl create rolebinding cicd-secret-viewer \ --namespace=prod \ --clusterrole=view \ --serviceaccount=cicd-ns:cicd
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.
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.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
.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.
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
Concedi all'account di servizio IAM l'accesso al tuo cluster.
Il seguente comando concede il ruolo IAM
roles/container.developer
al service account IAMci-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
.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
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
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:
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
Concedi all'account di servizio IAM l'accesso al tuo cluster.
Il seguente comando concede il ruolo IAM
roles/container.developer
al service account IAMci-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.
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
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 valoreclusterCaCertificate
per il cluster:gcloud container clusters describe CLUSTER_NAME \ --zone=COMPUTE_ZONE \ --format="value(masterAuth.clusterCaCertificate)"
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 perendpoint
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 parametrocluster
del filekubeconfig.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.
Esegui il deployment di
kubeconfig.yaml
egsa-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
Ora la tua applicazione può inviare richieste all'API Kubernetes e verrà autenticata come account di servizio IAM.
Aggiornare i metodi di autenticazione precedenti
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.
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.
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.
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