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

  • Artigo
  • 9 minutos para ler

A segurança do contentor protege todo o pipeline ponto a ponto da compilação para as cargas de trabalho da aplicação em execução no Azure Kubernetes Service (AKS).

A Cadeia de Fornecimento Segura inclui o ambiente de compilação e o registo.

O Kubernetes inclui componentes de segurança, como padrões de segurança de pods e Segredos. O Azure inclui componentes como o Active Directory, Microsoft Defender para Contentores, Azure Policy, Key Vault do Azure, grupos de segurança de rede e atualizações de cluster orquestradas. O AKS combina estes componentes de segurança para:

  • Forneça uma história completa de autenticação e autorização.
  • Aplique Azure Policy Incorporados do AKS para proteger as suas aplicações.
  • Informações ponto a ponto da compilação através da sua aplicação com Microsoft Defender para Contentores.
  • Mantenha o cluster do AKS a executar as atualizações de segurança mais recentes do SO 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 as suas aplicações no AKS.

Segurança da Compilação

Como ponto de entrada da Cadeia de Fornecimento, é importante realizar uma análise estática das compilações de imagens antes de serem promovidas no pipeline. Isto inclui a avaliação de vulnerabilidades e conformidade. Não se trata de falhar uma compilação porque tem uma vulnerabilidade, pois isso interrompe o desenvolvimento. Trata-se de analisar o Estado do Fornecedor para segmentar com base em vulnerabilidades acionáveis pelas equipas de desenvolvimento. Utilize também Períodos de Tolerância para permitir aos programadores tempo para remediar problemas identificados.

Segurança do Registo

Avaliar o estado de vulnerabilidade da imagem no Registo deteta um desfasamento e também captura imagens que não vieram do seu ambiente de compilação. Utilize o Notary V2 para anexar assinaturas às suas imagens para garantir que as implementações provêm de uma localização fidedigna.

Segurança do cluster

No AKS, os componentes principais do Kubernetes fazem parte do serviço gerido fornecido, gerido e mantido pela Microsoft. Cada cluster do AKS tem o seu próprio mestre do Kubernetes dedicado e com inquilino único para fornecer o Servidor de API, o Scheduler, etc. Para obter informações sobre como a Microsoft gere vulnerabilidades de segurança e detalhes sobre o lançamento de atualizações de segurança para análises geridas de clusters do AKS, veja Gestão de vulnerabilidades para Azure Kubernetes Service.

Por predefinição, o servidor da API do Kubernetes utiliza um endereço IP público e um nome de domínio completamente qualificado (FQDN). Pode limitar o acesso ao ponto final do servidor de API através de intervalos de IP autorizados. Também pode criar um cluster totalmente privado para limitar o acesso do servidor de API à sua rede virtual.

Pode controlar o acesso ao servidor de API com o controlo de acesso baseado em funções do Kubernetes (RBAC do Kubernetes) e o RBAC do Azure. Para obter mais informações, veja Azure AD integração com o AKS.

Segurança do nó

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

  • Os nós do Linux executam versões otimizadas do Ubuntu ou Mariner.
  • Os nós do Windows Server executam uma versão otimizada do Windows Server 2019 com o ou o runtime de contentor do containerd Docker.

Quando um cluster do AKS é criado ou aumentado verticalmente, os nós são implementados automaticamente com as mais recentes atualizações e configurações de segurança do SO.

Nota

Clusters do AKS com:

  • O Kubernetes versão 1.19 e superior para conjuntos de nós do Linux utilizam containerd como o respetivo runtime de contentor. A utilização containerd com conjuntos de nós do Windows Server 2019 está atualmente em pré-visualização. Para obter mais informações, consulte Adicionar um conjunto de nós do Windows Server com containerd.
  • O Kubernetes anterior à v1.19 para conjuntos de nós do Linux utiliza o Docker como o respetivo runtime de contentor. Para conjuntos de nós do Windows Server 2019, o Docker é o runtime de contentor predefinido.

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 aplicação de patches de segurança.

Autorização de nó

A autorização de nó é um modo de autorização para fins especiais que autoriza especificamente os pedidos de API feitos pelos kubelets para proteger contra ataques East-West. A autorização de nós está ativada por predefinição no AKS 1.24 + clusters.

Implementação de nós

Os nós são implementados numa sub-rede de rede virtual privada, sem endereços IP públicos atribuídos. Para fins de resolução de problemas e gestão, o SSH está ativado por predefinição e apenas acessível através do endereço IP interno.

Armazenamento de nós

Para fornecer armazenamento, os nós utilizam o Azure Managed Disks. Para a maioria dos tamanhos de nós de VM, o Azure Managed Disks são discos Premium apoiados por SSDs de elevado desempenho. Os dados armazenados em discos geridos são automaticamente encriptados inativos na plataforma do Azure. Para melhorar a redundância, os Managed Disks do Azure são replicados de forma segura no datacenter do Azure.

Cargas de trabalho multi-inquilino hostis

Atualmente, os ambientes do Kubernetes não são seguros para utilização multi-inquilino hostil. Funcionalidades de segurança adicionais, como Políticas de Segurança de Pods ou RBAC do Kubernetes para nós, bloqueiam explorações de forma eficiente. Para uma verdadeira segurança ao executar cargas de trabalho multi-inquilino hostis, confie apenas num hipervisor. O domínio de segurança do Kubernetes torna-se o cluster completo e não um nó individual.

Para estes tipos de cargas de trabalho multi-inquilino hostis, deve utilizar clusters fisicamente isolados. Para obter mais informações sobre formas de isolar cargas de trabalho, veja Melhores práticas para o isolamento de clusters no AKS.

Isolamento de computação

Devido à conformidade ou aos requisitos regulamentares, determinadas cargas de trabalho podem exigir um elevado grau de isolamento de outras cargas de trabalho do cliente. Para estas cargas de trabalho, o Azure fornece VMs isoladas para utilizar como nós de agente num cluster do AKS. Estas VMs estão isoladas de um tipo de hardware específico e dedicadas a um único cliente.

Selecione um dos tamanhos de VMs isoladas como o tamanho do nó ao criar um cluster do AKS ou adicionar um conjunto de nós.

Atualizações do cluster

O Azure fornece ferramentas de orquestração de atualização para atualizar um cluster e componentes do AKS, manter a segurança e conformidade e aceder às funcionalidades mais recentes. Esta orquestração de atualização inclui os componentes principais e de agente do Kubernetes.

Para iniciar o processo de atualização, especifique uma das versões do Kubernetes disponíveis listadas. Em seguida, o Azure isola e drena em segurança cada nó e atualizações do AKS.

Cordão e drenagem

Durante o processo de atualização, os nós do AKS são isolados individualmente do cluster para impedir que novos pods sejam agendados nos mesmos. Em seguida, os nós são drenados e atualizados da seguinte forma:

  1. É implementado um novo nó no conjunto de nós.
    • Este nó executa a imagem e os patches do SO mais recentes.
  2. Um dos nós existentes é identificado para atualização.
  3. Os pods no nó identificado são terminados corretamente e agendados nos outros nós no conjunto de nós.
  4. O nó esvaziado é eliminado do cluster do AKS.
  5. Os passos 1 a 4 são repetidos até que todos os nós sejam substituídos com êxito como parte do processo de atualização.

Para obter mais informações, veja Atualizar um cluster do AKS.

Segurança da rede

Para conectividade e segurança com redes no local, pode implementar o cluster do AKS em sub-redes de rede virtual do Azure existentes. Estas redes virtuais ligam-se novamente à sua rede no local através da VPN Site a Site do Azure ou do ExpressRoute. Defina controladores de entrada do Kubernetes com endereços IP internos privados para limitar o acesso dos serviços à ligação de rede interna.

Grupos de segurança de rede do Azure

Para filtrar o fluxo de tráfego de rede virtual, o Azure utiliza regras de grupo de segurança de rede. Estas regras definem os intervalos de IP de origem e de destino, as portas e os protocolos permitidos ou negados acesso aos recursos. São criadas regras predefinidas para permitir o tráfego TLS para o servidor da API do Kubernetes. Pode criar serviços com balanceadores de carga, mapeamentos de portas ou rotas de entrada. O AKS modifica automaticamente o grupo de segurança da rede do fluxo de tráfego.

Se fornecer a sua própria sub-rede para o cluster do AKS (quer esteja a utilizar o Azure CNI ou o Kubenet), não modifique o grupo de segurança de rede ao nível da NIC gerido 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. Verifique se não interferem com o tráfego necessário que gere o cluster, como o acesso ao balanceador de carga, a comunicação com o plano de controlo e a saída.

Política de rede do Kubernetes

Para limitar o tráfego de rede entre pods no cluster, o AKS oferece suporte para políticas de rede do Kubernetes. Com as políticas de rede, pode permitir ou negar caminhos de rede específicos no cluster com base em espaços de nomes e seletores de etiquetas.

Segurança de Aplicações

Para proteger pods em execução no AKS, considere Microsoft Defender para Contentores detetar e restringir ciberataques contra as aplicações em execução nos seus pods. Execute a análise contínua para detetar desvios no estado de vulnerabilidade da sua aplicação e implemente um processo "azul/verde/canário" para corrigir e substituir as imagens vulneráveis.

Segredos de Kubernetes

Com um Segredo do Kubernetes, injeta dados confidenciais em pods, como credenciais de acesso ou chaves.

  1. Crie um Segredo com a API do Kubernetes.
  2. Defina o pod ou a implementação e solicite um Segredo específico.
    • Os segredos só são fornecidos aos nós com um pod agendado que os exija.
    • O Segredo é armazenado em tmpfs, não escrito no disco.
  3. Quando elimina o último pod num nó que requer um Segredo, o Segredo é eliminado dos tmpfs do nó.
    • Os segredos são armazenados num determinado espaço de nomes e só são acessíveis a partir de pods no mesmo espaço de nomes.

A utilização de Segredos reduz as informações confidenciais definidas no manifesto YAML do pod ou do serviço. Em vez disso, pede o Segredo armazenado no Servidor de API do Kubernetes como parte do seu manifesto YAML. Esta abordagem fornece apenas o acesso de pod específico ao Segredo.

Nota

Os ficheiros de manifesto secreto não processados contêm os dados secretos no formato base64 (consulte a documentação oficial para obter mais detalhes). Trate estes ficheiros como informações confidenciais e nunca os consolide com o controlo de origem.

Os segredos do Kubernetes são armazenados no etcd, um arquivo de chave-valor distribuído. O AKS gere totalmente o arquivo Etcd e os dados são encriptados inativos na plataforma do Azure.

Passos seguintes

Para começar a proteger os clusters do AKS, veja Atualizar um cluster do AKS.

Para obter as melhores práticas associadas, veja Melhores práticas para a segurança do cluster e atualizações no AKS e Melhores práticas para a segurança de pods no AKS.

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