Conceitos de segurança para aplicações e clusters no Azure Kubernetes Service (AKS)

A segurança do contêiner protege todo o pipeline de ponta a ponta, desde a compilação até as cargas de trabalho do aplicativo em execução no Serviço Kubernetes do Azure (AKS).

O Secure Supply Chain inclui o ambiente de construção e o registro.

O Kubernetes inclui componentes de segurança, como padrões de segurança de pod e Segredos. O Azure inclui componentes como Ative Directory, Microsoft Defender for Containers, 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 a Política do Azure incorporada do AKS para proteger as suas aplicações.
• Visão de ponta a ponta desde a compilação até seu aplicativo com o Microsoft Defender for Containers.
• Mantenha seu cluster AKS executando as atualizações de segurança mais recentes do sistema operacional e as versões do Kubernetes.
• Forneça tráfego de pod seguro e acesso a credenciais confidenciais.

Este artigo apresenta os principais conceitos que protegem seus aplicativos no AKS.

Construa Segurança

Como ponto de entrada para a cadeia de suprimentos, é importante realizar análises estáticas de compilações de imagens antes que elas sejam promovidas no pipeline. Isso inclui a avaliação de vulnerabilidade e conformidade. Não se trata de falhar uma compilação porque ela tem uma vulnerabilidade, pois isso quebra o desenvolvimento. Trata-se de analisar o Status do Fornecedor para segmentar com base em vulnerabilidades acionáveis pelas equipas de desenvolvimento. Use também os Períodos de carência para permitir que os desenvolvedores tenham tempo para corrigir problemas identificados.

Segurança do Registo

A avaliação do estado de vulnerabilidade da imagem no Registro deteta desvios e também captura imagens que não vieram do seu ambiente de compilação. Use o Notary V2 para anexar assinaturas às suas imagens para garantir que as implementações provenham de um local confiável.

Segurança do cluster

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

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

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. Para obter mais informações, consulte Integração do Microsoft Entra com o AKS.

Segurança do Node

Os nós AKS são máquinas virtuais (VMs) do Azure que você gerencia e mantém.

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

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

Para obter mais informações sobre o processo de atualização de segurança nos nós de trabalho em Windows e Linux, consulte Patch de segurança dos nós.

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

Autorização do nó

A autorização de nó é um modo de autorização de finalidade especial que autoriza especificamente solicitações de API kubelet para proteção contra ataques Leste-Oeste. A autorização de nó é ativada como padrão em clusters AKS 1.24 +.

Implantação de nó

Os nós são implantados em uma sub-rede de rede virtual privada, sem endereços IP públicos atribuídos. 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. A desativação do SSH durante a criação do cluster e do pool de nós, ou para um cluster ou pool de nós existente, está em modo de pré-visualização. Consulte Gerenciar acesso SSH para obter mais informações.

Armazenamento de nós

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

Cargas de trabalho multilocatárias hostis

Atualmente, os ambientes Kubernetes não são seguros para uso multilocatário hostil. Recursos de segurança extras, como Políticas de Segurança do Pod ou RBAC do Kubernetes para nós, bloqueiam explorações de forma eficiente. Para uma verdadeira segurança ao executar cargas de trabalho multilocatárias hostis, confie apenas em um hipervisor. O domínio de segurança para Kubernetes passa a incluir todo o cluster, não um nó individual.

Para cargas de trabalho multilocatárias hostis deste tipo, deve-se usar clusters fisicamente isolados. Para obter mais informações sobre maneiras de isolar cargas de trabalho, consulte Práticas recomendadas para isolamento de cluster no AKS.

Isolamento de computação

Devido a requisitos de conformidade ou regulamentares, certas cargas de trabalho podem exigir um alto grau de isolamento de outras cargas de trabalho de clientes. Para essas cargas de trabalho, o Azure fornece:

• Contentores isolados do kernel para usar como nós de agente num cluster AKS. Esses contentores estão completamente isolados num tipo específico de hardware e isolados da infraestrutura do Host do Azure, do sistema operativo do 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.
• Confidential Containers (visualização), também baseado em Kata Confidential Containers, criptografa a memória do contêiner e impede que os dados na memória durante a computação estejam em texto claro, formato legível ou sejam adulterados. Ele ajuda a isolar seus contêineres de outros grupos/pods de contêineres, bem como do kernel do sistema operacional do nó da VM. Contêineres Confidenciais (visualização) usam criptografia de memória baseada em hardware (SEV-SNP).
• O Pod Sandboxing (visualização ) fornece um limite de isolamento entre o aplicativo de contêiner e o kernel compartilhado e os recursos de computação (CPU, memória e rede) do host do contêiner.

Segurança da rede

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

Grupos de segurança de rede do Azure

Para filtrar o fluxo de tráfego de rede virtual, o Azure usa regras de grupo de segurança de rede. Essas regras definem os intervalos de IP de origem e destino, portas e protocolos de acesso permitido ou negado aos recursos. As 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, mapeamento de portas ou rotas de ingresso. 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 seu cluster AKS (seja usando o Azure CNI ou Kubenet), não modifique o grupo de segurança de rede de nível NIC gerenciado pelo AKS. Em vez disso, crie mais grupos de segurança de rede ao nível da sub-rede para modificar o fluxo de tráfego. Certifique-se de que eles não interfiram com o tráfego necessário gerenciando o cluster, como acesso ao balanceador de carga, comunicação com o plano de controle ou 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 diretivas de rede, você pode permitir ou negar caminhos de rede específicos dentro do cluster com base em namespaces e seletores de rótulo.

Segurança de Aplicações

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

Acesso seguro de contêineres aos recursos

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

Segredos de Kubernetes

Com um Kubernetes Secret, você injeta dados confidenciais em pods, como credenciais de acesso ou chaves.

1. Crie um segredo usando a API do Kubernetes.
2. Defina seu pod ou implantação e solicite um Segredo específico.
   • Os segredos são fornecidos apenas aos nodos que têm um pod agendado que os exige.
   • O segredo é armazenado em tmpfs, não gravado em disco.
3. Quando se apaga o último pod num nó que requer uma Chave Secreta, esta é removida do tmpfs do nó.
   • Os segredos são armazenados dentro de um determinado namespace e só são acessíveis a partir de pods dentro do mesmo namespace.

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

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

Próximos passos

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

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

Para obter mais informações sobre os principais conceitos do Kubernetes e AKS, consulte:

• Clusters e cargas de trabalho Kubernetes / AKS
• Identidade de Kubernetes / AKS
• Redes virtuais Kubernetes / AKS
• Soluções de Armazenamento Kubernetes / AKS
• Escala de Kubernetes / AKS