Compartilhar via

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

  • Artigo

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 ataques aplicando as últimas atualizações de segurança do sistema operacional do nó e do Kubernetes.

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

  • Use o Microsoft Entra ID e o controle de acesso baseado em função do Kubernetes (RBAC do Kubernetes) para proteger o acesso ao servidor de API.
  • Proteger o acesso do contêiner aos recursos de nó.
  • Atualizar um cluster do AKS para a última versão do Kubernetes.
  • Manter os nós atualizados e aplicar automaticamente patches de segurança.

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

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.

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.

Integração do Microsoft Entra para clusters do AKS

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.

A melhor prática recomendada é usar grupos para fornecer acesso a arquivos e pastas, em vez de identidades individuais. Por exemplo, use uma associação de grupo do Microsoft Entra ID para associar usuários a funções do Kubernetes em vez de usuários individuais. Conforme a associação de grupo de um usuário sofre alterações, as permissões de acesso dele no cluster do AKS são alteradas.

Enquanto isso, digamos que você associe o usuário individual diretamente a uma função e a função de trabalho dele mude. Embora as associações de grupo do Microsoft Entra sejam atualizadas, suas permissões no cluster do AKS não o faziam. Nesse cenário, o usuário acaba tendo mais permissões do que o necessário.

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.

Observação

Para implementar a Política de Rede, incluindo o atributo --network-policy azure ao criar o cluster do 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

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.

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. Para obter mais informações, consulte Proteger acesso do contêiner para 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. Quando estáveis, são lançados em disponibilidade geral e recomendados para uso em produção. O novo ciclo de versão de recurso do Kubernetes permite que você atualize o Kubernetes sem encontrar frequentemente alterações interruptivas ou 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.

Para verificar quais versões estão disponíveis para seu cluster, use o comando az aks get-upgrades conforme mostrado no exemplo a seguir:

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

Você pode atualizar seu cluster do AKS usando o comando az aks upgrade. O processo de atualização, com segurança:

  • Isola e esvazia um nó por vez.
  • Agenda pods nos nós restantes.
  • Implanta um novo nó que executa as últimas versões do sistema operacional e do Kubernetes.

Importante

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

O Kubernetes pode preterir APIs (como na versão 1.16) das quais suas cargas de trabalho dependem. Ao trazer novas versões para produção, considere usar vários pools de nó em versões separadas e atualizar pools individuais, um de cada vez, para distribuir progressivamente a atualização em um cluster. Se estiver executando vários clusters, atualize um por vez para monitorar progressivamente o impacto ou as alterações.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

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 de nós do Linux

Todas as noites, os nós do Linux no AKS recebem patches de segurança por meio de seu canal de distribuição de atualizaçã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 lidar com reinicializações de nó, confira Aplicar atualizações de segurança e o kernel para nós do AKS.

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 Windows 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.