Visão geral da segurança da Rede de Aplicativos do Kubernetes do Azure (versão prévia)

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

A Rede de Aplicativos kubernetes do Azure protege a comunicação entre serviços em clusters conectados do AKS (Serviço de Kubernetes do Azure) por meio de TLS mútuo automático (mTLS) e autorização baseada em identidade. Emite identidades de cargas de trabalho e gerencia a emissão, a rotação e a validação de certificados para habilitar a comunicação criptografada, autenticada e explicitamente autorizada de serviço a serviço, sem configuração manual, com criptografia compatível com FIPS em trânsito.

Este artigo fornece uma visão geral dos recursos de segurança na Rede de Aplicativos kubernetes do Azure, incluindo mTLS, identidades de carga de trabalho, gerenciamento de certificados e políticas de autorização. Ele também descreve as limitações e as próximas etapas para implementar a comunicação segura em seu ambiente de Rede de Aplicativos do Kubernetes do Azure.

Limitações

Atualmente, os certificados são emitidos por uma AC (autoridade de certificação gerenciada por rede de aplicativos) do Azure Kubernetes e não são encadeados a uma AC pública.

mTLS

A Rede de Aplicativos usa mTLS para fornecer comunicação criptografada baseada em identidade entre cargas de trabalho. Cada serviço em um cluster conectado da Rede de Aplicativos recebe automaticamente um certificado que permite que ele prove sua identidade e estabeleça conexões criptografadas confiáveis com outros serviços na mesma Rede de Aplicativos. A criptografia em trânsito usa criptografia compatível com FIPS.

Estratégia de migração do mTLS

Atualmente, a Rede de Aplicativos permite tráfego criptografado e não criptografado. Essa abordagem garante que as cargas de trabalho existentes continuem operando normalmente enquanto cargas de trabalho novas ou atualizadas usam automaticamente o mTLS para comunicação segura. Isso significa que você pode adotar o mTLS para comunicação segura em suas cargas de trabalho sem tempo de inatividade. Depois que a migração for concluída, você poderá alterar para o modo estrito para que a autenticação seja imposta.

Benefícios do mTLS na Rede de Aplicativos kubernetes do Azure

O mTLS na Rede de Aplicativos kubernetes do Azure ajuda você a:

Proteger dados em trânsito: todo o tráfego serviço a serviço pode ser criptografado automaticamente (em conformidade com FIPS).
Verificar a identidade do serviço: cada carga de trabalho tem uma raiz gerenciada pela rede de aplicativo exclusiva e um certificado intermediário.
Simplificar operações: a Rede de Aplicativos manipula a emissão, rotação e revogação de certificados para os usuários.

Gerenciamento de certificados

A Rede de Aplicativos kubernetes do Azure fornece gerenciamento de certificados apoiado pelo Azure Key Vault que emite e mantém os certificados usados para mTLS. Esse serviço estabelece um limite de confiança compartilhada em todos os clusters do AKS conectados ao mesmo recurso de Rede de Aplicativos.

A Rede de Aplicativos gerencia automaticamente todo o ciclo de vida do certificado para certificados raiz e intermediários, incluindo provisionamento, renovação e rotação. Isso garante que as identidades da carga de trabalho permaneçam válidas e a comunicação permaneça segura ao longo do tempo. Você não precisa criar, armazenar ou girar certificados manualmente.

O diagrama a seguir ilustra a hierarquia de certificados na Rede de Aplicativos, mostrando como as AC raiz, as ACs intermediárias e os certificados de carga de trabalho são estruturados para estabelecer a confiança entre clusters conectados:

Hierarquia de certificados e ciclo de vida

Quando um recurso de Rede de Aplicativo é criado, uma AC raiz é provisionada para servir como âncora de confiança para a Rede de Aplicativos. Quando um cluster do AKS ingressa na Rede de Aplicativos como membro, a Rede de Aplicativos emite um certificado intermediário para esse membro assinado pela AC raiz da Rede de Aplicativos. Cada cluster do AKS conectado usa seu certificado intermediário gerenciado pela Rede de Aplicativos para emitir certificados de carga de trabalho de curta duração para cargas de trabalho nesse cluster.

Todos os certificados de workload herdam a confiança da CA raiz da rede de aplicações, mantendo um limite de confiança unificado por todo o recurso. A rotação dos certificados raiz e intermediários é realizada de forma transparente para os usuários, sem causar qualquer tempo de inatividade ou interrupções no tráfego. Essa hierarquia gerenciada garante uma confiança consistente e verificável em todos os clusters em uma Rede de Aplicativos, mantendo automaticamente a validade de cada certificado.

Em qualquer cluster membro, você pode obter o certificado de CA raiz do mapa de configuração istio-root-cert no namespace applink-system.

Tipos de certificado e períodos de rotação

Tipo de certificado	Âmbito	Período de validade	Período de rotação	Purpose
CA raiz	Rede de Aplicativos Kubernetes do Azure	12 meses	6 meses	Estabelece o limite de confiança para todos os clusters conectados à Rede de Aplicativos kubernetes do Azure
AC intermediária	Cluster	90 dias	45 dias	Emite certificados de carga de trabalho para cargas de trabalho dentro desse cluster
Certificado de carga de trabalho	Carga de Trabalho	24 horas	12 horas	Autentica tarefas e assegura a comunicação entre serviços

Autorização e identidade de carga de trabalho

À medida que os aplicativos crescem, os serviços geralmente precisam se comunicar com segurança em diferentes namespaces e ambientes dentro da mesma implantação. Gerenciar certificados e garantir que cada serviço possa verificar com quem ele está conversando pode rapidamente se tornar complexo e propenso a erros. A Rede de Aplicativos kubernetes do Azure elimina essa sobrecarga atribuindo e gerenciando automaticamente identidades de carga de trabalho.

Em um ambiente conectado à Rede de Aplicativos, as cargas de trabalho se comunicam com segurança dentro e entre namespaces. Para garantir que cada serviço possa ser confiável e autenticado, a Rede de Aplicativos atribui a cada carga de trabalho uma identidade verificável que representa seu namespace e sua conta de serviço.

Cada carga de trabalho da Rede de Aplicativos recebe automaticamente uma identidade exclusiva no formato SPIFFE , que inclui seu namespace e conta de serviço. A identidade é formatada da seguinte maneira:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Essa identidade é inserida no certificado de carga de trabalho e é usada para provar a identidade do serviço ao se comunicar com outras cargas de trabalho. A Rede de Aplicativos kubernetes do Azure usa esse modelo de identidade baseado em SPIFFE com políticas de autorização istio para que você possa definir regras claras e consistentes para as quais os serviços têm permissão para se comunicar.

Definir políticas de acesso

Você pode usar o Istio AuthorizationPolicies para controlar quais cargas de trabalho têm permissão para se comunicar em seu ambiente. Essas políticas permitem definir o acesso com base em identidades de carga de trabalho verificadas em vez de locais de rede ou endereços IP. Essa abordagem ajuda você a impor controles de acesso consistentes, mesmo conforme os serviços escalam e se movem entre nós. Por exemplo, você pode permitir que apenas gateways ou cargas de trabalho específicos de namespaces confiáveis chamem um serviço referenciando as identidades SPIFFE na lista de entidades de serviço da política, conforme mostrado no exemplo a seguir:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Diretrizes de design de política

Ao criar políticas de autorização, tenha em mente as seguintes práticas recomendadas:

Sempre especifique o namespace e a conta de serviço para impedir o acesso não intencional entre namespaces.
Use princípios para definir identidades de carga de trabalho explícita para acesso detalhado.
Use namespaces para definir limites de confiança mais amplos quando apropriado.
Evite regras que correspondam apenas a nomes de conta de serviço sem namespaces, pois isso pode conceder acesso entre clusters ou ambientes.
Combine AuthorizationPolicies com o Kubernetes NetworkPolicies para impor o isolamento baseado em identidade e de rede.

Observação

A autorização da Rede de Aplicativo do Kubernetes do Azure baseia-se na identidade da carga de trabalho verificada em vez do endereço IP. Isso garante a aplicação consistente, mesmo quando as cargas de trabalho são escaladas ou transferidas entre nós.

Combinando identidades, certificados e controles de política gerenciados pela Rede de Aplicativos do Kubernetes do Azure, você pode implementar a comunicação de serviço baseada em identidade, com privilégios mínimos, garantindo o tráfego autenticado, criptografado e explicitamente autorizado entre cargas de trabalho entre clusters.

Para saber mais sobre a Rede de Aplicativos kubernetes do Azure, confira os seguintes artigos:

Comentários

Esta página foi útil?

Última atualização em 2026-03-25