Como ativar a federação de identidade da carga de trabalho para o GKE

Neste tópico, explicamos como ativar a federação de identidade da carga de trabalho para o GKE na Apigee híbrida.

Se você estiver usando o AKS ou EKS da Apigee híbrida, siga as instruções em Como ativar a federação de identidade da carga de trabalho no AKS e EKS.

Visão geral

A federação de identidade da carga de trabalho para GKE é uma maneira de aplicativos em execução no GKE (Google Kubernetes Engine) acessarem os serviços do Google Cloud . Para visões gerais da federação de identidade da carga de trabalho para o GKE, consulte:

Uma conta de serviço do Google Cloud IAM é uma identidade que um aplicativo pode usar para fazer solicitações às APIs do Google. Essas contas de serviço são chamadas de GSA (Contas de serviço do Google) no documento. Para mais informações sobre os GSAs, consulte Contas de serviço.

Separadamente, o Kubernetes também tem o conceito de contas de serviço. Uma conta de serviço fornece uma identidade para processos executados em um pod. As contas de serviço do Kubernetes são recursos do Kubernetes, enquanto as contas de serviço do Google são específicas do Google Cloud. Para informações sobre as contas de serviço do Kubernetes, consulte Configurar contas de serviço para pods na documentação do Kubernetes.

A Apigee cria e usa uma conta de serviço do Kubernetes para cada tipo de componente quando você instala os gráficos do Helm pela primeira vez para eles. A ativação da federação de identidade da carga de trabalho para GKE permite que os componentes híbridos interajam com as contas de serviço do Kubernetes.

Variáveis de ambiente usadas nestes procedimentos

Esses procedimentos usam as variáveis de ambiente a seguir. Elas podem ser definidas no shell de comando ou substituídas nas amostras de código por valores reais:

  • PROJECT_ID: o ID do projeto do Google Cloud.
  • ORG_NAME: o nome da organização da Apigee.
  • ENV_NAME: nome do ambiente da Apigee.
  • NAMESPACE: seu namespace da Apigee (geralmente apigee).
  • CLUSTER_LOCATION: a região ou zona do cluster do Kubernetes. Por exemplo: us-west1.
  • CLUSTER_NAME: o nome do cluster.

Verifique as variáveis de ambiente:

echo $PROJECT_ID
echo $ORG_NAME
echo $ENV_NAME
echo $NAMESPACE
echo $CLUSTER_LOCATION
echo $CLUSTER_NAME

Inicialize uma das variáveis necessárias:

export PROJECT_ID=MY_PROJECT_ID
export ORG_NAME=MY_ORG_NAME
export ENV_NAME=MY_ENV_NAME
export NAMESPACE=APIGEE_NAMESPACE
export CLUSTER_LOCATION=MY_CLUSTER_LOCATION
export CLUSTER_NAME=MY_CLUSTER_NAME

Federação de identidade da carga de trabalho para GKE e arquivos de chave da conta de serviço

Ao executar a Apigee híbrida no GKE, a prática padrão é criar e fazer o download de chaves privadas (arquivos .json) para cada uma das contas de serviço. Ao usar a Federação de Identidade da Carga de Trabalho para GKE, não é necessário fazer o download de chaves privadas conta de serviço e adicioná-las a Clusters do GKE.

Se você fez o download de arquivos de chave de conta de serviço como parte da instalação da Apigee híbrida, é possível excluí-los depois de ativar a federação de identidade da carga de trabalho para o GKE. Na maioria das instalações, eles ficam no diretório do gráfico de cada componente.

Ativar a federação de identidade da carga de trabalho para o GKE na Apigee híbrida

Siga estas instruções para configurar seu projeto e usar a federação de identidade da carga de trabalho do GKE.

Preparar-se para configurar a Federação de Identidade da Carga de Trabalho para GKE

  1. Verifique se a federação de identidade da carga de trabalho para GKE está ativada no arquivo de substituições. Ela precisa estar ativada no arquivo de substituições, e você precisa ter valores para as seguintes propriedades de configuração:
  2. Verifique se a configuração gcloud atual está definida como o ID do projeto do Google Cloud usando o seguinte comando: 
    gcloud config get project

    3. Se necessário, defina a configuração atual da gcloud:

    gcloud config set project $PROJECT_ID
  3. Verifique se a federação de identidade da carga de trabalho do GKE está ativada no cluster do GKE. Quando você criou o cluster na Etapa 1: criar um cluster, a etapa 6 consistia na ativação da federação de identidade da carga de trabalho para o GKE. Confirme se a federação de identidade da carga de trabalho para GKE está ativada com o seguinte comando:

    Clusters regionais

    gcloud container clusters describe $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

    Clusters zonais

    gcloud container clusters describe $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

    A saída será semelhante a esta: 

      ---
workloadPool: PROJECT_ID.svc.id.goog

    Se null for exibido nos resultados, em vez dos resultados, execute o seguinte comando para ativar a federação de identidade da carga de trabalho para GKE no cluster:

    Clusters regionais

    gcloud container clusters update $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --project $PROJECT_ID \
  --region $CLUSTER_LOCATION

    Clusters zonais

    gcloud container clusters update $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID

  4. Ative a federação de identidade da carga de trabalho para o GKE em cada pool de nós com os comandos a seguir. Essa operação pode levar até 30 minutos para cada nó:

    Clusters regionais

    gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

    Clusters zonais

    gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

    Em que NODE_POOL_NAME é o nome de cada pool de nós. Na maioria das instalações da Apigee híbrida, os dois pools de nós padrão são denominados apigee-data e apigee-runtime.

  5. Verifique se a federação de identidade da carga de trabalho para GKE está ativada nos pools de nós com os seguintes comandos:

    Clusters regionais

    gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"
     
    gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

    Clusters zonais

    gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"
     
    gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

    A resposta será semelhante a esta:

    ---
diskSizeGb: 100
diskType: pd-standard
...
workloadMetadataConfig:
mode: GKE_METADATA

Configurar a instalação para usar a federação de identidade da carga de trabalho para o GKE

Siga este procedimento para ativar a federação de identidade da carga de trabalho para o GKE nestes componentes híbridos:

  • apigee-datastore
  • apigee-telemetry
  • apigee-org
  • apigee-env

Quando você executa helm upgrade com as flags --dry-run ou --dry-run=server para os gráficos apigee-datastore, apigee-env, apigee-org e apigee-telemetry, a saída inclui os comandos necessários para configurar a federação de identidade da carga de trabalho para o GKE com os nomes corretos de GSA e KSA.

Exemplo:

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

A saída será algo como:

NAME: datastore
...
For Cassandra backup, please make sure to add the following membership to the IAM policy binding using the respective kubernetes SA (KSA).
gcloud iam service-accounts add-iam-policy-binding apigee-cassandra@PROJECT_ID.iam.gserviceaccount.com \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:PROJECT_ID.svc.id.goog[APIGEE_NAMESPACE/apigee-cassandra-default]" \
      --project PROJECT_ID

kubectl annotate serviceaccount apigee-cassandra-default \
      iam.gke.io/gcp-service-account=apigee-cassandra@PROJECT_ID.iam.gserviceaccount.com \
      --namespace APIGEE_NAMESPACE

Em que:

  • apigee-cassandra é o nome da conta de serviço do Google (GSA) para o Cassandra. Consulte Sobre contas de serviço.
  • PROJECT_ID é substituído pelo ID do projeto do Google Cloud.
  • APIGEE_NAMESPACE é substituído pelo seu namespace da Apigee, apigee por padrão.
  • apigee-cassandra-default é o nome da conta de serviço do Kubernetes para os pods do Cassandra criados pelo gráfico apigee-datastore.
  1. Receba o comando para configurar a federação de identidade da carga de trabalho para o GKE para apigee-datastore e execute os comandos em NOTES: na saída. 
    helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
  2. Receba os comandos para configurar a federação de identidade da carga de trabalho para o GKE para apigee-telemetry e os execute em NOTES: na saída. 
    helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run
  3. Receba os comandos para configurar a federação de identidade da carga de trabalho para o GKE para apigee-org e os execute em NOTES: na saída. 
    helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run
  4. Receba os comandos para configurar a federação de identidade da carga de trabalho para o GKE para apigee-env e os execute em NOTES: na saída. 
    helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=$ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run

    Repita essa etapa para cada ambiente na instalação.

Verificar a federação de identidade da carga de trabalho para o GKE

  1. Valide se as etapas funcionaram: 
    gcloud config set project $PROJECT_ID

    kubectl run --rm -it --image google/cloud-sdk:slim \
  --namespace $NAMESPACE workload-identity-test\
  -- gcloud auth list

    Caso o prompt de comando não seja exibido, pressione Enter.

    Se as etapas tiverem sido executadas corretamente, você verá uma resposta como esta:

                       Credentialed Accounts
ACTIVE  ACCOUNT
*       GSA@PROJECT_ID.iam.gserviceaccount.com
  2. Se estiver fazendo upgrade de uma instalação anterior, limpe os secrets que continham chaves privadas de conta de serviço: 
    kubectl delete secrets -n $NAMESPACE $(k get secrets -n $NAMESPACE | grep svc-account | awk '{print $1}')
  3. Verifique os registros: 
    kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer
  4. (Opcional) Veja o status das suas contas de serviço do Kubernetes na página Kubernetes: visão geral das cargas de trabalho no Google Cloud console.

    Acesse "Cargas de trabalho"

Configurar barreiras de proteção com a Federação de Identidade da Carga de Trabalho para GKE

É possível usar os guardrails durante a instalação inicial do gráfico apigee-operator para verificar se as APIs corretas estão ativadas para seu projeto. Para configurar sua instalação com a Federação de identidade da carga de trabalho para o GKE e usar proteções durante a instalação, configure manualmente a vinculação antes de executar o comando helm upgrade.

  1. Receba o endereço de e-mail do GSA de proteção com o seguinte comando: 
    gcloud iam service-accounts list --project ${PROJECT_ID} --filter "apigee"

    Os endereços de e-mail da GSA costumam ter o seguinte formato:

    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Exemplo:

    DISPLAY NAME       EMAIL                                                DISABLED
apigee-guardrails  apigee-guardrails@myproject.iam.gserviceaccount.com  False

    Use esse endereço de e-mail para a variável GSA_EMAIL nas próximas duas etapas.

  2. Verifique se a estrofe guardrails está no arquivo overrides.yaml: 
    guardrails:
  gsa: GSA_EMAIL
  3. A KSA para os guardrails é chamada de apigee-operator-guardrails-sa. Crie a vinculação para a GSA de proteção com o seguinte comando: 
    gcloud iam service-accounts add-iam-policy-binding GSA_EMAIL \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
  --project PROJECT_ID

Quando você executa o comando helm upgrade para o gráfico apigee-operator, ele cria um pod de barreiras de proteção para testar se as APIs necessárias estão ativadas para seu projeto. Se alguma API necessária não estiver ativada, o pod vai falhar e a instalação será interrompida. É possível inspecionar os registros do pod de barreiras de proteção para ver quais APIs são necessárias, mas não estão ativadas. Para mais detalhes, consulte Diagnosticar problemas com proteções.