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

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:

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.

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.

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.

Por exemplo, defina allowPrivilegeEscalation: false no manifesto do pod. Esses contextos de segurança de pod internos do Kubernetes permitem que você defina permissões adicionais, tais como o usuário ou grupo como o qual executar ou quais funcionalidades do Linux expor. Para obter mais práticas recomendadas, confira Proteger o acesso do pod a recursos.

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.

1. Defina os recursos de segurança do Linux no nível do nó.
2. Implemente recursos por meio de um manifesto de pod.

Os recursos de segurança internos do Linux estão disponíveis apenas em nós e pods do Linux.

Armadura de aplicativo

Para limitar as ações de contêineres, use o módulo de segurança de kernel do Linux AppArmor. O AppArmor está disponível como parte do sistema operacional do nó do AKS subjacente e é habilitado por padrão. Você cria perfis do AppArmor que restringem ações de leitura, gravação ou execução, bem como funções de sistema como a montagem de sistemas de arquivos. Perfis padrão do AppArmor restringem o acesso a vários locais /proc e /sys e fornecem um meio para isolar logicamente os contêineres do nó subjacente. O AppArmor funciona para qualquer aplicativo executado no Linux, não apenas para os pods do Kubernetes.

Para ver o AppArmor em ação, o exemplo a seguir cria um perfil que impede a gravação em arquivos.

1. Conecte-se por SSH a um nó do AKS.

2. Crie um arquivo chamado deny-write.profile.

3. 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,
   }
   

Perfis de AppArmor são adicionados usando o comando apparmor_parser.

1. Adicione o perfil ao AppArmor.

2. Especifique o nome do perfil criado na etapa anterior:

   sudo apparmor_parser deny-write.profile
   

   Se o perfil for analisado e aplicado corretamente ao AppArmor, você não verá nenhuma saída e será levado de volta ao prompt de comando.

3. No computador local, crie um manifesto de pod chamado aks-apparmor.yaml. Esse manifesto:

   • Define uma anotação para container.apparmor.security.beta.kubernetes.
   • Faz referência ao perfil de negação de 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" ]
   

4. Com o pod implantado, execute o seguinte comando e verifique se o pod hello-apparmor mostra um status Em execução:

   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 AppArmor, confira Perfis do AppArmor no Kubernetes.

Computação segura

Enquanto o AppArmor funciona para qualquer aplicativo do Linux, o seccomp (computação segura) funciona no nível do processo. O seccomp também é um módulo de segurança de kernel do Linux e tem compatibilidade nativa com o runtime do Docker usado por nós do AKS. Com seccomp, você pode limitar as chamadas de processo do contêiner. Alinhe-se à melhor prática de conceder ao contêiner as permissões mínimas para sua execução ao:

• Definir com filtros as ações a serem permitidas ou negadas.
• Anotar em um manifesto YAML do pod para associação ao filtro de seccomp.

Para ver o seccomp em ação, crie um filtro que impeça a alteração das permissões em um arquivo.

1. Conecte-se por SSH a um nó do AKS.

2. Crie um filtro de seccomp chamado /var/lib/kubelet/seccomp/prevent-chmod.

3. 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 posteriores, você precisa configurar o seguinte:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. No computador local, crie um manifesto de pod chamado aks-seccomp.yaml e cole o conteúdo a seguir. Esse 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: Never
   

   Na versão 1.19 e posteriores, 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
   

5. Implante o pod de exemplo usando o comando kubectl apply:

   kubectl apply -f ./aks-seccomp.yaml
   

6. Veja o status do pod usando o comando kubectl get pods.

   • O pod relata um erro.
   • O comando chmod é impedido de executar pelo filtro do 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 os filtros disponíveis, confira Perfis de segurança do seccomp para o Docker.

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.

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 *

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

Set-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster -KubernetesVersion <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.