Conceitos de segurança para aplicativos e clusters no AKS (Serviço de Kubernetes do Azure)

A segurança do contêiner protege todo o pipeline de ponta a ponta da compilação às cargas de trabalho do aplicativo em execução no Serviço de Kubernetes do Azure (AKS).

A cadeia de fornecimento seguro inclui o ambiente e o registro de compilação.

O Kubernetes inclui componentes de segurança, como padrões de segurança pod e Segredos. Azure inclui componentes como Microsoft Entra ID, Microsoft Defender para contêineres, Azure Policy, Azure Key Vault, grupos de segurança de rede e atualizações de cluster orquestradas. O AKS combina esses componentes de segurança para:

  • Forneça uma história completa de autenticação e autorização.
  • Aplique as políticas internas do Azure Policy no AKS para proteger suas aplicações.
  • Visibilidade de ponta a ponta, da compilação ao seu aplicativo com o Microsoft Defender para Contêineres.
  • Manter o cluster AKS executando as atualizações de segurança do sistema operacional mais recentes e as versões do Kubernetes.
  • Fornecer tráfego de pod seguro e acesso a credenciais confidenciais.

O AKS dá suporte a dois modos de cluster: AKS Automatic e AKS Standard. Os conceitos de segurança neste artigo se aplicam a ambos os modos, a menos que seja observado de outra forma. O AKS Automatic inclui uma linha de base de segurança protegida com vários controles pré-configurados por padrão, enquanto o AKS Standard fornece mais flexibilidade de configuração.

Este artigo apresenta os conceitos básicos que protegem seus aplicativos no AKS.

Importante

A partir de 30 de novembro de 2025, AKS (Serviço de Kubernetes do Azure) não dá mais suporte ou fornece atualizações de segurança para Azure Linux 2.0. A imagem do nó Azure Linux 2.0 está congelada na versão 202512.06.0. A partir de 31 de março de 2026, as imagens dos nós serão removidas e você não poderá dimensionar os pools de nós. Migre para uma versão do Linux Azure com suporte atualizando seus pools de nós para uma versão do Kubernetes com suporte ou migrando para osSku AzureLinux3. Para obter mais informações, consulte Problema de desativação do GitHub e o comunicado de desativação das Atualizações do Azure. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de versão do AKS.

Segurança de build

A segurança de build é o ponto de entrada para sua cadeia de suprimentos segura. Antes que as imagens sejam promovidas a ambientes de implantação, execute a análise estática e a avaliação de vulnerabilidade e conformidade na CI.

Em ambos os modos do AKS, use a triagem baseada em risco em vez de bloquear todos os builds por causa de qualquer vulnerabilidade. Priorize a correção com base no status do fornecedor e na gravidade, e aplique períodos de carência para exceções não exploráveis ou com prazo determinado.

O AKS Automatic ajuda a reduzir o desvio de configuração em etapas posteriores ao iniciar os clusters a partir de uma linha de base reforçada, com controles de segurança pré-configurados. Isso torna a validação, durante a build, da qualidade da imagem e da conformidade com as políticas ainda mais importante, porque imagens confiáveis são promovidas com mais consistência para uma linha de base segura de execução.

O AKS Standard oferece mais flexibilidade em nível de cluster; portanto, os pipelines de compilação devem aplicar explicitamente o padrão mínimo da sua organização para a origem das imagens, os limites de vulnerabilidade e os controles de política antes da implantação.

Segurança do Registro

A segurança do registro verifica se apenas imagens confiáveis e em conformidade estão disponíveis para implantação e ajuda a detectar desvios após a compilação. Avalie o estado de vulnerabilidade da imagem no registro continuamente, não apenas no momento da compilação. A verificação do registro detecta vulnerabilidades recém-divulgadas e imagens que contornaram os processos de build aprovados. Use a assinatura e a verificação de imagens, como Notary V2, para garantir que as cargas de trabalho sejam implantadas a partir de fontes confiáveis com proveniência verificável.

No AKS Automatic, em que vários recursos de segurança de runtime são pré-configurados, os controles de registro continuam sendo uma barreira crítica na etapa inicial para manter limpa a cadeia de suprimentos do runtime. Para o AKS Standard, aplique os mesmos controles do registro e alinhe-os com a configuração de admissão e de políticas do cluster para garantir o uso de imagens confiáveis de forma consistente.

Segurança de cluster

No AKS, os componentes primários do Kubernetes fazem parte do serviço gerenciado fornecido, gerenciado e mantido por Microsoft. Cada cluster do AKS tem seu próprio plano de controle primário do Kubernetes, dedicado a um único locatário, para fornecer o Servidor da API, o Agendador etc. Para obter mais informações, consulte Gerenciamento de vulnerabilidades do Serviço de Kubernetes do Azure.

Por padrão, o servidor de API do Kubernetes usa um endereço IP público e um FQDN (nome de domínio totalmente qualificado). Você pode limitar o acesso ao ponto de extremidade do servidor da API usando intervalos de IP autorizados. Você também pode criar um cluster particular para limitar o acesso do servidor de API à sua rede virtual.

Para o AKS Automatic, a integração de rede virtual do servidor de API é pré-configurada como parte da postura de segurança padrão. No AKS Standard, a mesma funcionalidade está disponível e pode ser habilitada com base em seus requisitos de design de rede e segurança.

Você pode controlar o acesso ao servidor de API usando o controle de acesso baseado em função do Kubernetes (Kubernetes RBAC) e o Azure RBAC. No AKS Automatic, o Azure RBAC para autorização do Kubernetes vem pré-configurado. No AKS Standard, você pode escolher e configurar o modelo de autorização que melhor se adapta ao seu ambiente. Para obter mais informações, consulte integração do Microsoft Entra com o AKS.

Configurações padrão automáticas de segurança do AKS

O AKS Automatic inclui uma linha de base protegida com controles de segurança pré-configurados por padrão, incluindo:

  • Azure RBAC para Autorização do Kubernetes
  • Integração de rede virtual do servidor de API
  • Identidade da carga de trabalho e emissor OIDC
  • Proteções de implantação e Padrões básicos de segurança de Pod em modo de imposição
  • Limpador de imagem para remover imagens vulneráveis não usadas
  • Restrições de segurança para pools de nós de sistema gerenciados que preservam os limites entre as cargas de trabalho dos clientes e a infraestrutura gerenciada pelo AKS

O AKS Standard dá suporte a esses recursos com maior flexibilidade de implementação, mas eles podem exigir habilitação explícita e gerenciamento operacional.

Segurança do nó

Os nós do AKS são máquinas virtuais (VMs) do Azure. No AKS Standard, você gerencia a configuração do pool de nós e as opções de ciclo de vida. No AKS Automatic, o AKS gerencia para você os pools de nós do sistema e os componentes centrais do sistema, incluindo dimensionamento e atualizações, com restrições de segurança para a infraestrutura gerenciada do sistema.

Os nós do Linux executam versões otimizadas do Ubuntu ou Azure Linux. Os nós do Windows Server executam uma versão otimizada do Windows Server usando o ambiente de execução de contêiner containerd.

Quando um cluster do AKS é criado ou dimensionado, os nós são implantados automaticamente com as configurações e atualizações de segurança do sistema operacional mais recentes.

Observação

Clusters do AKS em execução:

  • Kubernetes versão 1.19 e posteriores: os pools de nós do Linux usam containerd como ambiente de execução de contêineres. Pools de nós do Windows Server 2019 e Windows Server 2022 usam containerd como seu ambiente de execução de contêiner. Para obter mais informações, consulte Adicionar um pool de nós do Windows Server com containerd.
  • Kubernetes versão 1.19 e anteriores: os conjuntos de nós do Linux usam o Docker como ambiente de execução de contêineres.

Para obter mais informações sobre o processo de atualização de segurança para nós de trabalho do Linux e do Windows, consulte Security patching nodes.

Os clusters do AKS que executam VMs Azure Geração 2 incluem suporte para Trusted Launch. Esse recurso protege contra técnicas de ataque avançadas e persistentes combinando tecnologias que você pode habilitar de forma independente, como inicialização segura e uma versão virtualizada do módulo de plataforma confiável (vTPM). Os administradores podem implantar nós de trabalho do AKS com carregadores de inicialização verificados e assinados, kernels do sistema operacional e drivers para garantir a integridade de toda a cadeia de inicialização da VM subjacente.

Opções de sistema operacional otimizado para contêiner e segurança

Azure ACL (Container Linux) é um sistema operacional imutável com otimização de contêiner para AKS. ACL deriva do projeto Flatcar Container Linux e se baseia na arquitetura imutável comprovada da Flatcar, voltada a contêineres, ao mesmo tempo que incorpora em camadas os pacotes, a manutenção e a integração de plataforma do Azure Linux. Isso permite que a ACL permaneça em estreita sintonia com as inovações upstream do Flatcar, ao mesmo tempo em que atende aos requisitos de produção, segurança e conformidade do Azure. Para saber mais sobre o Flatcar Container Linux, consulte a documentação do Flatcar.

ACL está em disponibilidade geral (GA) como opção de sistema operacional no AKS a partir do AKS v1.34. Você pode implantar pools de nós de ACL em um novo cluster do AKS, adicionar pools de nós de ACL aos clusters existentes e migrar pools de nós do Linux existentes para ACL.

Para obter mais informações sobre ACL, consulte visão geral do Azure Container Linux (ACL) para AKS.

Autorização de nó

A autorização de nó é um modo de autorização kubelet de finalidade especial que autoriza especificamente solicitações de API kubelet para proteger contra ataques east-west. A autorização de nó está habilitada por padrão no AKS 1.24 + clusters.

Implantação de nó

Os nós são implantados em uma sub-rede de rede virtual privada, sem nenhum endereço IP público atribuído. Para fins de solução de problemas e gerenciamento, o SSH é habilitado por padrão e só pode ser acessado usando o endereço IP interno. O recurso de desabilitar o SSH durante a criação do pool de nós e de clusters ou para um cluster ou pool de nós existentes está em versão prévia. Confira Gerenciar o acesso por SSH para obter mais informações.

Armazenamento do nó

Para fornecer armazenamento, os nós usam Azure Managed Disks. Para a maioria dos tamanhos de nó de VM, os Azure Managed Disks são discos Premium apoiados por SSDs de alto desempenho. Os dados armazenados em discos gerenciados são criptografados automaticamente em repouso na plataforma Azure. Para melhorar a redundância, Azure Managed Disks são replicados com segurança no datacenter Azure.

Cargas de trabalho multilocatários hostis

Atualmente, os ambientes do Kubernetes não são seguros para uso hostil multilocatário. Recursos de segurança adicionais, como as Políticas de Segurança de Pod ou RBAC do Kubernetes para nós, bloqueiam explorações com eficiência. Para a segurança verdadeira ao executar cargas de trabalho multilocatários hostis, confie apenas em um hipervisor. O domínio de segurança para o Kubernetes se torna o cluster inteiro, não um nó individual.

Para esses tipos de cargas de trabalho multilocatário hostis, você deve usar clusters fisicamente isolados. Para obter mais informações sobre formas de isolar as cargas de trabalho, confira Melhores práticas para o isolamento de cluster no AKS.

Isolamento de computação

Determinadas cargas de trabalho podem exigir um alto grau de isolamento de outras cargas de trabalho do cliente devido aos requisitos normativos ou de conformidade. Para essas cargas de trabalho, Azure fornece:

  • Contêineres isolados do kernel a serem usados como nós de agente em um cluster do AKS. Esses contêineres são completamente isolados para um tipo de hardware específico e isolados da malha do Host do Azure, do sistema operacional host e do hipervisor. Eles são dedicados a um único cliente. Selecione um dos tamanhos de VMs isoladas como o tamanho do nó ao criar um cluster AKS ou adicionar um pool de nós.
  • Contêineres Confidenciais (versão prévia), também baseados em Contêineres Confidenciais kata, criptografam a memória do contêiner e impedem que os dados na memória durante a computação fiquem em texto claro, formato legível e adulteração. Ele ajuda a isolar seus contêineres de outros grupos de contêineres/pods e do kernel do sistema operacional do nó da VM. Contêineres Confidenciais (versão prévia) usam a criptografia de memória baseada em hardware (SEV-SNP).
  • O Pod Sandboxing (versão prévia) fornece um limite de isolamento entre o aplicativo contêiner e os recursos compartilhados de kernel e computação (CPU, memória e rede) do host do contêiner.

Segurança de rede

Para conectividade e segurança com redes locais, você pode implantar seu cluster do AKS em sub-redes de rede virtual Azure existentes. Essas redes virtuais se conectam de volta à rede local usando a VPN do Azure Site a Site ou a Rota Expressa. Defina controladores de entrada do Kubernetes com endereços IP privados e internos para limitar o acesso de serviços à conexão de rede interna.

No AKS Automatic, os recursos de rede virtual gerenciada e os padrões de entrada e saída principais são pré-configurados para fornecer uma linha de base segura. No AKS Standard, os modelos de rede e os controles de saída/entrada são mais flexíveis e devem ser selecionados com base em sua arquitetura de segurança.

Grupos de segurança de rede do Azure

Para filtrar o fluxo de tráfego de rede virtual, Azure usa regras de grupo de segurança de rede. Essas regras definem os intervalos de IP de origem e destino, portas e protocolos que têm ou não têm acesso aos recursos. Regras padrão são criadas para permitir o tráfego TLS para o servidor de API do Kubernetes. Você cria serviços com balanceadores de carga, mapeamentos de porta ou rotas de entrada. O AKS modifica automaticamente o grupo de segurança de rede para o fluxo de tráfego.

Se você fornecer sua própria sub-rede para o cluster do AKS (usando Azure CNI ou Kubenet), não modifique o grupo de segurança de rede no nível do NIC gerenciado pelo AKS. Em vez disso, crie mais grupos de segurança de rede no nível da sub-rede para modificar o fluxo de tráfego. Certifique-se de que eles não interfiram no gerenciamento de tráfego necessário do cluster, como o acesso ao balanceador de carga, a comunicação com o painel de controle ou a saída.

Política de rede do Kubernetes

Para limitar o tráfego de rede entre pods em seu cluster, o AKS oferece suporte para políticas de rede do Kubernetes. Com as políticas de rede, você pode optar por permitir ou negar os caminhos de rede específicos no cluster, com base em namespaces e seletores de rótulo.

Segurança do aplicativo

Para proteger os pods em execução no AKS, considere usar o Microsoft Defender para Contêineres para detectar e restringir ataques cibernéticos contra seus aplicativos. Execute a verificação contínua para detectar descompasso no estado de vulnerabilidade do seu aplicativo e implemente um processo "azul/verde/canário" para corrigir e substituir as imagens vulneráveis.

No AKS Automatic, a identidade da carga de trabalho e o emissor do OIDC são pré-configurados para simplificar o acesso seguro à carga de trabalho para serviços de Azure. No AKS Standard, esses recursos estão disponíveis e podem ser habilitados como parte de sua postura de segurança de linha de base.

Proteger o acesso do contêiner a recursos

Da mesma forma que deve conceder a usuários ou grupos os privilégios mínimos necessários, você também deve limitar os contêineres apenas às ações e aos processos necessários. Para minimizar o risco de ataques, evite configurar aplicativos e contêineres que exijam privilégios elevados ou acesso à raiz. Recursos internos de segurança do Linux, como AppArmor e seccomp , são recomendados como práticas recomendadas para proteger o acesso de contêiner aos recursos.

Segredos do Kubernetes

Um Segredo do Kubernetes é usado para injetar dados confidenciais em pods, como chaves ou credenciais de acesso.

  1. Crie um Segredo usando a API do Kubernetes.
  2. Defina o pod ou a implantação e solicite um Segredo específico.
    • Os segredos só são fornecidos a nós com um pod agendado que os exige.
    • O Segredo é armazenado em tmpfs, não gravado em disco.
  3. Quando você exclui o último pod em um nó que exige um Segredo, o Segredo é excluído do tmpfs do nó.
    • Os segredos são armazenados dentro de um determinado namespace e só podem ser acessados de pods que estão no mesmo namespace.

O uso de Segredos reduz as informações confidenciais definidas no manifesto YAML do pod ou do serviço. Em vez disso, você pode solicitar o Segredo armazenado no servidor de API do Kubernetes como parte do seu manifesto YAML. Essa abordagem fornece apenas ao pod específico acesso ao Segredo.

Observação

Os arquivos de manifesto secreto bruto contêm os dados secretos no formato base64. Para obter mais informações, confira a documentação oficial. Trate esses arquivos como informações confidenciais e nunca os registre no controle do código-fonte.

Os segredos do Kubernetes são armazenados no etcd, um armazenamento de chave-valor distribuído. O AKS permite a criptografia em repouso de segredos no etcd usando chavesgerenciadas pelo cliente.

Conteúdo relacionado

Para começar a proteger seus clusters do AKS, confira Atualizar um cluster do AKS.

Se você estiver avaliando configurações padrão específicas de cada modo e responsabilidades operacionais, consulte O que é o AKS (Serviço de Kubernetes do Azure) Automatic?

Para obter as práticas recomendadas associadas, confira Práticas recomendadas de segurança e atualizações de cluster no AKS e Práticas recomendadas de segurança de pod no AKS.

Para saber mais sobre os principais conceitos do Kubernetes e do AKS, confira:

  • Last updated on