Práticas recomendadas para segurança de cluster e atualizações no Serviço Kubernetes do Azure (AKS)
À 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 aplicando as atualizações de segurança mais recentes do Kubernetes e do sistema operacional do nó.
Este artigo se concentra em como proteger seu cluster AKS. Sabe como:
- 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.
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.
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.
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.
A 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 vincular usuários a funções do Kubernetes em vez de usuários individuais. À medida que a associação ao grupo de um usuário muda, suas permissões de acesso no cluster AKS mudam de acordo.
Enquanto isso, digamos que você vincule o usuário individual diretamente a uma função e sua função de trabalho seja alterada. Embora as associações do grupo Microsoft Entra sejam atualizadas, suas permissões no cluster AKS não. Nesse cenário, o usuário acaba com mais permissões do que eles exigem.
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 de usuário para bloquear a saída do pod para o ponto de extremidade 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
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.
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. 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.
Para verificar as versões disponíveis para o 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
Em seguida, você pode atualizar seu cluster AKS usando o comando az aks upgrade . O processo de atualização com segurança:
- Cordões e 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 substituir APIs (como na versão 1.16) nas quais suas cargas de trabalho dependem. Ao trazer novas versões para a produção, considere o uso de vários pools de nós em versões separadas e atualize pools individuais um de cada vez para rolar 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.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION
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.
Atualizações de imagem de nó
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 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 nós do Windows Server, execute regularmente uma operação de atualização de imagem de nó para conectar e drenar pods com segurança e implantar nós atualizados.
Azure Kubernetes Service