Métodos de autenticação de contas de serviço no Apigee Hybrid

Escolher métodos de autenticação de contas de serviço no Apigee Hybrid

O Apigee hybrid requer contas de serviço para uma comunicação segura com os serviços Google Cloud . Escolha um método de autenticação para estas contas de serviço que esteja alinhado com os seus requisitos de segurança e operacionais. Este guia oferece uma breve vista geral das opções disponíveis.

Compreenda a autenticação da conta de serviço

O Apigee hybrid usa Google Cloud contas de serviço para autenticar e autorizar componentes em execução no seu cluster do Kubernetes. Estas contas de serviço acedem a Google Cloud recursos, como contentores do Cloud Storage e Cloud Logging. Cada conta de serviço requer funções específicas de gestão de identidade e de acesso (IAM) para desempenhar as respetivas funções.

Opções do método de autenticação

O Apigee hybrid suporta vários métodos de autenticação de contas de serviço. Cada método gere as chaves da conta de serviço de forma diferente, oferecendo vários níveis de segurança e complexidade operacional. Considere a sua plataforma, postura de segurança e infraestrutura existente ao selecionar um método.

A tabela que se segue resume os métodos de autenticação disponíveis:

Método Localização do armazenamento de chaves Compatibilidade com a plataforma Gestão de chaves
Segredos do Kubernetes Segredos do cluster do Kubernetes Qualquer plataforma Kubernetes O Kubernetes gere segredos, rotação manual
Ficheiros de chave JSON da conta de serviço Sistema de ficheiros local Qualquer plataforma Kubernetes Rotação e distribuição manuais
Vault HashiCorp Vault Qualquer plataforma Kubernetes O Vault gere segredos, rotação manual
Workload Identity Federation para o GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google Cloud faz a gestão, não são necessários ficheiros de chaves
Federação de identidades de cargas de trabalho noutras plataformas Google Cloud IAM AKS, EKS, OpenShift ou outras plataformas Kubernetes Google Cloud faz a gestão, não são necessários ficheiros de chaves

Armazene chaves de contas de serviço em Secrets do Kubernetes

Armazene as chaves de contas de serviço como segredos do Kubernetes no seu cluster. Este método tira partido das capacidades de gestão de segredos incorporadas no Kubernetes. Os segredos do Kubernetes podem oferecer uma forma mais segura de gerir chaves do que o armazenamento de ficheiros direto. Continua a gerir a rotação de chaves manualmente.

Os componentes híbridos referenciam estes segredos através das propriedades serviceAccountRef e envs[].serviceAccountRefs no ficheiro overrides.yaml. O Kubernetes gere a distribuição destes segredos para os pods adequados.

Por exemplo:

logger:
  serviceAccountRef: "my-project-apigee-logger-key"

Para usar este método, consulte o artigo Armazene chaves de contas de serviço em segredos do Kubernetes.

Ficheiros de chave JSON da conta de serviço

Este método envolve a criação de um ficheiro de chave JSON para cada conta de serviço e o armazenamento destes ficheiros diretamente num sistema de ficheiros. Esta abordagem oferece simplicidade para a configuração inicial. No entanto, requer garantir a segurança do sistema de ficheiros. A rotação de chaves é manual.

Coloque o ficheiro JSON da chave privada de cada conta de serviço num diretório acessível pelos componentes híbridos do Apigee. Faça referência ao caminho para estes ficheiros na configuração overrides.yaml usando as propriedades serviceAccountPath e envs[].serviceAccountPaths.

Por exemplo:

logger:
  serviceAccountPath: "my-project-apigee-logger.json"

Pode gerar e transferir os ficheiros de chave da conta de serviço através da ferramenta create-service-account fornecida com o Apigee hybrid. Para mais informações, consulte create-service-account.

Armazene chaves de contas de serviço no Vault

Integre o HashiCorp Vault para gerir as chaves da sua conta de serviço. O Vault oferece uma solução robusta para a gestão de segredos, com funcionalidades como a geração dinâmica de segredos, a auditoria e a rotação automática de chaves. Requer a configuração e a manutenção de uma instância do Vault.

Tem de criar segredos, políticas e funções do Vault separados para os componentes ao nível da organização e do ambiente. Faz referência a estes segredos na configuração do overrides.yaml através das propriedades serviceAccountSecretProviderClass e envs[].serviceAccountSecretProviderClass.

Por exemplo:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

envs:
- name: my-env
  serviceAccountSecretProviderClass: apigee-envsakeys-my-env-spc

Consulte o artigo Armazene chaves de contas de serviço no Vault.

Workload Identity Federation para o GKE

A federação de identidades da carga de trabalho para o GKE permite que as contas de serviço do Kubernetes atuem como Google Cloud contas de serviço. Este método elimina totalmente a necessidade de ficheiros de chaves de contas de serviço. Em alternativa, o seu cluster do GKE autentica diretamente as cargas de trabalho através do Google Cloud IAM. A federação de identidade da carga de trabalho para o GKE oferece um mecanismo de autenticação altamente seguro e automatizado, o que simplifica a gestão de chaves. Este método é específico dos clusters do GKE.

Este método requer a associação de cada conta de serviço do Kubernetes a uma Google Cloud conta de serviço específica. O processo de instalação do Apigee hybrid cria as contas de serviço do Kubernetes específicas da sua instalação quando instala os gráficos Helm do Apigee hybrid. Quando executa o comando helm install ou helm upgrade com a flag --dry-run para cada gráfico, o resultado inclui os comandos para associar as contas de serviço do Kubernetes às contas de serviço Google Cloud para o componente híbrido do Apigee específico nesse gráfico.

Ativa a Workload Identity Federation para o GKE no ficheiro overrides.yaml com a propriedade gcp.workloadIdentity.enabled.

Por exemplo:

gcp:
  projectID: my-project
  region: us-west1
  workloadIdentity:
    enabled: true

Consulte o artigo Ative a federação de identidades da carga de trabalho para o GKE.

Workload Identity Federation em plataformas que não sejam o GKE

A federação de identidades da carga de trabalho estende as vantagens da federação de identidades da carga de trabalho para o GKE a clusters do Kubernetes executados fora do Google Cloud, como o Azure Kubernetes Service (AKS), o Amazon Elastic Kubernetes Service (EKS) ou o OpenShift. Este método permite que o cluster não GKE se autentique Google Cloud usando o fornecedor OIDC do cluster para configurar uma relação de confiança entre o fornecedor de identidade do cluster e Google Cloud. Após a configuração inicial, este método elimina a necessidade de ficheiros de chaves de contas de serviço.

Pode usar a federação de identidade da carga de trabalho com:

  • Ficheiros de configuração de credenciais (em vez de ficheiros de chaves de contas de serviço)
  • Segredos do Kubernetes
  • Vault

Para usar a Workload Identity Federation, cria ficheiros de configuração de credenciais para cada Google Cloud conta de serviço. Use estes ficheiros em vez dos ficheiros de chaves de contas de serviço ou para configurar os segredos do Kubernetes ou do Vault, se estiver a usar esses métodos.

Ativa a Workload Identity Federation no ficheiro overrides.yaml com as propriedades gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience e gcp.federatedWorkloadIdentity.credentialSourceFile.

Por exemplo:

gcp:
  projectID: my-project
  region: us-west1
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

Consulte o artigo Ative a federação de identidades da carga de trabalho.

Escolha um método de autenticação

Selecione um método de autenticação com base no seu ambiente de implementação e requisitos de segurança.

  • Para implementações do GKE, a federação de identidades da carga de trabalho para o GKE oferece uma abordagem segura e simplificada. Elimina a necessidade de gerir diretamente os ficheiros de chaves da conta de serviço.
  • Para implementações do Kubernetes não GKE (AKS, EKS, OpenShift), a federação de identidades da carga de trabalho oferece uma experiência de autenticação sem chave semelhante. Este método é a escolha recomendada para estes ambientes.
  • Se a federação de identidades da carga de trabalho para o GKE ou a federação de identidades da carga de trabalho não forem opções, considere usar o Vault para a gestão e a automatização de chaves centralizadas.
  • Para implementações mais simples ou se não tiver uma configuração do Vault, o armazenamento de chaves em segredos do Kubernetes oferece uma solução nativa do Kubernetes. Este método oferece melhor segurança do que o armazenamento direto de ficheiros.
  • Os ficheiros de chaves de contas de serviço diretas são adequados para testes iniciais ou ambientes onde outros métodos não são viáveis. No entanto, este método requer uma gestão e uma rotação manuais cuidadosas das chaves.

O que se segue?