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

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 serviços Google Cloud . Escolha um método de autenticação para essas contas de serviço que esteja alinhado aos seus requisitos operacionais e de segurança. 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 contas de serviço Google Cloud 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 Cloud Logging. Cada conta de serviço requer papéis específicos do Identity and Access Management (IAM) para realizar as funções.

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

A Apigee híbrida oferece suporte a vários métodos para autenticar 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 de plataforma Gerenciamento de chaves
Secrets do Kubernetes Secrets do cluster do Kubernetes Qualquer plataforma do Kubernetes O Kubernetes gerencia secrets e faz a rotação manual
Arquivos de chave JSON da conta de serviço Sistemas de arquivos locais Qualquer plataforma do Kubernetes Rotação e distribuição manuais
Vault HashiCorp Vault Qualquer plataforma do Kubernetes O Vault gerencia secrets e a rotação manual.
Federação de identidade da carga de trabalho para o GKE Google Cloud IAM Google Kubernetes Engine (GKE) OGoogle Cloud gerencia, sem necessidade de arquivos de chave
Federação de identidade da carga de trabalho em outras plataformas Google Cloud IAM AKS, EKS, OpenShift ou outras plataformas do Kubernetes OGoogle Cloud gerencia, sem necessidade de arquivos de chave

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

Armazene as chaves da 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 oferecem 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 propriedades serviceAccountRef e envs[].serviceAccountRefs no arquivo overrides.yaml. O Kubernetes gerencia a distribuição desses secrets para os pods adequados.

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, é necessário garantir a segurança do sistema de arquivos. A rotação de chaves é manual.

Coloque cada arquivo JSON da chave privada da conta de serviço em um diretório acessível pelos componentes do Apigee Hybrid. Faça referência ao caminho desses arquivos na configuração overrides.yaml 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 da conta de serviço. O Vault oferece uma solução robusta para gerenciamento de secrets, com recursos como geração dinâmica de secrets, auditoria e rotação automática de chaves. É necessário configurar e manter 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ê faz referência a esses segredos na configuração overrides.yaml 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 o GKE

A Federação de Identidade da Carga de Trabalho para GKE permite que as contas de serviço do Kubernetes atuem como contas de serviço do Google Cloud. Esse método elimina totalmente a necessidade de arquivos de chave de conta de serviço. Em vez disso, o cluster do GKE autentica diretamente as cargas de trabalho usando o 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 Google Cloud específica. O processo de instalação da Apigee híbrida cria as contas de serviço do Kubernetes específicas para sua instalação quando você instala os gráficos do Helm da Apigee híbrida. Quando você executa o comando helm install ou helm upgrade com a flag --dry-run para cada gráfico, a saída inclui os comandos para vincular as contas de serviço do Kubernetes às contas de serviço do Google Cloud para o componente específico da Apigee híbrida nesse gráfico.

Você ativa a federação de identidade da carga de trabalho para o 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 o 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 executados 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 se autentique no Google Cloud usando 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 da 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 conta de serviço Google Cloud . Use esses arquivos no lugar dos arquivos de chave da conta de serviço ou para configurar os secrets do Kubernetes ou o Vault, se você estiver usando esses métodos.

Você ativa 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. Isso dispensa 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 centralizados de chaves.
  • Para implantações mais simples ou se você não tiver uma configuração do Vault, armazene chaves em secrets do Kubernetes para ter uma solução nativa do Kubernetes. Esse método oferece mais 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 requer gerenciamento e rotação manuais cuidadosos das chaves.

A seguir