Usar provedores de identidade externos com autenticação estruturada para o AKS (pré-visualização)

O Serviço Kubernetes do Azure (AKS) dá suporte à autenticação estruturada, que permite configurar provedores de identidade externos para autenticar usuários no servidor de API do Kubernetes. Esta funcionalidade baseia-se na configuração de autenticação estruturada "upstream" do Kubernetes. O AKS implementa essa funcionalidade por meio de autenticadores JSON Web Token (JWT) que validam tokens de provedores de identidade externos de acordo com sua configuração. Com autenticação estruturada, as organizações podem integrar o AKS com a sua infraestrutura de identidade existente para além do Microsoft Entra ID.

Este artigo apresenta uma visão geral de como utilizar fornecedores externos de identidade com autenticação estruturada AKS, incluindo conceitos-chave, considerações de segurança e os próximos passos para a configuração.

Benefícios da autenticação de fornecedor de identidade externo

A autenticação estruturada estende o AKS além da integração tradicional do Microsoft Entra ID, oferecendo suporte a provedores de identidade OpenID Connect (OIDC) padrão do setor. Esta funcionalidade permite-lhe:

• Autentique os utilizadores com fornecedores externos de identidade como Google, GitHub ou qualquer fornecedor compatível com o OIDC.
• Mantenha uma gestão centralizada de identidade em toda a sua organização.
• Implementar regras personalizadas de validação de reivindicações e mapeamento de utilizadores.
• Suportar múltiplos fornecedores de identidade simultaneamente num único cluster.

Fluxo de autenticação de fornecedor de identidade externo

Quando um utilizador tenta aceder ao servidor API Kubernetes usando autenticação estruturada com um fornecedor externo de identidade, o fluxo de autenticação e autorização é o seguinte:

• Autenticação: as seguintes etapas validam a identidade do usuário:
  • Apresentação do token: O utilizador apresenta um token JWT do seu fornecedor de identidade configurado.
  • Validação do token: O servidor API valida a assinatura, o emissor, a audiência e a expiração do token.
  • Processamento de sinistros: São aplicadas regras personalizadas de validação de reivindicações para garantir que o token cumpre os seus requisitos.
  • Mapeamento de utilizadores: As reivindicações são mapeadas para a identidade do utilizador Kubernetes (nome de utilizador, grupos e atributos extra).
• Autorização: O Kubernetes RBAC (Role-Based Access Control) padrão determina as ações que o utilizador autenticado pode executar.

Fornecedores de identidade suportados

Embora a autenticação estruturada do AKS permita fornecedores de identidade compatíveis com OIDC, os fornecedores comuns incluem:

• GitHub: Autenticar usando identidades GitHub ou GitHub Actions.
• Google OAuth 2.0: Use contas Google para autenticação.
• Fornecedores OIDC genéricos: Qualquer fornecedor que implemente padrões OIDC.
• Soluções de identidade personalizadas: Implementações OIDC específicas da organização.

Requisitos para fornecedores externos de identidade

Os fornecedores externos de identidade devem cumprir os seguintes requisitos para trabalhar com autenticação estruturada AKS:

• Apoiem os padrões OIDC.
• Fornecer endpoints de descoberta OIDC que sejam acessíveis publicamente.
• Emitir tokens JWT com reivindicações apropriadas.
• Seja acessível a partir dos nós do cluster AKS para validação de tokens.

Autenticadores JWT para autenticação estruturada AKS

Um autenticador JWT é um objeto de configuração que define como o AKS valida e processa tokens de um fornecedor de identidade externo. Por exemplo, o AKS espera um token ID (JWT) cuja aud reivindicação (audiência) corresponda ao valor de audiência que configura para o autenticador, como "my-api", ou um ID de cliente OAuth. Cada autenticador JWT inclui os seguintes componentes:

• Configuração do emissor: Especifica o URL do emissor OIDC e os valores esperados de audiência para tokens.
• Regras de validação de reivindicações: Utiliza expressões CEL (Common Expression Language) para impor lógica de validação personalizada nas reivindicações de token.
• Mapeamentos de reivindicações: Define como as reivindicações JWT são mapeadas para atributos de utilizador do Kubernetes, como nome de utilizador, grupos e campos extra.
• Regras de validação do utilizador: Aplica lógica de validação extra após o mapeamento das reivindicações para restringir ou permitir o acesso adicional.

Expressões CEL para validação e mapeamento de reivindicações

A autenticação estruturada utiliza expressões CEL para validação e mapeamento flexíveis de reivindicações. O CEL fornece um ambiente sandbox seguro para avaliar lógica personalizada contra reivindicações JWT.

Exemplos de expressões CEL:

// Validate that the 'sub' claim exists
has(claims.sub)

// Map username with AKS prefix
'aks:jwt:' + claims.sub

// Map groups from comma-separated string
claims.groups.split(',').map(g, 'aks:jwt:' + g)

// Conditional mapping based on claim verification
'aks:jwt:' + (claims.email_verified ? claims.email : claims.sub)

Práticas recomendadas de segurança

Tenha em mente as seguintes melhores práticas de segurança ao utilizar fornecedores externos de identidade com autenticação estruturada AKS:

• Use validação forte de declarações: implemente regras de validação abrangentes para garantir que apenas tokens autorizados sejam aceitos.
• Limitar o escopo do token: configure seu provedor de identidade para emitir tokens com o mínimo de declarações necessárias.
• Rotação regular: Alterne segredos e certificados do cliente regularmente.
• Monitorar acesso: habilite logs de recursos e ative kube-apiserver logs para inspecionar possíveis problemas com os autenticadores JWT configurados e rastrear eventos de autenticação.
• Configurações de teste: Valide primeiro a configuração do autenticador JWT num ambiente não produtivo.

Considerações de segurança

Tenha em mente as seguintes considerações de segurança ao utilizar fornecedores externos de identidade com autenticação estruturada AKS:

• Requisitos de prefixo: Todos os nomes de utilizador e grupos mapeados através de autenticação estruturada devem ser prefixados com aks:jwt: para evitar conflitos com outros métodos de autenticação e contas do sistema.
• Acesso à rede: Os endpoints do fornecedor de identidade devem ser acessíveis a partir de:
  • Nós de cluster AKS para validação de tokens.
  • Sistemas clientes para aquisição de tokens.
  • Quaisquer caminhos de rede envolvidos no fluxo de autenticação.
• Camadas de validação: A autenticação estruturada fornece múltiplas camadas de validação:
  • A validação da assinatura do token assegura a autenticidade do token.
  • A validação padrão das reivindicações verifica o emissor, o público e a expiração.
  • A validação personalizada de reivindicações aplica-se aos requisitos específicos da sua organização.
  • Verificações finais de validação do utilizador após o mapeamento da reclamação.

Conteúdo relacionado

Para mais informações sobre autenticação estruturada e funcionalidades relacionadas, consulte os seguintes recursos:

• Configurar autenticação estruturada para AKS
• Configuração de autenticação estruturada do Kubernetes
• Expressões CEL no Kubernetes
• Especificação do OpenID Connect