Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Kubernetes GKE Workload Identity

By Ami MahloofOct 11, 20193 min read

Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.

1 1f14dqe9np6kalf53ha4kq

En muchos casos necesitas configurar tus servicios de Kubernetes para que usen una cuenta de servicio específica de Google (parecido al proyecto kube2iam).

1 9i9730xcxt2drqhbkrszcw

Para conseguirlo, basta con configurar una cuenta de servicio de Kubernetes para que actúe como una cuenta de servicio de Google. Así, cualquier Pod que ejecute:

ServiceAccountName: <kubernetes_service_account>

se autenticará en los servicios de gcloud con la cuenta de servicio de Google.

Nota: este es un producto en beta y puede cambiar en el futuro.

Resumen:

Workload Identity es la forma recomendada de acceder a los servicios de gcloud desde GKE. Una vez que configuras la relación entre una cuenta de servicio de Kubernetes y una cuenta de servicio de Google, cualquier workload que corra con la cuenta de servicio de Kubernetes se autentica de forma automática como la cuenta de servicio de Google al consumir las APIs de Google Cloud.

Identidad entre clusters: Hay que tener presente que, como IAM es global por proyecto, el namespace de identidad se comparte entre todos los clusters del mismo proyecto, por lo que conviene separar los clusters en proyectos distintos.

Por ejemplo:

El siguiente comando otorga el mismo acceso a cualquier cluster del proyecto que use la cuenta de servicio y el Namespace por defecto y que tenga Workload Identity activado en el cluster:

gcloud iam service-accounts add-iam-policy-binding \
— role roles/iam.workloadIdentityUser \
— member "serviceAccount:[PROJECT_ID].svc.id.goog[default/default]"
[GOOGLE_SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com

Limitaciones:

  • Workload Identity está disponible para clusters que ejecuten GKE versión 1.12 o superior.
  • Cuando Workload Identity está activado, ya no puedes usar la cuenta de servicio por defecto de Compute Engine.
  • Workload Identity no se puede usar con Pods que se ejecuten en la red del host.
  • La inyección de namespaces de Istio no funciona con Workload Identity, ya que cambia el servidor de Metadata a GCE en vez de GKE y termina usando la cuenta de servicio de cómputo de GCE.

Activar Workload Identity en un cluster nuevo:

  1. Asegúrate de tener activada la API de IAM Credentials
  2. define el ID del proyecto y el nombre del cluster
export PROJECT_ID=<project_ID>
export CLUSTER_NAME=<cluster_name>
export CLUSTER_VERSION=<cluster_version>

3. Puedes crear un cluster nuevo con Workload Identity

gcloud beta container clusters create ${CLUSTER_NAME} \
--cluster-version=${CLUSTER_VERSION} \

--identity-namespace=${PROJECT_ID}.svc.id.goog

o actualizar un cluster existente:

gcloud beta container clusters update ${CLUSTER_NAME} \
--identity-namespace=${PROJECT_ID}.svc.id.goog

Activar el Metadata Server

El Metadata Server corre en cada nodo de GKE y modifica el comportamiento del endpoint de metadata. Además, asegura ese endpoint y elimina la necesidad de ocultar la metadata. Activemos el Metadata Server en nuestro node pool por defecto.

gcloud beta container node-pools update default-pool \
— cluster=workload-identity-test \
— workload-metadata-from-node=GKE_METADATA_SERVER \
— zone=us-central1-b

4. configura kubectl para el cluster

gcloud container clusters get-credentials ${CLUSTER_NAME}

5. Igual que la mayoría de los recursos, las cuentas de servicio de Kubernetes viven dentro de un Namespace. Crea el Namespace que vas a usar para la cuenta de servicio de Kubernetes

kubectl create namespace <namespace>

6. define el nombre y el namespace de la cuenta de servicio de Kubernetes, así como el nombre de la cuenta de servicio de Google

export K8S_NAMESPACE=<kubernetes_service_account_namespace>
export KSA_NAME=<kubernetes_service_account>
export GSA_NAME=<google_service_account>

7. Crea la cuenta de servicio de Kubernetes

kubectl create serviceaccount \
--namespace ${K8S_NAMESPACE} ${KSA_NAME}

8. Crea la cuenta de servicio de Google

gcloud iam service-accounts create ${GSA_NAME}

9. Crea el binding entre la cuenta de servicio de Kubernetes y la cuenta de servicio de Google

gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

10. Agrega la anotación iam.gke.io/gcp-service-account=[GSA_NAME]@[PROJECT_ID] a la cuenta de servicio de Kubernetes, usando la dirección de correo de la cuenta de servicio de Google:

kubectl annotate serviceaccount \
--namespace ${K8S_NAMESPACE} \
${KSA_NAME} \
iam.gke.io/gcp-service-account=${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

11. ejecuta un pod de prueba

kubectl run -it \
--generator=run-pod/v1 \
--image google/cloud-sdk \
--serviceaccount ${KSA_NAME} \
--namespace ${K8S_NAMESPACE} \
workload-identity-test

12. comprueba que la cuenta de servicio sea la correcta

gcloud auth list

Revocar el acceso:

ten en cuenta que revocar el acceso no es una operación inmediata y los tokens en caché pueden tardar hasta 30 minutos en expirar.

para revocar el acceso solo tienes que eliminar el binding:

gcloud iam service-accounts remove-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

Aplicar la cuenta de servicio a un pod en un archivo YAML o un Helm chart:

debes usar la directiva serviceAccountName con la cuenta de servicio de Kubernetes que usaste en el binding para que la ejecución se haga con la cuenta de servicio de Google.