Ativar a Workload Identity Federation no AKS e no EKS

Este tópico explica como ativar a identidade de carga de trabalho para instalações híbridas do Apigee nas plataformas AKS e EKS.

Vista geral

A federação de identidades de cargas de trabalho permite que as aplicações executadas fora do Google Cloud se façam passar por uma conta de serviço da Google Cloud Platform através da utilização de credenciais de um fornecedor de identidade externo.

A utilização da federação de identidades de cargas de trabalho pode ajudar a melhorar a segurança, permitindo que as aplicações utilizem os mecanismos de autenticação fornecidos pelo ambiente externo, e pode ajudar a substituir as chaves de contas de serviço.

Para uma vista geral, consulte o artigo Práticas recomendadas para usar a Workload Identity Federation.

Configure a Workload Identity Federation

Para usar a Workload Identity Federation com o Apigee hybrid, primeiro configure o cluster e, em seguida, aplique a funcionalidade à sua instalação do Apigee hybrid.

Configure o cluster para usar a Workload Identity Federation.

Siga as instruções do Google Cloud para configurar a Federação de identidades da carga de trabalho para o Kubernetes, com as seguintes modificações:

  • Liste as suas contas de serviço IAM e contas de serviço Kubernetes com os seguintes comandos:
    • Contas de serviço do IAM: provavelmente, já criou as contas de serviço do IAM (também denominadas "contas de serviço Google") durante a instalação inicial do Apigee hybrid com a ferramenta create-service-account. Consulte o artigo Acerca das contas de serviço para ver uma lista das contas de serviço do IAM necessárias para o Apigee hybrid.

      Pode ver uma lista de contas de serviço da IAM no seu projeto com o seguinte comando: 

      gcloud iam service-accounts list --project PROJECT_ID
    • Contas de serviço do Kubernetes: os gráficos do Apigee Hybrid criam as contas de serviço do Kubernetes necessárias para cada componente quando executa o comando helm install ou helm update.

      Pode ver as contas de serviço do Kubernetes no seu cluster com os comandos kubectl get sa: 

      kubectl get sa -n APIGEE_NAMESPACE
kubectl get sa -n apigee-system
  • No passo Configure a federação de identidades da carga de trabalho, o público-alvo predefinido para os Workload Identity Pools e os fornecedores criados é o seguinte. Use esta predefinição ou defina um público-alvo esperado personalizado e guarde este valor para utilização posterior. 
    https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
  • Pare após o passo 1 em Implemente uma carga de trabalho do Kubernetes. Existe um ficheiro de configuração de credenciais para cada conta de serviço Google. Guarde cada ficheiro de configuração de credenciais e guarde o caminho introduzido para o parâmetro --credential-source-file, por exemplo: /var/run/service-account/token.

Configure o Apigee Hybrid para usar a Workload Identity Federation

  1. Copie o ficheiro de origem das credenciais e o ficheiro de saída (credential-configuration.json) para os seguintes diretórios de gráficos. Estes foram os valores que indicou no passo 1 em Implemente uma carga de trabalho do Kubernetes.
    • apigee-datastore/
    • apigee-env
    • apigee-org/
    • apigee-telemetry/
  2. Faça as seguintes alterações globais ao ficheiro de substituições do cluster: 
    gcp:
  workloadIdentity:
    enabled: false # must be set to false to use Workload Identity Federation
  federatedWorkloadIdentity:
    enabled: true
    audience: "AUDIENCE"
    credentialSourceFile: "CREDENTIAL_SOURCE_FILE"

    Onde:

    • AUDIENCE é o público-alvo permitido do Workload Identity Provider, o valor em .audience no ficheiro JSON de configuração de credenciais que configurou no passo 1 em Implemente uma carga de trabalho do Kubernetes.
    • CREDENTIAL_SOURCE_FILE é o nome do ficheiro e o caminho para o ficheiro de origem das credenciais usado pela federação de identidades da carga de trabalho para obter as credenciais das contas de serviço. Este é o valor que fornece para credential-source-file quando configura a federação de identidade da carga de trabalho com o comando create-cred-config no passo 1 em Implemente uma carga de trabalho do Kubernetes. Por exemplo:

      • Por exemplo:

      gcp:
  workloadIdentity:
    enabled: false
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider"
    credentialSourceFile: "/var/run/service-account/token"
  3. Configure as substituições para cada componente através da Workload Identity Federation. Selecione as instruções para ficheiros CERT, segredos do Kubernetes ou Vault, conforme adequado para a sua instalação.

    Ficheiro de certificação

    Substitua o valor de serviceAccountPath pelo ficheiro de origem das credenciais. Este tem de ser o caminho relativo ao diretório do gráfico. Por exemplo:

    udca:
  serviceAccountPath: fwi/credential-configuration.json

    K8s Secret

    1. Crie um novo segredo do Kubernetes para o ficheiro de origem das credenciais. 
      kubectl create secret -n apigee generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"

      Por exemplo:

      kubectl create secret -n apigee generic udca-fwi-secret --from-file="client_secret.json=./fwi/credential-configuration.json"
    2. Substitua o valor de serviceAccountRef pelo novo segredo. Por exemplo: 
      udca:
  serviceAccountRef: udca-fwi-secret

    Vault

    Atualize a chave da conta de serviço SAKEY no Vault com o ficheiro de origem das credenciais. Por exemplo, para UDCA (o procedimento é semelhante para todos os componentes): 

    SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"
  4. Aplique as alterações a cada componente afetado com o comando helm update:

    Se estiver a usar o Vault pela primeira vez com este cluster, atualize o gráfico apigee-operator: 

    helm upgrade operator apigee-operator/ \
  --namespace apigee-system \
  --atomic \
  -f overrides.yaml

    Atualize os restantes tops afetados pela seguinte ordem: 

    helm upgrade datastore apigee-datastore/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

    helm upgrade telemetry apigee-telemetry/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

    helm upgrade $ORG_NAME apigee-org/ \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

    Atualize o gráfico apigee-env para cada ambiente, substituindo ENV_NAME de cada vez: 

    helm upgrade $ENV_NAME apigee-env/ \
  --namespace apigee \
  --atomic \
  --set env=$ENV_NAME \
  -f overrides.yaml

    Consulte a referência do Helm do Apigee hybrid para ver uma lista de componentes e os respetivos gráficos.

Para mais informações sobre a Workload Identity Federation e as práticas recomendadas, consulte o artigo Práticas recomendadas para usar a Workload Identity Federation.