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

  • Artigo

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. O Azure inclui componentes como Active Directory Domain Services, 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 os Azure Policy internos do AKS para proteger seus aplicativos.
  • Visão de ponta a ponta da compilação por meio de 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.

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

Segurança da Compilação

Como ponto de entrada para a Cadeia de Fornecedores, é importante realizar a análise estática dos builds de imagem antes que eles sejam promovidos pelo pipeline. Isso inclui a avaliação de conformidade e vulnerabilidade. Não se trata de falhar em uma compilação porque ela tem uma vulnerabilidade, pois isso interrompe o desenvolvimento. Trata-se de observar 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 corrijam os problemas identificados.

Segurança do registro

Avaliar o estado da vulnerabilidade da imagem no registro detecta descompasso e também detecta 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 de cluster

No AKS, os componentes mestres de Kubernetes fazem parte do serviço gerenciado fornecido, gerenciado e mantido pela Microsoft. Cada cluster do AKS tem seu próprio Kubernetes dedicado de locatário único mestre para fornecer o Servidor de API, o Agendador e etc. Para obter mais informações, confira Gerenciamento de vulnerabilidades para o 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.

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, confira Integração do Microsoft Entra com o AKS.

Segurança do nó

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

  • Os nós do 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 e também usam o containerd ou o runtime de contêiner do Docker.

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 superiores: os pools de nós do Linux usam containerd como seu runtime de contêiner. Os pools de nós do Windows Server 2019 usam containerd como seu runtime de contêiner, que está atualmente em versão prévia. 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 pools de nós do Linux usam o Docker como seu runtime de contêiner. Os pools de nós do Windows Server 2019 usam o Docker como o runtime 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 Windows, confira Nós de aplicação de patch de segurança.

Os clusters do AKS que executam as VMs do Azure Geração 2 incluem suporte para o início confiável (versão prévia), que fornece proteção contra técnicas de ataque avançadas e persistentes combinando tecnologias que podem ser habilitadas de maneira independente, como a inicialização segura e a versão virtualizada do vTPM (módulo de plataforma confiável). 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.

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 o 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, os Azure Managed Disks são replicados com segurança no datacenter do 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, o 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, bem como do kernel do so 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 um cluster do AKS em sub-redes de rede virtual do 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.

Grupos de segurança de rede do Azure

Para filtrar o fluxo de tráfego em redes virtuais, 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 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 sub-rede para o cluster do AKS (seja usando a CNI do Azure ou o 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. Confira se eles não interferem 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 o Microsoft Defender para contêineres para detectar e restringir ataques cibernéticos contra seus aplicativos em execução em seus pods. 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.

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 gerencia totalmente o repositório etcd e os dados são criptografados em repouso na plataforma do Azure.

Próximas etapas

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

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: