Esegui l'autenticazione utilizzando un token di trasporto

Questa pagina spiega come configurare l'autenticazione utilizzando un token di accesso per accedere ai cluster registrati all'esterno di Google Cloud. Al termine della configurazione, gli amministratori dei cluster potranno accedere ai cluster dalla console Google Cloud . Sono supportati molti tipi di token bearer, come specificato in Autenticazione Kubernetes. Il metodo più semplice è creare un account di servizio Kubernetes (KSA) nel cluster e utilizzare il relativo token di accesso per accedere.

Altri metodi di autenticazione

In alternativa alla configurazione dell'autenticazione tramite un token di accesso, puoi configurare uno dei seguenti metodi di autenticazione, a seconda delle esigenze della tua organizzazione:

  • Google Identity, che consente agli utenti di accedere utilizzando la propria identità Google Cloud . Utilizza questa opzione se i tuoi utenti hanno già accesso a Google Cloud con un'identità Google.

  • Se il cluster è configurato per utilizzare un provider di identità OIDC, puoi utilizzarlo per autenticarti al cluster dalla console Google Cloud . Puoi scoprire come configurare OIDC per i cluster GKE nelle seguenti guide:

Se questi metodi di autenticazione forniti da Google non sono adatti alla tua organizzazione, segui le istruzioni riportate in questa pagina per configurare l'autenticazione utilizzando un token di accesso.

Concedi i ruoli IAM per l'accesso tramite la console Google Cloud

Gli utenti che vogliono visualizzare i cluster collegati utilizzando la console devono disporre almeno dei seguenti ruoli IAM:

  • roles/container.viewer. Questo ruolo consente agli utenti di visualizzare le risorse dei container nella console Google Cloud , inclusa la pagina GKE Clusters. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo, consulta Ruoli Kubernetes Engine nella documentazione IAM.

  • roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster al di fuori diGoogle Cloud nella console Google Cloud . Gli utenti non hanno bisogno di questo ruolo se il tuo parco non include cluster esterni a Google Cloud. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo, consulta la sezione Ruoli GKE Hub nella documentazione IAM.

Esegui i comandi seguenti per concedere questi ruoli:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/gkehub.viewer

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto ospitante del parco risorse.

  • EMAIL_ADDRESS: l'indirizzo email associato all'account Google Cloud dell'utente.

Per ulteriori informazioni sulla concessione dei ruoli IAM, consulta Gestire l'accesso a progetti, cartelle e organizzazioni nella documentazione IAM.

Configurazione del controllo dell'accesso basato sui ruoli

L'accesso ai cluster è controllato utilizzando controllo dell'accesso basato su ruoli (RBAC) di Kubernetes.

Ti consigliamo di creare un KSA per ogni utente che accede al cluster. L'utilizzo di un token di accesso è come l'utilizzo di una password, quindi ogni utente deve avere il proprio account. Se accedi con il token di accesso del KSA, tutte le operazioni vengono eseguite come KSA, limitate dai ruoli RBAC detenuti dal KSA.

Per accedere al cluster tramite la console, l'amministratore del sistema deve disporre di almeno i seguenti ruoli RBAC nel cluster:

Creare e applicare il ruolo RBAC cloud-console-reader

Gli utenti autenticati che vogliono accedere alle risorse di un cluster nella console Google Cloud devono disporre delle autorizzazioni Kubernetes pertinenti. Se non vuoi concedere a questi utenti autorizzazioni più ampie, ad esempio quelle di un amministratore del cluster, puoi creare un ruolo RBAC personalizzato che includa le autorizzazioni minime per visualizzare i nodi, i volumi permanenti, i pod e le classi di archiviazione del cluster. Puoi definire questo insieme di autorizzazioni creando una risorsa ClusterRole RBAC,cloud-console-reader nel cluster.

cloud-console-reader concede ai propri utenti le autorizzazioni get, list e watch per i nodi, i volumi permanenti, i pod e le classi di archiviazione del cluster, che consentono di visualizzare i dettagli di queste risorse.

kubectl

Per creare il cloud-console-reader ClusterRole e applicarlo al cluster, esegui il comando seguente:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

Puoi quindi concedere questo ruolo ai KSA come descritto nella sezione successiva.

Creare e autorizzare un KSA

kubectl

Per creare un KSA e associarvi le autorizzazioni:

  1. Crea le risorse KSA e ClusterRoleBinding per associareClusterRoles view e cloud-console-reader Kubernetes RBAC alla KSA:

    KSA_NAME=KSA_NAME
    kubectl create serviceaccount ${KSA_NAME}
    kubectl create clusterrolebinding VIEW_BINDING_NAME \
       --clusterrole view --serviceaccount default:${KSA_NAME}
    kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
       --clusterrole cloud-console-reader --serviceaccount default:${KSA_NAME}
    

    Sostituisci quanto segue:

    • KSA_NAME: il nome scelto per il KSA
    • VIEW_BINDING_NAME: il nome che scegli per la risorsa view ClusterRoleBinding. Puoi chiamarla come preferisci, ma potrebbe essere più semplice assegnare il nome del KSA
    • CLOUD_CONSOLE_READER_BINDING_NAME: il nome scelto per la risorsa cloud-console-reader ClusterRoleBinding. Puoi anche scegliere un nome diverso.
  2. A seconda dell'accesso che deve avere l'account di servizio, associa altri ruoli all'account KSA. Per le opzioni, consulta i ruoli predefiniti di Kubernetes.

    Ad esempio, se vuoi eseguire il deployment di un'applicazione Kubernetes da Cloud Marketplace, associa il ruolo cluster-admin al servizio KSA:

    kubectl create clusterrolebinding BINDING_NAME \
       --clusterrole cluster-admin --serviceaccount default:KSA_NAME
    

    Sostituisci BINDING_NAME con il nome dell'associazione del ruolo del cluster per l'account di servizio.

Autorizzare altri account

kubectl

Per ogni altro utente o account di servizio che ottiene l'accesso al cluster, crea risorse ClusterRoleBinding per associare i ruoli view e cloud-console-reader al relativo account:

  1. Associa view e cloud-console-reader ClusterRoles:

    ACCOUNT_NAME=ACCOUNT_NAME
    kubectl create clusterrolebinding VIEW_BINDING_NAME \
       --clusterrole view --serviceaccount default:${ACCOUNT_NAME}
    kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
       --clusterrole cloud-console-reader --serviceaccount default:${ACCOUNT_NAME}
    

    Sostituisci quanto segue:

    • ACCOUNT_NAME: l'account di servizio Kubernetes
    • VIEW_BINDING_NAME: il nome che scegli per la risorsa view ClusterRoleBinding. Puoi chiamarla come preferisci, ma ti consigliamo di utilizzare il nome dell'account utente o di servizio
    • CLOUD_CONSOLE_READER_BINDING_NAME: il nome scelto per la risorsa view ClusterRoleBinding. Puoi anche scegliere un nome diverso.
  2. Associa altri ruoli, a seconda dell'accesso che deve avere l'account. Per le opzioni, consulta i ruoli predefiniti di Kubernetes.

    Ad esempio, per associare il ruolo cluster-admin, esegui il seguente comando:

    kubectl create clusterrolebinding BINDING_NAME \
       --clusterrole cluster-admin --serviceaccount default:ACCOUNT_NAME
    

    Sostituisci BINDING_NAME con il nome dell'associazione del ruolo del cluster per l'account di servizio.

Ottieni il token di accesso del KSA

kubectl

Per acquisire il token di accesso del KSA, esegui il seguente comando:

SECRET_NAME=KSA_NAME-token

kubectl apply -f - << __EOF__
apiVersion: v1
kind: Secret
metadata:
  name: "${SECRET_NAME}"
  annotations:
    kubernetes.io/service-account.name: "${KSA_NAME}"
type: kubernetes.io/service-account-token
__EOF__

until [[ $(kubectl get -o=jsonpath="{.data.token}" "secret/${SECRET_NAME}") ]]; do
  echo "waiting for token..." >&2;
  sleep 1;
done

kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 --decode

Sostituisci KSA_NAME con il nome scelto per il KSA.

Dall'output di questo comando, copia il token e salvalo in modo che gli utenti possano utilizzarlo per accedere alla console .