Práticas recomendadas para segurança de cluster e atualizações no Serviço Kubernetes do Azure (AKS)

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

À medida que você gerencia clusters no Serviço Kubernetes do Azure (AKS), a carga de trabalho e a segurança dos dados são uma consideração fundamental. Ao executar clusters multilocatários usando isolamento lógico, você precisa proteger especialmente o acesso a recursos e cargas de trabalho. Minimize o risco de ataque ao aplicar as atualizações de segurança mais recentes do Kubernetes e do sistema operativo do nó.

Este artigo se concentra em como proteger seu cluster AKS. Você aprende a:

  • Use o Microsoft Entra ID e o controle de acesso baseado em função do Kubernetes (Kubernetes RBAC) para proteger o acesso ao servidor de API.
  • Proteja o acesso do contêiner aos recursos do nó.
  • Atualize um cluster AKS para a versão mais recente do Kubernetes.
  • Mantenha os nós atualizados e aplique automaticamente patches de segurança.

Você também pode ler as práticas recomendadas para gerenciamento de imagens de contêiner e segurança de pod.

Responsabilidades de segurança em modo cluster AKS

O AKS suporta dois modos de cluster: AKS Automático e AKS Standard. Os objetivos de segurança são os mesmos em ambos os modos, mas a responsabilidade de implementação difere.

O AKS Automatic inclui uma base reforçada com mais controlos pré-configurados em configurações suportadas. A Norma AKS proporciona um controlo direto de configuração mais amplo, o que aumenta a responsabilidade do operador pela configuração base e operações em curso.

Area AKS Automático Padrão AKS
Linha de base de autenticação e autorização do cluster Mais predefinições em configurações suportadas Comumente configurado explicitamente por operadores
Reforço da rede de servidores API Comportamento de base mais pré-configurado em configurações suportadas Escolhas explícitas de reforço da segurança por parte dos operadores
Controlos de políticas e controlos de segurança de referência Mais predefinições em configurações suportadas Ativação explícita de políticas e seleção de modos
Controlo da higiene da imagem Controlos de linha de base disponíveis em configurações suportadas Ativação explícita e responsabilidade pelo ciclo de vida
Operações do conjunto de nós do sistema Mais comportamento de gestão de serviços Mais comportamento gerido pelo operador
Atualizar titularidade Mais padrões de atualização geridos Estratégia selecionada pelo operador e governação de implementação

Habilite a proteção contra ameaças

Orientações sobre boas práticas

Você pode habilitar o Defender for Containers para ajudar a proteger seus contêineres. O Defender for Containers pode avaliar configurações de cluster e fornecer recomendações de segurança, executar verificações de vulnerabilidades e fornecer proteção e alertas em tempo real para nós e clusters do Kubernetes.

Esta orientação aplica-se a ambos os modos. Mesmo quando o AKS Automatic fornece padrões de segurança pré-configurados, os fluxos de trabalho de integração de proteção contra ameaças e de resposta a alertas continuam a ser responsabilidades operacionais para a sua equipa.

Acesso seguro ao servidor de API e aos nós do cluster

Orientações sobre boas práticas

Uma das maneiras mais importantes de proteger seu cluster é proteger o acesso ao servidor de API do Kubernetes. Para controlar o acesso ao servidor de API, integre o Kubernetes RBAC com o Microsoft Entra ID. Com esses controles, você protege o AKS da mesma forma que protege o acesso às suas assinaturas do Azure.

O servidor de API do Kubernetes fornece um único ponto de conexão para solicitações para executar ações dentro de um cluster. Para proteger e auditar o acesso ao servidor de API, limite o acesso e forneça os níveis de permissão mais baixos possíveis. embora essa abordagem não seja exclusiva do Kubernetes, ela é especialmente importante quando você isolou logicamente seu cluster AKS para uso multilocatário.

O Microsoft Entra ID fornece uma solução de gerenciamento de identidades pronta para empresas que se integra a clusters AKS. Como o Kubernetes não fornece uma solução de gerenciamento de identidades, você pode ter dificuldade em restringir granularmente o acesso ao servidor de API. Com clusters integrados do Microsoft Entra no AKS, você usa suas contas de usuário e grupo existentes para autenticar usuários no servidor de API.

Integração do Microsoft Entra para clusters AKS

Usando o Kubernetes RBAC e a integração de ID do Microsoft Entra, você pode proteger o servidor de API e fornecer as permissões mínimas necessárias para um conjunto de recursos com escopo, como um único namespace. Você pode conceder diferentes usuários ou grupos do Microsoft Entra diferentes funções do Kubernetes. Com permissões granulares, você pode restringir o acesso ao servidor de API e fornecer uma trilha de auditoria clara das ações executadas.

No AKS Automatic, as bases de autorização e segurança estão mais pré-configuradas em configurações suportadas, pelo que os operadores focam-se na validação, governação e gestão de exceções. No AKS Standard, os operadores normalmente configuram estes controlos diretamente e mantêm a sua postura ao longo do ciclo de vida.

Para obter mais informações sobre a integração do Microsoft Entra, o RBAC do Kubernetes e o RBAC do Azure, consulte Práticas recomendadas para autenticação e autorização no AKS.

Restringir o acesso à API de metadados da instância

Orientações sobre boas práticas

Adicione uma política de rede em todos os namespaces do utilizador para bloquear o egresso do pod para o endpoint de metadados.

Nota

Para implementar a Política de Rede, inclua o atributo --network-policy azure ao criar o cluster AKS. Use o seguinte comando para criar o cluster: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

No AKS Standard, certifique-se de que o modelo de rede e o motor de políticas selecionados apoiam este caminho de política. No AKS Automatic, aplique restrições equivalentes de saída ao nível do namespace quando suportadas na configuração do cluster.

Acesso seguro de contêineres aos recursos

Orientações sobre boas práticas

Limite o acesso a ações que os contêineres podem executar. Forneça o menor número de permissões e evite o uso de acesso raiz ou escalonamento privilegiado.

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.

Usando namespaces de usuário, você melhora o isolamento do host e limita o movimento lateral em caso de quebras de contêiner. Essas melhorias são significativas, quer o pod esteja sendo executado como root ou não.

Para um controle ainda mais granular das ações do contêiner, você também pode usar recursos de segurança internos do Linux, como AppArmor e seccomp.

Mesmo quando o AKS Automatic fornece padrões reforçados, os controlos de segurança ao nível da carga de trabalho continuam a ser responsabilidades da aplicação e da equipa da plataforma.

Para obter mais informações, consulte Proteger o acesso de contêiner aos recursos.

Atualize regularmente para a versão mais recente do Kubernetes

Orientações sobre boas práticas

Para se manter atualizado sobre novos recursos e correções de bugs, atualize regularmente a versão do Kubernetes em seu cluster AKS.

O Kubernetes lança novos recursos em um ritmo mais rápido do que as plataformas de infraestrutura mais tradicionais. As atualizações do Kubernetes incluem:

  • Novas funcionalidades
  • Correções de bugs ou de segurança

Os novos recursos normalmente passam pelo status alfa e beta antes de se tornarem estáveis. Uma vez estáveis, estão geralmente disponíveis e recomendados para uso em produção. O novo ciclo de lançamento de recursos do Kubernetes permite que você atualize o Kubernetes sem encontrar regularmente alterações significativas ou ajustar suas implantações e modelos.

O AKS suporta três versões secundárias do Kubernetes. Assim que uma nova versão de patch secundária é introduzida, a versão secundária mais antiga e as versões de patch suportadas são desativadas. Pequenas atualizações do Kubernetes acontecem periodicamente. Para permanecer dentro do suporte, certifique-se de ter um processo de governança para verificar as atualizações necessárias. Para obter mais informações, consulte Versões suportadas do Kubernetes AKS.

No AKS Automatic, o comportamento relacionado com a atualização é mais pré-configurado em configurações suportadas, e os operadores devem focar-se na validação da prontidão da carga de trabalho e na governação de lançamentos. No AKS Standard, os operadores escolhem e governam a estratégia de atualização e o calendário de implementação de forma mais direta.

Para verificar as versões disponíveis para o seu cluster, use o az aks get-upgrades comando mostrado no seguinte exemplo:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Depois podes atualizar o teu cluster AKS usando o az aks upgrade comando. O processo de atualização com segurança:

  • Isola e depois drena um nó de cada vez.
  • Programa pods nos nós restantes.
  • Implanta um novo nó executando as versões mais recentes do sistema operacional e do Kubernetes.

Importante

Teste novas versões secundárias em um ambiente de teste de desenvolvimento e valide se sua carga de trabalho permanece íntegra com a nova versão do Kubernetes.

O Kubernetes pode desvalorizar APIs (como na versão 1.16) das quais os teus workloads dependem. Ao introduzir novas versões em produção, considere o uso de vários conjuntos de nós em versões distintas e atualize pools individuais um de cada vez para implementar progressivamente a atualização em um cluster. Se estiver executando vários clusters, atualize um cluster de cada vez para monitorar progressivamente o impacto ou as alterações.

Para obter mais informações sobre atualizações no AKS, consulte Versões do Kubernetes suportadas no AKS e Atualizar um cluster AKS.

Processar atualizações do nó Linux

Todas as noites, os nós Linux no AKS recebem patches de segurança através do seu canal de atualização de distro. Esse comportamento é configurado automaticamente à medida que os nós são implantados em um cluster AKS. Para minimizar a interrupção e o impacto potencial nas cargas de trabalho em execução, os nós não são reinicializados automaticamente se um patch de segurança ou atualização do kernel exigir. Para obter mais informações sobre como lidar com reinicializações de nós, consulte Aplicar atualizações de segurança e kernel a nós no AKS.

No AKS Automatic, o comportamento de atualização de nós está mais predefinido nas configurações suportadas. No AKS Standard, os operadores normalmente definem a governação de patch e reboot com controlos operacionais explícitos.

Atualizações de imagem do nodo

As atualizações autônomas aplicam atualizações ao sistema operacional do nó Linux, mas a imagem usada para criar nós para o cluster permanece inalterada. Se um novo nó Linux for adicionado ao seu cluster, a imagem original será usada para criar o nó. Este novo nó receberá todas as atualizações de segurança e kernel disponíveis durante a verificação automática todas as noites, mas permanecerá sem patches até que todas as verificações e reinicializações sejam concluídas. Você pode usar a atualização de imagem de nó para verificar e atualizar imagens de nó usadas pelo cluster. Para obter mais informações sobre a atualização da imagem do nó, consulte Atualização da imagem do nó do Serviço Kubernetes do Azure (AKS).

Processar atualizações de nó do Windows Server

Para os nós do Windows Server, execute regularmente uma operação de atualização de imagem de nó para isolar e esvaziar os pods com segurança e implantar nós atualizados.

Para mais informações sobre o AKS e a segurança do seu cluster AKS, consulte os seguintes artigos: