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 requer contas de serviço para comunicação segura com os serviços da 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 fornece uma breve visão geral das opções disponíveis.

Noções básicas sobre a autenticação da conta de serviço

A Apigee híbrida usa contas de serviço do Google Cloud para autenticar e autorizar componentes em execução no cluster do Kubernetes. Essas contas de serviço acessam recursos do Google Cloud , 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 executar as funções dela.

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 com a 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 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, rotação manual
Federação de Identidade da Carga de Trabalho para GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google 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 Google 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 podem fornecer 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 fazem referência a esses secrets usando as propriedades serviceAccountRef e envs[].serviceAccountRefs no arquivo overrides.yaml. 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, é preciso garantir 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. Faça referência ao caminho para esses 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 sua conta de serviço. O Vault oferece uma solução robusta para o gerenciamento de secrets, com recursos como geração dinâmica de secrets, auditoria e rotação automática de chaves. É preciso configurar e manter uma instância do Vault.

Você precisará criar secrets, políticas e papéis do Vault separados para os componentes no nível da organização e do ambiente. Você faz referência a esses secrets na configuração do 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 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 requer a vinculação de cada conta de serviço do Kubernetes a uma conta de serviço específica do Google Cloud . 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. 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 contas de serviço do Google Cloud para o componente específico da Apigee híbrida 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 para 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 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 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 conta de serviço do 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 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. Isso elimina a necessidade de gerenciar diretamente os arquivos de chave da conta de serviço.
  • 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 escolha 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, o armazenamento de chaves em secrets do Kubernetes oferece uma solução nativa do Kubernetes. Esse método oferece mais segurança do que o armazenamento direto de arquivos.
  • Os 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 manuais cuidadosos das chaves.

A seguir