Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Autenticarsi nel server dell'API Kubernetes

Autopilot Standard

Questa pagina ti guida attraverso l'autenticazione sicura nel server dell'API Kubernetes dai cluster GKE. Puoi proteggere il 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 carichi di lavoro Kubernetes nelle Google Cloud API, consulta Workload Identity Federation for GKE.

Questa pagina è rivolta a specialisti della sicurezza e operatori che devono autenticarsi in modo sicuro nel server dell'API Kubernetes dai cluster GKE. Questa pagina fornisce informazioni essenziali sui metodi di autenticazione disponibili e su come implementarli. Per saperne 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 GKE.

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

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à, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Autenticazione degli utenti

GKE gestisce l'autenticazione degli utenti finali tramite Google Cloud CLI. gcloud CLI autentica gli utenti in Google Cloud, configura 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, convalidando le credenziali presentate da kubectl e recuperando l'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 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 scegliere di configurare kubectl in modo che utilizzi le credenziali di un Google Cloud service account, 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 dell'accesso basato sui ruoli (RBAC) di Kubernetes.

Autenticazione con OAuth

Per autenticarti nel cluster utilizzando il metodo OAuth:

Accedi a gcloud CLI utilizzando le tue credenziali. Viene aperto un browser web per completare la procedura di autenticazione in 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 i dettagli, consulta la sezione Applicazioni in Google Cloud.
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 località di Compute Engine del piano di controllo del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
Verifica di aver eseguito l'autenticazione:
```
kubectl cluster-info
```

Una volta autenticati, gli utenti o i Google Cloud service account devono anche essere autorizzati a eseguire qualsiasi azione su un cluster GKE. Per saperne di più su come configurare l'autorizzazione, consulta Controllo dell'accesso basato sui ruoli.

Autenticazione delle applicazioni

Puoi anche autenticarti nel server API da un'applicazione in un pod senza interazione dell'utente, ad esempio da uno script nella pipeline CI/CD. La procedura dipende dall'ambiente in cui è in esecuzione l'applicazione.

Applicazione nello stesso cluster

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

Crea un service account Kubernetes e collegalo al pod. Se il pod ha già un service account Kubernetes o se vuoi utilizzare il account di servizio predefinito dello spazio dei nomi, salta questo passaggio.
Utilizza RBAC di Kubernetes per concedere al account di servizio Kubernetes le autorizzazioni richieste dall'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
```
Durante il runtime, quando l'applicazione invia una richiesta API Kubernetes, il server API autentica le credenziali del account di servizio.

Applicazioni in Google Cloud

Se l'applicazione è in esecuzione all'interno di Google Cloud ma all'esterno del cluster di destinazione (ad esempio, una VM di Compute Engine o un altro cluster GKE), devi autenticarti nel server API utilizzando le credenziali del account di servizio IAM disponibili nell'ambiente.

Assegna un account di servizio IAM al tuo ambiente. Se l'applicazione è in esecuzione all'interno di una VM di Compute Engine, assegna un service account IAM all'istanza. Se l'applicazione è in esecuzione in un altro cluster GKE, utilizza Workload Identity Federation for 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.
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 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 al service account 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.
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 l'applicazione esegue l'autenticazione da un ambiente esterno a Google Cloud, non può accedere alle credenziali del account di servizio IAM gestito. Per recuperare le credenziali del cluster, puoi creare un account di servizio IAM, scaricare la relativa chiave e utilizzarla durante il runtime 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 al account di servizio IAM l'accesso al cluster.

Il seguente comando concede il roles/container.developer ruolo IAM al ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com account di servizio IAM:
```
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 al 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.

Crea e scarica una chiave per il tuo account di servizio IAM. Rendila disponibile per l'applicazione durante il runtime:

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

Durante il runtime, nell'ambiente in cui è in esecuzione l'applicazione, autenticati in gcloud CLI utilizzando la chiave del 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 \
    --location=CONTROL_PLANE_LOCATION

Ambienti senza gcloud

È consigliabile utilizzare gcloud CLI per recuperare le credenziali del cluster perché questo metodo è resiliente agli eventi del cluster, come la rotazione dell'IP del control plane o la rotazione delle credenziali. Tuttavia, se non puoi installare 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 al account di servizio IAM l'accesso al cluster.

Il seguente comando concede il roles/container.developer ruolo IAM al ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com account di servizio IAM:
```
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 sulle autorizzazioni che concedi.

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

Recupera l'endpoint del piano di controllo per il 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 piano di controllo, recupera il certificato pubblico con codifica base64 dell'autorità di certificazione (CA) radice del cluster. Se utilizzi l'endpoint basato su DNS, puoi saltare questo passaggio.
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(masterAuth.clusterCaCertificate)"
```

Crea un file kubeconfig.yaml. Utilizza uno dei seguenti formati, a seconda di come l'applicazione accede al piano di controllo:

Endpoint basato su DNS:

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://docs.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.

Quando utilizzi l'endpoint basato su DNS, il servizio Google Front End (GFE) che ospita l'endpoint basato su DNS presenta un certificato firmato da una CA pubblica di Google. Il client può convalidare questo certificato utilizzando le librerie integrate. Per saperne di più, consulta Sicurezza del trasporto per le connessioni del piano di controllo.

Endpoint basato su IP:

apiVersion: v1
kind: Config
clusters:
- name: CLUSTER_NAME
  cluster:
    server: https://ENDPOINT
    certificate-authority-data: CLUSTER_CA_CERTIFICATE
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://docs.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 nel campo endpoint, dall'output del passaggio precedente.
CLUSTER_CA_CERTICATE: il certificato pubblico del cluster con codifica base64.

Quando utilizzi gli endpoint basati su IP, il server API presenta un certificato firmato dalla CA radice del cluster. Il client utilizza il certificato CA pubblico nel campo certificate-authority-data per convalidare il certificato del server API. Per saperne di più, consulta Sicurezza del trasporto per le connessioni del piano di controllo.

Esegui il deployment di kubeconfig.yaml e gsa-key.json insieme all'applicazione nel tuo ambiente. Durante il runtime, nell'ambiente in cui è in esecuzione l'applicazione, imposta queste variabili di ambiente:
```
export KUBECONFIG=path/to/kubeconfig.yaml
export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
```
L'applicazione può ora inviare richieste all'API Kubernetes e verrà autenticata come account di servizio IAM.

Aggiorna i metodi di autenticazione legacy

Prima dell'integrazione di OAuth con GKE, il certificato X.509 pre-provisioning o una password statica erano gli unici metodi di autenticazione disponibili, 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 sui cluster che eseguono GKE versione 1.12 e successive. Se utilizzi metodi di autenticazione legacy, ti consigliamo di disattivarli.

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

Disattiva 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 è denominato autenticazione di base.

Per aggiornare un cluster esistente e rimuovere la password statica:

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

Disattiva 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 radice del cluster (CA) firma i certificati client.

L'autenticazione tramite certificato client ha implicazioni sull'autorizzazione al server API Kubernetes. Se l'autorizzazione legacy del controllo dell'accesso basato su attributi (ABAC) è 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, ai certificati client devono essere concesse autorizzazioni specifiche per le risorse Kubernetes.

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 tramite certificato client su un cluster esistente, assicurati che RBAC sia abilitato sul cluster e che il certificato client non abbia alcuna autorizzazione sul cluster.

Passaggi successivi

Scopri di più sull'Google Cloud autenticazione.
Scopri di più sul controllo dell'accesso in GKE.
Scopri di più sui service account Google.
Scopri di più su Workload Identity Federation for GKE.
Scopri di più sul rafforzamento della sicurezza del cluster.