Esta página foi traduzida pela API Cloud Translation.

Etapa 11 (opcional): configurar a Identidade da carga de trabalho

A Apigee híbrida v.1.14 é compatível com a Identidade da carga de trabalho no GKE e a federação de identidade da carga de trabalho no AKS e no EKS. Os procedimentos neste guia abordam apenas a configuração da Identidade da carga de trabalho no GKE. Para o AKS e o EKS, siga os procedimentos em Como ativar a federação de identidade da carga de trabalho no AKS e no EKS.

Configurar a Identidade da carga de trabalho no GKE

Contas de serviço do Google Cloud e do Kubernetes

Uma conta de serviço do Google Cloud é um tipo especial de conta que pode ser usada para fazer chamadas de API autorizadas por meio da autenticação como a própria conta de serviço. As contas de serviço do Google Cloud podem receber papéis e permissões semelhantes a um usuário individual. Quando um aplicativo é autenticado como uma conta de serviço, ele tem acesso a todos os recursos que a conta de serviço tem permissão para acessar. Para saber mais sobre as contas de serviço do Google Cloud, consulte Visão geral de contas de serviço.

Você criou contas de serviço do Google Cloud para a instalação híbrida da Apigee na Etapa 4: criar contas de serviço. A Apigee usa essas contas de serviço para autenticar os componentes híbridos.

As contas de serviço do Kubernetes são semelhantes às contas de serviço do Google Cloud. Uma conta de serviço do Kubernetes fornece uma identidade para processos executados em um pod e permite a autenticação no servidor da API de maneira semelhante a um usuário. Para saber mais sobre contas de serviço do Kubernetes, consulte Configurar contas de serviço para pods.

Se gcp.workloadIdentity.enabled estiver definido como true no arquivo de substituição, quando os gráficos do Helm para cada componente híbrido criarão as contas de serviço do Kubernetes para os componentes na instalação ou atualização deles, como você fez na Etapa 11: instalar a Apigee híbrida usando gráficos do Helm.

Ao configurar a Identidade da carga de trabalho no GKE, você associa as contas de serviço do Google Cloud às contas de serviço do Kubernetes no cluster do Kubernetes. Dessa forma, as contas de serviço do Kubernetes podem representar as contas de serviço do Google Cloud e usar os papéis e permissões atribuídos para a autenticação nos componentes híbridos.

Siga essas instruções para configurar a Identidade da carga de trabalho para seu projeto.

Preparar-se para configurar a Identidade da carga de trabalho

Verifique se a Identidade da carga de trabalho está ativada no arquivo de modificações. Ela precisa ser ativada no arquivo de substituições nas propriedades a seguir.
- namespace é obrigatório. Exemplo:
```
instanceID: "hybrid-instance-1"
namespace: "apigee"
```
- Se você estiver usando uma única conta de serviço (de não produção) para todos os componentes, especifique-a com: gcp.workloadIdentity.gsa. Exemplo:
```
  gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
  
```
- Se você estiver usando uma conta de serviço separada para cada componente (instalações de produção), especifique a conta de serviço com a propriedade gsa do componente. Exemplo:
```
  logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
  
```
Ver: gcp.workloadIdentity.enabled.
Verifique se a configuração gcloud atual está definida como o ID do projeto do Google Cloud com o comando a seguir:
```
gcloud config get project
```

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

gcloud config set project $PROJECT_ID

Verifique se a Identidade da carga de trabalho está ativada no cluster do GKE. Quando você criou o cluster na Etapa 1: criar um cluster, a etapa 6 foi ativar a Identidade da carga de trabalho. Confirme se a Identidade da carga de trabalho está ativada executando 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 você vir null nos resultados, execute o seguinte comando a fim de ativar a Identidade da carga de trabalho 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

Ative a Identidade da carga de trabalho para 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.

Verifique se a Identidade da carga de trabalho 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 Identidade da carga de trabalho

Use o procedimento a seguir para ativar a Identidade da carga de trabalho nos seguintes componentes híbridos:

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

Quando você executa o helm upgrade com a flag --dry-run para os gráficos apigee-datastore, apigee-env, apigee-org e apigee-telemetry, a saída inclui os comandos que você precisará para configurar a Identidade da carga de trabalho com os nomes corretos de GSA e KSA.

Por exemplo:

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server

NAME: datastore
  ...
For C* backup GKE Workload Identity, please make sure to add the below membership to the IAM policy binding using the respective kubernetes SA (KSA).
  gcloud iam service-accounts add-iam-policy-binding  \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-backup-sa]" \
        --project :my-project

Receba o comando para configurar a Identidade da carga de trabalho para apigee-datastore e o execute em NOTES: na saída.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Receba os comandos para configurar a Identidade da carga de trabalho para apigee-telemetry e os execute em NOTES: na saída.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Receba os comandos para configurar a Identidade da carga de trabalho para apigee-org e os execute em NOTES: na saída.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Receba os comandos para configurar a Identidade da carga de trabalho 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.yaml \
  --dry-run=server
```
Repita essa etapa para cada ambiente na instalação.
(Opcional) Veja o status das suas contas de serviço do Kubernetes na página Kubernetes: visão geral das cargas de trabalho no console do Google Cloud.
Acesse "Cargas de trabalho"

Observação: talvez você veja um status de erro das contas de serviço apigee-cassandra-backup e apigee-cassandra-restore. Isso ocorre porque, no momento, você não está executando backup ou restauração, e esses processos ainda não foram totalmente configurados. Para mais informações sobre o backup e a restauração do Cassandra, consulte a visão geral de backup do feedbackCassandra.

Próximas etapas

Na próxima etapa, você vai configurar o gateway de entrada da Apigee e implantar um proxy para testar a instalação.

Próxima etapa

(PRÓXIMA) Etapa 1: expor a entrada da Apigee 2