Visão Geral da Segurança de Rede de Aplicações do Azure Kubernetes (pré-visualização)

Importante

Os recursos de pré-visualização do AKS estão disponíveis numa base de autosserviço e adesão voluntária. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões de teste do AKS são parcialmente cobertas pelo suporte ao cliente numa base de melhor esforço. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

A Azure Kubernetes Application Network assegura a comunicação entre serviços em clusters Azure Kubernetes Service (AKS) conectados através de TLS mútuo automático (mTLS) e autorização baseada em identidade. Emite identidades de cargas de trabalho e gere a emissão, rotação e validação de certificados para permitir uma comunicação encriptada, autenticada e explicitamente autorizada entre serviços sem configuração manual, com encriptação compatível com FIPS em trânsito.

Este artigo apresenta uma visão geral das funcionalidades de segurança na Azure Kubernetes Application Network, incluindo mTLS, identidades de carga de trabalho, gestão de certificados e políticas de autorização. Também descreve limitações e próximos passos para implementar comunicação segura no seu ambiente Azure Kubernetes Application Network.

Limitações

Os certificados são atualmente emitidos por uma autoridade certificadora gerida pela Azure Kubernetes Application Network (CA) e não estão ligados a uma CA pública.

mTLS

A Rede de Aplicações utiliza mTLS para fornecer comunicação encriptada baseada em identidade entre cargas de trabalho. Cada serviço num cluster ligado a uma Rede de Aplicações recebe automaticamente um certificado que lhe permite provar a sua identidade e estabelecer ligações encriptadas e de confiança com outros serviços na mesma Rede de Aplicações. A encriptação em trânsito utiliza a criptografia compatível com FIPS.

Estratégia de migração mTLS

Atualmente, a Rede de Aplicações permite tráfego encriptado e não encriptado. Esta abordagem garante que as cargas de trabalho existentes continuam a operar normalmente, enquanto cargas de trabalho novas ou atualizadas usam automaticamente mTLS para comunicação segura. Isto significa que pode adotar mTLS para comunicação segura entre as suas cargas de trabalho sem tempo de inatividade. Depois de concluída a migração, pode mudar para o modo estrito para que a autenticação seja imposta.

Benefícios do mTLS in Azure Kubernetes Application Network

O mTLS no Azure Kubernetes Application Network ajuda-o a:

Proteger dados em trânsito: Todo o tráfego serviço-a-serviço pode ser encriptado automaticamente (compatível com FIPS).
Verificar identidade do serviço: Cada carga de trabalho possui um certificado raiz e intermédio único gerido pela Rede de Aplicações.
Simplificar operações: A Rede de Aplicações gere a emissão, rotação e revogação de certificados para os utilizadores.

Gestão de certificados

A Azure Kubernetes Application Network fornece gestão de certificados apoiada pelo Azure Key Vault, que emite e mantém os certificados usados para o mTLS. Este serviço estabelece uma fronteira de confiança partilhada entre todos os clusters AKS ligados ao mesmo recurso de Rede de Aplicações.

A Application Network gere automaticamente todo o ciclo de vida dos certificados raiz e intermédios, incluindo provisionamento, renovação e rotação. Isto garante que as identidades das cargas de trabalho se mantêm válidas e que a comunicação se mantém segura ao longo do tempo. Não precisa de criar, armazenar ou rodar certificados manualmente.

O diagrama seguinte ilustra a hierarquia de certificados na Rede de Aplicações, mostrando como a CA raiz, as CAs intermédias e os certificados de carga de trabalho estão estruturados para estabelecer confiança entre clusters ligados:

Hierarquia de certificados e ciclo de vida

Quando um recurso de Rede de Aplicações é criado, uma CA raiz é provisionada para servir como âncora de confiança para a Rede de Aplicações. Quando um cluster AKS se junta à Rede de Aplicações como membro, a Rede de Aplicações emite um certificado intermédio para esse membro assinado pela CA raiz da Rede de Aplicações. Cada cluster AKS ligado utiliza o seu certificado intermédio gerido pela Rede de Aplicações para emitir certificados de carga de trabalho de curta duração para cargas de trabalho nesse cluster.

Todos os certificados de carga de trabalho herdam a confiança da CA raiz da Rede de Aplicações, mantendo uma fronteira de confiança unificada ao longo do recurso. A rotação dos certificados raiz e intermédios é gerida de forma transparente para os utilizadores, sem causar tempo de inatividade ou disrupções no tráfego. Esta hierarquia gerida garante uma confiança consistente e verificável em todos os clusters de uma Rede de Aplicações, mantendo automaticamente a validade de cada certificado.

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

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

Tipo de certificado	Scope	Período de validade	Período de rotação	Objetivo
Root CA	Azure Kubernetes Application Network	12 meses	6 meses	Estabelece o limite de confiança para todos os clusters ligados à Rede de Aplicações Azure Kubernetes
CA Intermédio	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 cargas de trabalho e assegura a comunicação entre serviços

Identidade da carga de trabalho e autorização

À medida que as aplicações crescem, os serviços muitas vezes precisam de comunicar de forma segura através de diferentes namespaces e ambientes dentro da mesma implementação. Gerir certificados e garantir que cada serviço pode verificar com quem está a falar pode rapidamente tornar-se complexo e propenso a erros. O Azure Kubernetes Application Network elimina esta sobrecarga ao atribuir e gerir automaticamente identidades de cargas de trabalho.

Num ambiente ligado à Rede de Aplicações, as cargas de trabalho comunicam de forma segura dentro e entre namespaces. Para garantir que cada serviço pode ser confiável e autenticado, a Rede de Aplicações atribui a cada carga de trabalho uma identidade verificável que representa o seu namespace e conta de serviço.

Cada carga de trabalho de Rede de Aplicações recebe automaticamente uma identidade única no formato SPIFFE , que inclui o seu namespace e conta de serviço. A identidade está formatada da seguinte forma:

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

Esta identidade está incorporada no certificado da carga de trabalho e é usada para provar a identidade do serviço ao comunicar com outras cargas de trabalho. A Azure Kubernetes Application Network utiliza este modelo de identidade baseado em SPIFFE com políticas de autorização Istio, para que possa definir regras claras e consistentes sobre quais os serviços autorizados a comunicar.

Definir políticas de acesso

Podes usar o Istio AuthorizationPolicies para controlar quais cargas de trabalho são permitidas a comunicar dentro do seu ambiente. Estas políticas permitem-lhe definir o acesso com base nas identidades verificadas das cargas de trabalho, em vez de localizações de rede ou endereços IP. Esta abordagem ajuda-te a impor controlos de acesso consistentes mesmo à medida que os serviços escalam e se movem entre nós. Por exemplo, pode permitir apenas gateways ou cargas de trabalho específicas de namespaces de confiança para chamar um serviço, referenciando as suas identidades SPIFFE na lista de princípios da política, como mostrado no seguinte exemplo:

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

Orientação para o desenho de políticas

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

Especifique sempre tanto o namespace como a conta de serviço para evitar acessos não intencionais entre namespace.
Use princípios para definir identidades explícitas de carga de trabalho para acesso detalhado.
Use namespaces para definir limites de confiança mais amplos quando apropriado.
Evite regras que correspondam apenas a nomes de contas de serviço sem namespaces, pois isso pode conceder acesso entre clusters ou ambientes.
Combine AuthorizationPolicies com o Kubernetes NetworkPolicies para impor isolamento tanto baseado em identidade como em rede.

Observação

A autorização da Rede de Aplicações Azure Kubernetes baseia-se na identidade verificada da carga de trabalho em vez do endereço IP. Isto assegura uma aplicação consistente mesmo à medida que as cargas de trabalho escalam de tamanho ou se deslocam entre nós.

Ao combinar identidades, certificados e controlos de políticas geridos pela Azure Kubernetes Application Network, pode implementar comunicação de serviços baseada em identidade e privilégio mínimo, garantindo tráfego autenticado, encriptado e explicitamente autorizado entre cargas de trabalho entre clusters.

Para saber mais sobre a Azure Kubernetes Application Network, consulte os seguintes artigos:

Comentários

Esta página foi útil?

Última atualização a 2026-03-23