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.
Por exemplo, defina allowPrivilegeEscalation: false no manifesto pod. Esses contextos de segurança de pod Kubernetes integrados permitem que você defina permissões adicionais, como o usuário ou grupo para executar como, ou os recursos do Linux para expor. Para obter mais práticas recomendadas, consulte Proteger o acesso do pod aos recursos.
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.
- Defina os recursos de segurança do Linux no nível do nó.
- Implemente recursos por meio de um manifesto de pod.
Os recursos de segurança Linux integrados só estão disponíveis em nós e pods Linux.
Nota
Atualmente, os ambientes Kubernetes não são completamente seguros para uso multilocatário hostil. Recursos de segurança adicionais, como Microsoft Defender for Containers AppArmor, seccomp, Pod Security Admission ou Kubernetes RBAC para nós, bloqueiam explorações de forma eficiente.
Para uma verdadeira segurança ao executar cargas de trabalho multilocatárias hostis, confie apenas em um hipervisor. O domínio de segurança do Kubernetes torna-se o cluster inteiro, não um nó individual.
Para esses tipos de cargas de trabalho multilocatárias hostis, você deve usar clusters fisicamente isolados.
App Armadura
Para limitar as ações do contêiner, você pode usar o módulo de segurança do kernel do AppArmor Linux. O AppArmor está disponível como parte do sistema operacional subjacente do nó AKS e está habilitado por padrão. Você cria perfis do AppArmor que restringem leitura, gravação ou execução de ações, ou funções do sistema, como a montagem de sistemas de arquivos. Os perfis padrão do AppArmor restringem o acesso a vários /proc locais /sys e fornecem um meio de isolar logicamente os contêineres do nó subjacente. O AppArmor funciona para qualquer aplicativo executado em Linux, não apenas para pods Kubernetes.
Para ver o AppArmor em ação, o exemplo a seguir cria um perfil que impede a gravação em arquivos.
SSH para um nó AKS.
Crie um arquivo chamado deny-write.profile.
Copie e cole o seguinte conteúdo:
#include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, }
Os perfis do AppArmor são adicionados usando o apparmor_parser comando.
Adicione o perfil ao AppArmor.
Especifique o nome do perfil criado na etapa anterior:
sudo apparmor_parser deny-write.profileSe o perfil for analisado e aplicado corretamente ao AppArmor, você não verá nenhuma saída e retornará ao prompt de comando.
A partir da sua máquina local, crie um manifesto de pod chamado aks-apparmor.yaml. Este manifesto:
- Define uma anotação para
container.apparmor.security.beta.kubernetes. - Faz referência ao perfil de negação-gravação criado nas etapas anteriores.
apiVersion: v1 kind: Pod metadata: name: hello-apparmor annotations: container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write spec: containers: - name: hello image: mcr.microsoft.com/dotnet/runtime-deps:6.0 command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]- Define uma anotação para
Com o pod implantado, execute o seguinte comando e verifique se o pod hello-apparmor mostra um status Running :
kubectl get pods NAME READY STATUS RESTARTS AGE aks-ssh 1/1 Running 0 4m2s hello-apparmor 0/1 Running 0 50s
Para obter mais informações sobre o AppArmor, consulte Perfis do AppArmor no Kubernetes.
Computação segura
Enquanto o AppArmor funciona para qualquer aplicação Linux, seccomp (secure computing) funciona ao nível do processo. O Seccomp também é um módulo de segurança do kernel Linux e é suportado nativamente pelo tempo de execução do Docker usado pelos nós AKS. Com seccomp, você pode limitar as chamadas de processo de contêiner. Alinhe-se à prática recomendada de conceder permissão mínima ao contêiner apenas para ser executado por:
- Definir com filtros quais ações permitir ou negar.
- Anotação dentro de um manifesto YAML pod para associar ao filtro seccomp.
Para ver o seccomp em ação, crie um filtro que impeça a alteração de permissões em um arquivo.
SSH para um nó AKS.
Crie um filtro seccomp chamado /var/lib/kubelet/seccomp/prevent-chmod.
Copie e cole o seguinte conteúdo:
{ "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "name": "chmod", "action": "SCMP_ACT_ERRNO" }, { "name": "fchmodat", "action": "SCMP_ACT_ERRNO" }, { "name": "chmodat", "action": "SCMP_ACT_ERRNO" } ] }Na versão 1.19 e posterior, você precisa configurar o seguinte:
{ "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "names": ["chmod","fchmodat","chmodat"], "action": "SCMP_ACT_ERRNO" } ] }Na sua máquina local, crie um manifesto de pod chamado aks-seccomp.yaml e cole o seguinte conteúdo. Este manifesto:
- Define uma anotação para
seccomp.security.alpha.kubernetes.io. - Faz referência ao filtro prevent-chmod criado na etapa anterior.
apiVersion: v1 kind: Pod metadata: name: chmod-prevented annotations: seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod spec: containers: - name: chmod image: mcr.microsoft.com/dotnet/runtime-deps:6.0 command: - "chmod" args: - "777" - /etc/hostname restartPolicy: NeverNa versão 1.19 e posterior, você precisa configurar o seguinte:
apiVersion: v1 kind: Pod metadata: name: chmod-prevented spec: securityContext: seccompProfile: type: Localhost localhostProfile: prevent-chmod containers: - name: chmod image: mcr.microsoft.com/dotnet/runtime-deps:6.0 command: - "chmod" args: - "777" - /etc/hostname restartPolicy: Never- Define uma anotação para
Implante o pod de exemplo usando o comando kubectl apply :
kubectl apply -f ./aks-seccomp.yamlVisualize o status do pod usando o comando kubectl get pods .
- O pod relata um erro.
- O
chmodcomando é impedido de ser executado pelo filtro seccomp, conforme mostrado na saída de exemplo a seguir:
kubectl get pods NAME READY STATUS RESTARTS AGE chmod-prevented 0/1 Error 0 7s
Para obter mais informações sobre filtros disponíveis, consulte Perfis de segurança Seccomp para Docker.
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
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários