Kubernetes GKE Workload Identity

É comum precisar configurar seus serviços Kubernetes para usar uma service account específica do Google (parecido com o projeto kube2iam).

Para isso, basta configurar uma service account do Kubernetes para atuar como uma service account do Google. Assim, qualquer Pod que rodar com:

ServiceAccountName: <kubernetes_service_account>

vai se autenticar nos serviços do gcloud usando a service account do Google.

Observação: este produto está em beta e pode mudar no futuro.

Visão geral:

O Workload Identity é a forma recomendada de acessar serviços do gcloud a partir do GKE. Depois de configurar a relação entre uma service account do Kubernetes e uma service account do Google, qualquer workload que rodar com a service account do Kubernetes se autentica automaticamente como a service account do Google ao acessar as APIs do Google Cloud.

Identidade entre clusters: Vale lembrar que, como o IAM é global por projeto, o namespace de identidade é compartilhado entre todos os clusters do mesmo projeto. Por isso, recomendamos separar os clusters em projetos diferentes.

Por exemplo:

O comando a seguir concede o mesmo acesso a qualquer cluster do projeto que use a service account e o Namespace padrão e tenha o Workload Identity habilitado:

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

Limitações:

• O Workload Identity está disponível para clusters rodando o GKE versão 1.12 ou superior.
• Com o Workload Identity habilitado, não dá mais para usar a service account padrão do Compute Engine.
• O Workload Identity não pode ser usado com Pods que rodam na rede do host.
• A injeção de namespace do Istio não funciona com o Workload Identity, porque ela altera o Metadata Server para GCE em vez de GKE, o que resulta na service account de computação do GCE.

Como habilitar o Workload Identity em um novo cluster:

1. Confirme se a IAM Credentials API está habilitada
2. defina o project id e o nome do cluster

export PROJECT_ID=<project_ID>
export CLUSTER_NAME=<cluster_name>
export CLUSTER_VERSION=<cluster_version>

3. Você pode criar um novo cluster já com o Workload Identity

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

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

ou atualizar um cluster existente:

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

Habilitar o Metadata Server

O Metadata Server roda em cada nó do GKE e altera o comportamento do endpoint de metadados. Ele também protege esse endpoint, dispensando o uso de metadata concealment. Vamos habilitar o Metadata Server no nosso node pool padrão.

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

4. configure o kubectl para o cluster

gcloud container clusters get-credentials ${CLUSTER_NAME}

5. Como a maioria dos recursos, as service accounts do Kubernetes ficam dentro de um Namespace. Crie o Namespace que vai ser usado pela service account do Kubernetes

kubectl create namespace <namespace>

6. defina o nome da service account do Kubernetes, o namespace e o nome da service account do Google

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

7. Crie a service account do Kubernetes

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

8. Crie a service account do Google

gcloud iam service-accounts create ${GSA_NAME}

9. Crie o binding entre a service account do Kubernetes e a service account do 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. Adicione a anotação iam.gke.io/gcp-service-account=[GSA_NAME]@[PROJECT_ID] à service account do Kubernetes, usando o e-mail da service account do Google:

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

11. rode um pod de teste

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

12. confirme se a service account é a correta

gcloud auth list

Revogando o acesso:

vale lembrar que revogar o acesso não é imediato — tokens em cache podem levar até 30 minutos para expirar.

para revogar o acesso, basta remover o 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

Aplicando a service account a um pod em arquivo YAML ou em um Helm chart:

use a diretiva serviceAccountName com a service account do Kubernetes que você definiu no binding para rodar com a service account do Google.