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

  • Artigo

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 equipes 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 implantações sejam provenientes 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 nó

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 2019 usando o tempo de execução do containerd contêiner do Docker.

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.

Nota

Clusters AKS em execução:

  • Kubernetes versão 1.19 e superior - pools de nós Linux usam containerd como seu tempo de execução de contêiner. Os pools de nós do Windows Server 2019 usam containerd como seu tempo de execução de contêiner, que está atualmente em visualização. Para obter mais informações, consulte Adicionar um pool de nós do Windows Server com containerdo .
  • Kubernetes versão 1.19 e anterior - Os pools de nós do Linux usam o Docker como seu tempo de execução de contêiner. Os pools de nós do Windows Server 2019 usam o Docker para o tempo de execução de contêiner padrão.

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 Nós de patch de segurança.

Os clusters AKS que executam VMs da Geração 2 do Azure incluem suporte para Inicialização Confiável (visualização), 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 por 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 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 do Kubernetes torna-se o cluster inteiro, não um nó individual.

Para esses tipos de cargas de trabalho multilocatárias hostis, você deve 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:

  • Contêineres isolados do kernel para usar como nós de agente em um cluster AKS. Esses contêineres são completamente isolados em um tipo de hardware específico e isolados da malha do Host do Azure, do sistema operacional 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 não criptografado, formato legível e adulteração. 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) usa 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, mapeamentos de porta ou rotas de entrada. O AKS modifica automaticamente o grupo de segurança da rede do 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.

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 a nós com um pod agendado que os exija.
    • O segredo é armazenado em tmpfs, não gravado em disco.
  3. Quando você exclui o último pod em um nó que requer um Segredo, o Segredo é excluído 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 do 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.

Nota

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

Os segredos do Kubernetes são armazenados no etcd, um armazenamento distribuído de chave-valor. O AKS gerencia totalmente o armazenamento etcd e os dados são criptografados em repouso na plataforma Azure.

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: