Métodos de autenticação de contas de serviço na Apigee híbrida

Como escolher métodos de autenticação de conta de serviço na Apigee híbrida

A Apigee híbrida exige contas de serviço para comunicação segura com Google Cloud serviços. Escolha um método de autenticação para essas contas de serviço que esteja alinhado aos seus requisitos de segurança e operacionais. Este guia oferece uma breve visão geral das opções disponíveis.

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

A Apigee híbrida usa Google Cloud contas de serviço para autenticar e autorizar componentes em execução no cluster do Kubernetes. Essas contas de serviço acessam Google Cloud recursos, como buckets do Cloud Storage e o Cloud Logging. Cada conta de serviço requer papéis específicos do Identity and Access Management (IAM) para executar as funções.

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

A Apigee híbrida oferece suporte a vários métodos de autenticação de contas de serviço. Cada método gerencia as chaves de conta de serviço de maneira diferente, oferecendo vários níveis de segurança e complexidade operacional. Considere sua plataforma, postura de segurança e infraestrutura atual ao selecionar um método.

A tabela a seguir resume os métodos de autenticação disponíveis:

Método Local de armazenamento de chaves Compatibilidade da plataforma Gerenciamento de chaves
Secrets do Kubernetes Secrets do cluster do Kubernetes Qualquer plataforma do Kubernetes O Kubernetes gerencia secrets, rotação manual
Arquivos de chave JSON da conta de serviço Sistema de arquivos local Qualquer plataforma do Kubernetes Rotação e distribuição manual
Vault HashiCorp Vault Qualquer plataforma do Kubernetes O Vault gerencia secrets, rotação manual
Federação de Identidade da Carga de Trabalho para GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google Cloud gerencia, nenhum arquivo de chave necessário
Federação de identidade da carga de trabalho em outras plataformas Google Cloud IAM AKS, EKS, OpenShift ou outras plataformas do Kubernetes Google Cloud gerencia, nenhum arquivo de chave necessário

Armazenar chaves de conta de serviço em secrets do Kubernetes

Armazene as chaves de conta de serviço como secrets do Kubernetes no cluster. Esse método aproveita os recursos integrados de gerenciamento de secrets no Kubernetes. Os secrets do Kubernetes podem oferecer uma maneira mais segura de gerenciar chaves do que o armazenamento direto de arquivos. Você ainda gerencia a rotação de chaves manualmente.

Os componentes híbridos referenciam esses secrets usando as serviceAccountRef e envs[].serviceAccountRefs propriedades no overrides.yaml arquivo. O Kubernetes gerencia a distribuição desses secrets para os pods apropriados.

Exemplo:

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

Para usar esse método, consulte Armazenar chaves de conta de serviço em secrets do Kubernetes.

Arquivos de chave JSON da conta de serviço

Esse método envolve a criação de um arquivo de chave JSON para cada conta de serviço e o armazenamento desses arquivos diretamente em um sistema de arquivos. Essa abordagem oferece simplicidade para a configuração inicial. No entanto, ela exige que você garanta a segurança do sistema de arquivos. A rotação de chaves é manual.

Coloque o arquivo JSON da chave privada de cada conta de serviço em um diretório acessível pelos componentes híbridos da Apigee. Referencie o caminho para esses arquivos na sua overrides.yaml configuração usando as propriedades serviceAccountPath e envs[].serviceAccountPaths.

Exemplo:

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

É possível gerar e fazer o download dos arquivos de chave da conta de serviço usando a ferramenta create-service-account fornecida com a Apigee híbrida. Para mais informações, consulte create-service-account.

Armazenar chaves de conta de serviço no Vault

Integre o HashiCorp Vault para gerenciar as chaves de conta de serviço. O Vault oferece uma solução robusta para o gerenciamento de secrets, oferecendo recursos como geração dinâmica de secrets, auditoria e rotação de chaves automática. Ele exige a configuração e manutenção de uma instância do Vault.

Você precisará criar secrets, políticas e papéis separados do Vault para os componentes no nível da organização e do ambiente. Você referencia esses secrets na sua overrides.yaml configuração usando as propriedades serviceAccountSecretProviderClass e envs[].serviceAccountSecretProviderClass.

Exemplo:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

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

Consulte Armazenar chaves de conta de serviço no Vault.

Federação de Identidade da Carga de Trabalho para GKE

A federação de identidade da carga de trabalho para GKE permite que as contas de serviço do Kubernetes atuem como Google Cloud contas de serviço. Esse método elimina completamente a necessidade de arquivos de chave de conta de serviço. Em vez disso, o cluster do GKE autentica cargas de trabalho diretamente usando Google Cloud IAM. A federação de identidade da carga de trabalho para GKE oferece um mecanismo de autenticação altamente seguro e automatizado, simplificando o gerenciamento de chaves. Esse método é específico para clusters do GKE.

Esse método exige a vinculação de cada conta de serviço do Kubernetes a uma conta de serviço específica Google Cloud . O processo de instalação da Apigee híbrida cria as contas de serviço do Kubernetes específicas da instalação ao instalar os gráficos do Helm da Apigee híbrida. Ao executar o comando helm install ou helm upgrade com a flag --dry-run para cada gráfico, a saída vai incluir os comandos para vincular as contas de serviço do Kubernetes às Google Cloud contas de serviço do componente híbrido específico da Apigee nesse gráfico.

Ative a federação de identidade da carga de trabalho para GKE no arquivo overrides.yaml com a propriedade gcp.workloadIdentity.enabled.

Exemplo:

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

Consulte Ativar a federação de identidade da carga de trabalho para GKE.

Federação de identidade da carga de trabalho em plataformas que não são do GKE

A federação de identidade da carga de trabalho estende os benefícios da federação de identidade da carga de trabalho para GKE a clusters do Kubernetes em execução fora do Google Cloud, como o Serviço do Azure Kubernetes (AKS), o Amazon Elastic Kubernetes Service (EKS) ou o OpenShift. Esse método permite que o cluster que não é do GKE seja autenticado usando Google Cloud o provedor OIDC do cluster para configurar uma relação de confiança entre o provedor de identidade do cluster e o Google Cloud. Após a configuração inicial, esse método elimina a necessidade de arquivos de chave de conta de serviço.

É possível usar a federação de identidade da carga de trabalho com:

  • Arquivos de configuração de credenciais (em vez de arquivos de chave de conta de serviço)
  • Secrets do Kubernetes
  • Vault

Para usar a federação de identidade da carga de trabalho, crie arquivos de configuração de credenciais para cada Google Cloud conta de serviço. Use esses arquivos em vez de arquivos de chave de conta de serviço ou para configurar os secrets do Kubernetes ou o Vault, se você estiver usando esses métodos.

Ative a federação de identidade da carga de trabalho no arquivo overrides.yaml com as propriedades gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience e gcp.federatedWorkloadIdentity.credentialSourceFile.

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 Ativar a federação de identidade da carga de trabalho.

Escolher um método de autenticação

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

  • Para implantações do GKE, a federação de identidade da carga de trabalho para GKE oferece uma abordagem segura e simplificada. Ela remove a necessidade de gerenciar arquivos de chave de conta de serviço diretamente.
  • Para implantações do Kubernetes que não são do GKE (AKS, EKS, OpenShift), a federação de identidade da carga de trabalho oferece uma experiência de autenticação sem chave semelhante. Esse método é a opção recomendada para esses ambientes.
  • Se a federação de identidade da carga de trabalho para GKE ou a federação de identidade da carga de trabalho não forem opções, considere usar o Vault para gerenciamento e automação de chaves centralizados.
  • Para implantações mais simples ou se você não tiver uma configuração do Vault, o armazenamento de chaves em secrets do Kubernetes oferece uma solução nativa do Kubernetes. Esse método oferece melhor segurança do que o armazenamento direto de arquivos.
  • Arquivos de chave de conta de serviço direta são adequados para testes iniciais ou ambientes em que outros métodos não são viáveis. No entanto, esse método exige gerenciamento e rotação manual cuidadosos de chaves.

A seguir