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

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

Ao gerenciar clusters no AKS (Serviço de Kubernetes do Azure), a segurança dos dados e das cargas de trabalho é um aspecto fundamental. Quando executa clusters multilocatário usando isolamento lógico, você precisa especialmente proteger o acesso aos recursos e às cargas de trabalho. Minimize o risco de ataque instalando as atualizações de segurança mais recentes do Kubernetes e do sistema operacional dos nós.

Este artigo se concentra em como proteger seu cluster do AKS. Você aprenderá como:

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

Responsabilidades de segurança do AKS no modo de cluster

O AKS dá suporte a dois modos de cluster: AKS Automatic e AKS Standard. Os objetivos de segurança são os mesmos em ambos os modos, mas a responsabilidade de implementação é diferente.

O AKS Automatic inclui uma linha de base reforçada com mais controles pré-configurados nas configurações com suporte. O AKS Standard fornece um controle de configuração direta mais amplo, o que aumenta a responsabilidade do operador pela instalação da linha de base e pelas operações em andamento.

Habilitar a proteção contra ameaças

Orientação de melhor prática

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

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

Proteger o acesso aos nós de cluster e ao servidor de API

Orientação de melhor prática

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

O servidor de API do Kubernetes fornece um único ponto de conexão para que as solicitações realizem ações em um cluster. Para proteger e auditar o acesso ao servidor da API, limite o acesso e forneça permissões de acesso com os privilégios mínimos necessários. Embora essa abordagem não seja exclusiva do Kubernetes, ela é especialmente importante quando o cluster do AKS está isolado logicamente para uso na modalidade multilocatário.

O Microsoft Entra ID fornece uma solução de gerenciamento de identidade pronta para a empresa, que se integra aos clusters do AKS. Como o Kubernetes não fornece uma solução de gerenciamento de identidades, você pode ser levado a restringir de maneira granular o acesso ao servidor da API. Com os 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.

Usando o RBAC do Kubernetes e a integração do Microsoft Entra ID, 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 a diferentes funções do Kubernetes. Com permissões granulares, você pode restringir o acesso ao servidor da API e fornecer uma trilha de auditoria clara das ações realizadas.

No AKS Automatic, as linhas de base de autorização e segurança são mais pré-configuradas em configurações com suporte, portanto, os operadores se concentram na validação, governança e tratamento de exceções. No AKS Standard, os operadores geralmente configuram esses controles diretamente e mantêm sua postura de ciclo de vida.

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

Restringir o acesso à API de Metadados de Instância

Orientação de melhor prática

Adicione uma política de rede em todos os namespaces de usuário para bloquear a saída do pod para o ponto de extremidade de metadados.

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, verifique se o modelo de rede selecionado e o mecanismo de política dão suporte a esse caminho de política. No AKS Automatic, aplique restrições de saída no nível do namespace equivalente quando houver suporte na configuração do cluster.

Proteger o acesso do contêiner a recursos

Orientação de melhor prática

Limite o acesso às ações que podem ser executadas por contêineres. Forneça o menor número possível de permissões e evite o uso do acesso à raiz e da elevação de privilégio.

Da mesma forma que deve conceder a usuários ou grupos os privilégios mínimos necessários, você também deve limitar os contêineres apenas às ações e aos processos necessários. Para minimizar o risco de ataques, evite configurar aplicativos e contêineres que exijam privilégios elevados ou acesso à raiz.

Usando namespaces de usuário, é possível melhorar o isolamento do host e limitar a movimentação lateral em caso de fuga de contêiner. Essas melhorias são significativas independentemente de o pod estar sendo executado como root ou não.

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

Mesmo quando o AKS Automatic fornece configurações padrão reforçadas, os controles de segurança em nível de carga de trabalho continuam sendo responsabilidade das equipes de aplicativo e de plataforma.

Para obter mais informações, consulte Acesso seguro do contêiner aos recursos.

Atualizar frequentemente para a versão mais recente do Kubernetes

Orientação de melhor prática

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

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

• Novos recursos
• Correções de bugs ou de segurança

Normalmente, os novos recursos passam pelos status alfa e beta antes de se tornarem estáveis. Uma vez estáveis, ficam disponíveis de forma geral e são recomendados para uso em produção. O novo ciclo de lançamento de recursos do Kubernetes permite que você atualize o Kubernetes sem se deparar regularmente com mudanças incompatíveis nem precisar ajustar suas implantações e modelos.

O AKS é compatível com três versões secundárias do Kubernetes. Quando uma nova versão de patch secundária é introduzida, a versão secundária e o patch mais antigos com suporte são desativados. Atualizações secundárias do Kubernetes ocorrem em intervalos periódicos. Para permanecer dentro do suporte, verifique se você tem um processo de governança para verificar se há atualizações necessárias. Para obter mais informações, confira Versões do Kubernetes compatíveis no AKS.

No AKS Automatic, o comportamento relacionado à atualização é mais pré-configurado em configurações com suporte e os operadores devem se concentrar na validação de preparação da carga de trabalho e na governança de versão. No AKS Standard, os operadores escolhem e governam a estratégia de atualização e o tempo de distribuição mais diretamente.

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

Get-AzAksUpgradeProfile -ResourceGroupName myResourceGroup -ClusterName myAKSCluster |
Select-Object -Property Name, ControlPlaneProfileKubernetesVersion -ExpandProperty ControlPlaneProfileUpgrade |
Format-Table -Property *

Para obter mais informações sobre as atualizações no AKS, confira Versões compatíveis do Kubernetes no AKS e Atualizar um cluster do AKS.

Processar atualizações dos nós Linux

A cada noite, os nós Linux no AKS recebem atualizações de segurança por meio do canal de atualização da distribuição. Esse comportamento é configurado automaticamente conforme os nós são implantados em um cluster do AKS. Para minimizar a interrupção e o possível impacto da execução de cargas de trabalho, os nós não serão reinicializados automaticamente se um patch de segurança ou atualização de kernel precisar deles. Para obter mais informações sobre como gerenciar reinicializações dos nós, confira Aplicar atualizações de segurança e de kernel aos nós no AKS.

No AKS Automatic, o comportamento de atualização dos nós é mais predefinido nas configurações compatíveis. No AKS Standard, os operadores geralmente definem a governança de patch e reinicialização com controles operacionais explícitos.

Atualizações da imagem do nó

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

Processar atualizações de nós do Windows Server

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

Conteúdo relacionado

Para obter mais informações sobre o AKS e proteger o cluster do AKS, consulte os seguintes artigos:

• Comparação de recursos entre o AKS Automatic e o AKS Standard
• Práticas recomendadas para autenticação e autorização no AKS