Compartilhar via

Acesso de contêiner de segurança a recursos usando recursos de segurança internos do Linux

Neste artigo, você aprenderá a proteger o acesso de contêiner aos recursos para suas cargas de trabalho do AKS (Serviço de Kubernetes do Azure).

Importante

A partir de 30 de novembro de 2025, o AKS (Serviço de Kubernetes do Azure) não dá mais suporte ou fornece atualizações de segurança para o Azure Linux 2.0. A imagem do nó do Azure no Linux 2.0 está congelada na versão 202512.06.0. A partir de 31 de março de 2026, as imagens de nó serão removidas e não será possível escalar os grupos de nós. Migre para uma versão do Azure Linux com suporte atualizando os pools de nós para uma versão do Kubernetes com suporte ou migrando para o osSku AzureLinux3. Para obter mais informações, consulte [Desativação] Pools de nós do Azure Linux 2.0 no AKS.

Visão geral

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.

Você pode usar contextos de segurança de pod internos do Kubernetes para definir mais permissões, como o usuário ou grupo a ser executado como, as funcionalidades do Linux a serem expostas ou configuradas allowPrivilegeEscalation: false no manifesto do pod. Para obter mais práticas recomendadas, confira Proteger o acesso do pod a recursos.

Para melhorar o isolamento do host e diminuir o movimento lateral no Linux, você pode usar namespaces de usuário.

Para um controle ainda mais granular das ações de contêiner, você pode usar recursos de segurança internos 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.

Observação

Atualmente, os ambientes do Kubernetes não são completamente seguros para uso hostil multilocatário. Recursos de segurança adicionais, como Microsoft Defender para contêineres, AppArmor, seccomp, namespaces de usuário, Admissão de Segurança de Pod ou RBAC do Kubernetes para nós, bloqueiam explorações com eficiência.

Para a segurança verdadeira ao executar cargas de trabalho multilocatários hostis, confie apenas em um hipervisor. O domínio de segurança para o Kubernetes se torna o cluster inteiro, não um nó individual.

Para esses tipos de cargas de trabalho multilocatário hostis, você deve usar clusters fisicamente isolados.

Namespaces de usuário

Os pods do Linux são executados usando vários namespaces por padrão: namespaces de rede para isolar a identidade de rede e um namespace do PID para isolar os processos. Um namespace de usuário isola os usuários dentro do contêiner dos usuários no host. Ele também limita o escopo dos recursos e as interações do pod com o restante do sistema.

Os UIDs e GIDs dentro do contêiner são mapeados para usuários sem privilégios no host, portanto, toda a interação com o restante do host ocorre como aqueles UID e GID não privilegiados. Por exemplo, a raiz dentro do contêiner (UID 0) pode ser mapeada para o usuário 65536 no host. O Kubernetes cria o mapeamento para garantir que ele não se sobreponha a outros pods usando namespaces de usuário no sistema.

A implementação do Kubernetes tem alguns benefícios importantes:

  • Maior isolamento do host: se um contêiner escapar dos limites do pod, mesmo que ele seja executado como raiz dentro do contêiner, ele não terá privilégios no host. Isso ocorre porque os IUDs e GIDs do contêiner são mapeados para usuários sem privilégios no host. Se houver uma escape de contêiner, os namespaces de usuário protegerão bastante os arquivos no host para o qual um contêiner pode ler/gravar e para qual processo ele pode enviar sinais. Os recursos concedidos só são válidos dentro do namespace de usuário e não no host.

  • Prevenção de movimento lateral: à medida que os IUDs e GIDs de contêineres diferentes são mapeados para diferentes IUDs e GIDs não sobrepostos no host, os contêineres têm mais dificuldade em atacar uns aos outros. Por exemplo, suponha que o contêiner A seja executado com IUDs e GIDs diferentes no host do que o contêiner B. No caso de uma quebra de contêiner, as operações que ele pode fazer nos arquivos e processos do contêiner B são limitadas: somente leitura/gravação do que um arquivo permite a outras pessoas. Mas nem mesmo isso acaba sendo possível, pois há uma prevenção extra no diretório pai do volume raiz do pod para garantir que apenas o GID do pod possa acessá-lo.

  • Respeitar o princípio de privilégio mínimo: à medida que os IUDs e GIDs são mapeados para usuários desprivilegiados no host, somente os usuários que precisam do privilégio no host (e desabilitam namespaces de usuário) obtê-lo. Sem namespaces de usuário, não há separação entre os usuários do contêiner e os usuários do host. Não é possível evitar a concessão de privilégios no host a processos que não precisam dele, quando eles precisam de privilégios apenas dentro do contêiner.

  • Habilitação de novos casos de uso: os namespaces de usuário permitem que os contêineres obtenham determinadas funcionalidades dentro de seu próprio namespace de usuário sem afetar o host. Os recursos concedidos restritos ao pod desbloqueiam novas possibilidades, como executar aplicativos que exigem operações privilegiadas sem conceder acesso raiz completo no host. Novos casos de uso comuns que podem ser implementados com segurança são: execução de contêineres aninhados e builds de contêiner sem privilégios.

  • Configuração de contêiner sem privilégios: a maior parte da criação e configuração do contêiner não é executada como raiz no host, o que limita significativamente o impacto de muitas CVEs.

Nada disso é verdade quando namespaces de usuário não são usados. Se o contêiner for executado como raiz, quando os namespaces de usuário não forem usados, o processo será executado como raiz no host, os recursos serão válidos no host e a configuração do contêiner será feita como raiz no host.

Antes de começar

Antes de começar, certifique-se de que você tenha o seguinte:

Limitações

Habilitar namespaces de usuário

Não há configurações necessárias para usar esse recurso. Se estiver usando a versão apropriada do AKS, tudo funcionará imediatamente.

  1. Crie um arquivo chamado mypod.yaml e copie-o para o manifesto a seguir:

    Para usar namespaces de usuário, o yaml precisa ter o campo hostUsers: false.

    apiVersion: v1
kind: Pod
metadata:
  name: userns
spec:
  hostUsers: false
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian

  2. Implante o aplicativo usando o comando kubectl apply e especifique o nome do manifesto YAML.

    kubectl apply -f mypod.yaml

  3. Verifique o status dos pods implantados usando o comando kubectl get pods.

    kubectl get pods

  4. Execute no pod para verificar /proc/self/uid_map usando o kubectl exec comando:

    kubectl exec -ti userns -- bash
# Now inside the pod run
cat /proc/self/uid_map

A saída deve ter 65536 na última coluna. Por exemplo:

0  833617920      65536

CVEs mitigadas

Aqui estão algumas CVEs que são completamente/parcialmente mitigadas com namespaces de usuário.

Tenha em mente que a lista não é exaustiva, é apenas uma seleção de CVEs com pontuação alta que são atenuadas:

Para saber mais, leia esta postagem no blog com informações adicionais sobre namespaces de usuário.

Armadura de aplicativo

Para limitar as ações de contêineres, use o módulo de segurança de kernel do Linux AppArmor. AppArmor está disponível como parte do sistema operacional de nó do AKS subjacente e está 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.

Observação

O Azure Linux 3.0 não oferece suporte ao AppArmor. Para nós do Azure Linux 3.0, a recomendação é utilizar o SELinux em vez do AppArmor para controle de acesso obrigatório.

Perfis de AppArmor em uso em um cluster do AKS para limitar as ações de contêiner

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 corretamente e aplicado ao AppArmor, você não verá nenhuma saída e retornará 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 o AppArmor, confira Perfis do AppArmor no Kubernetes.

Computação segura (seccomp)

Enquanto o AppArmor funciona com 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 suporte nativo pelo containerd runtime usado pelos nós do AKS. Com o seccomp, você pode limitar as chamadas do sistema de um contêiner. O Seccomp estabelece uma camada extra de proteção contra vulnerabilidades comuns de chamada do sistema exploradas por atores mal-intencionados e permite que você especifique um perfil padrão para todas as cargas de trabalho no nó.

Configurar um perfil seccomp padrão (versão prévia)

Você pode aplicar perfis seccomp padrão usando configurações de nó personalizadas ao criar um novo pool de nós do Linux. Há dois valores com suporte no AKS: RuntimeDefault e Unconfined. Algumas cargas de trabalho podem exigir um número menor de restrições de syscall do que outras. Isso significa que eles podem falhar durante o runtime com o perfil 'RuntimeDefault'. Para atenuar essa falha, você pode especificar o perfil de Unconfined. Se sua carga de trabalho exigir um perfil personalizado, consulte Configurar um perfil seccomp personalizado.

Limitações

  • SeccompDefault não é um parâmetro suportado para pools de nós do Windows.
  • SeccompDefault estará disponível a partir da API 2024-09-02-preview.

Importante

As versões prévias de recursos do AKS estão disponíveis em uma base de autoatendimento e aceitação. As versões prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Registrar o sinalizador de recurso KubeletDefaultSeccompProfilePreview

  1. Registre o sinalizador de recurso KubeletDefaultSeccompProfilePreview usando o comando az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"

    Demora alguns minutos para o status exibir Registrado.

  2. Verifique o status do registro usando o comando az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"

  3. Quando o status reflete Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o comando az provider register.

    az provider register --namespace Microsoft.ContainerService

Restringir as chamadas do sistema do contêiner com seccomp

1. Siga as etapas para aplicar um perfil seccomp na configuração do kubelet especificando "seccompDefault": "RuntimeDefault".

RuntimeDefault usa o perfil de seccomp padrão do contêiner, restringindo determinadas chamadas do sistema para aprimorar a segurança. As chamadas restritas falharão. Para obter mais informações, consulte o perfil de seccomp padrão containerD.

2. Verifique se a configuração foi aplicada.

Você pode confirmar se as configurações são aplicadas aos nós conectando-se ao host e verificando se as alterações de configuração foram feitas no sistema de arquivos.

3. Solucionar problemas de falhas de cargas de trabalho.

Quando SeccompDefault está habilitado, o perfil de seccomp padrão do runtime do contêiner é usado por padrão para todas as cargas de trabalho agendadas no nó. Isso pode fazer com que as cargas de trabalho falhem devido a chamadas bloqueadas. Se uma falha de carga de trabalho tiver ocorrido, você poderá ver erros como:

  • A carga de trabalho é existente inesperadamente depois que o recurso é habilitado, com erro de "permissão negada".
  • Mensagens de erro seccomp também podem ser vistas em auditoria ou syslog substituindo SCMP_ACT_ERRNO por SCMP_ACT_LOG no perfil padrão.

Se você tiver os erros acima, recomendamos que você altere seu perfil seccomp para Unconfined. Unconfined não impõe restrições às chamadas, permitindo todas as chamadas do sistema, o que reduz a segurança.

Configurar um perfil de seccomp personalizado

Com um perfil seccomp personalizado, você pode ter um controle mais granular sobre chamadas restritas. 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 posterior, você precisa configurar:

    {
  "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 posterior, você precisa configurar:

    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 ser executado pelo filtro seccomp, conforme mostrado na saída de exemplo:
    kubectl get pods

NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s

Para obter ajuda para solucionar problemas de seu perfil seccomp, consulte o artigo Solucionar problemas de configuração de perfil seccomp no Serviço de Kubernetes do Azure.

Opções de perfil de segurança seccomp

Os perfis de segurança seccomp são um conjunto de chamadas syscalls definidas permitidas ou restritas. A maioria dos runtimes de contêiner tem um perfil seccomp padrão semelhante, se não o mesmo que o que o Docker usa. Para obter mais informações sobre perfis disponíveis, consulte os perfis de seccomp padrão do Docker ou containerD.

O AKS usa o perfil de seccomp padrão containerD para nosso RuntimeDefault quando você configura o seccomp usando a configuração de nó personalizado.

Chamadas syscalls significativas bloqueadas pelo perfil padrão

O Docker e containerD mantêm listas de permissões de chamadas seguras. Esta tabela lista as chamadas syscalls significativas (mas não todas) que são efetivamente bloqueadas porque não estão na lista de permissões. Se qualquer uma das chamadas bloqueadas for necessária para sua carga de trabalho, não use o perfil RuntimeDefault seccomp.

Quando são feitas alterações no Docker e no containerD, o AKS atualiza sua configuração padrão para corresponder. As atualizações dessa lista podem causar falha na carga de trabalho. Para ver as atualizações de versão, consulte as notas de versão do AKS.

Chamada de syscall bloqueada Descrição
acct Syscall de contabilidade que pode permitir que os contêineres desabilitem seus próprios limites de recurso ou contabilidade de processo. Também fechado por CAP_SYS_PACCT.
add_key Impedir que os contêineres usem o keyring do kernel, que não é espaçado por nomes.
bpf Negar o carregamento de programas bpf potencialmente persistentes no kernel, já fechado por CAP_SYS_ADMIN.
clock_adjtime A hora/data não está com o nome espaçado. Também fechado por CAP_SYS_TIME.
clock_settime A hora/data não está com o nome espaçado. Também fechado por CAP_SYS_TIME.
clone Negar a clonagem de novos namespaces. Também fechado por sinalizadores CAP_SYS_ADMIN for CLONE_*, exceto CLONE_NEWUSER.
create_module Negar manipulação e funções em módulos de kernel. Obsoleto. Também fechado por CAP_SYS_MODULE.
delete_module Negar manipulação e funções em módulos de kernel. Também fechado por CAP_SYS_MODULE.
finit_module Negar manipulação e funções em módulos de kernel. Também fechado por CAP_SYS_MODULE.
get_kernel_syms Negar a recuperação de símbolos de kernel e módulo exportados. Obsoleto.
get_mempolicy Syscall que modifica a memória do kernel e as configurações NUMA. Já fechado por CAP_SYS_NICE.
init_module Negar manipulação e funções em módulos de kernel. Também fechado por CAP_SYS_MODULE.
ioperm Impedir que os contêineres modifiquem os níveis de privilégio de E/S do kernel. Já fechado por CAP_SYS_RAWIO.
iopl Impedir que os contêineres modifiquem os níveis de privilégio de E/S do kernel. Já fechado por CAP_SYS_RAWIO.
kcmp Restrinja os recursos de inspeção do processo, já bloqueados por remoção CAP_SYS_PTRACE.
kexec_file_load Irmã syscall de kexec_load que faz a mesma coisa, argumentos ligeiramente diferentes. Também fechado por CAP_SYS_BOOT.
kexec_load Negue o carregamento de um novo kernel para execução posterior. Também fechado por CAP_SYS_BOOT.
keyctl Impedir que os contêineres usem o keyring do kernel, que não é espaçado por nomes.
lookup_dcookie Syscall de rastreamento/criação de perfil, que pode vazar informações no host. Também fechado por CAP_SYS_ADMIN.
mbind Syscall que modifica a memória do kernel e as configurações NUMA. Já fechado por CAP_SYS_NICE.
mount Negar montagem, já fechado por CAP_SYS_ADMIN.
move_pages Syscall que modifica a memória do kernel e as configurações NUMA.
nfsservctl Negar interação com o daemon nfs do kernel. Obsoleto desde o Linux 3.1.
open_by_handle_at Causa de uma fuga de contêiner antiga. Também fechado por CAP_DAC_READ_SEARCH.
perf_event_open Syscall de rastreamento/criação de perfil, que pode vazar informações no host.
personality Impedir que o contêiner habilite a emulação do BSD. Não inerentemente perigoso, mas mal testado, potencial para vulns kernel.
pivot_root Negar pivot_root, deve ser uma operação privilegiada.
process_vm_readv Restrinja os recursos de inspeção do processo, já bloqueados por remoção CAP_SYS_PTRACE.
process_vm_writev Restrinja os recursos de inspeção do processo, já bloqueados por remoção CAP_SYS_PTRACE.
ptrace Syscall de rastreamento/criação de perfil. Bloqueado nas versões do kernel do Linux antes da 4.8 para evitar o bypass do seccomp. Os processos arbitrários de rastreamento/criação de perfil já estão bloqueados descartando CAP_SYS_PTRACE, pois podem vazar informações sobre o host.
query_module Negar manipulação e funções em módulos de kernel. Obsoleto.
quotactl Chamada de cota que pode permitir que os contêineres desabilitem seus próprios limites de recursos ou contabilidade de processo. Também fechado por CAP_SYS_ADMIN.
reboot Não permita que os contêineres reinicializem o host. Também fechado por CAP_SYS_BOOT.
request_key Impedir que os contêineres usem o keyring do kernel, que não é espaçado por nomes.
set_mempolicy Syscall que modifica a memória do kernel e as configurações NUMA. Já fechado por CAP_SYS_NICE.
setns Negar associar um thread a um namespace. Também fechado por CAP_SYS_ADMIN.
settimeofday A hora/data não está com o nome espaçado. Também fechado por CAP_SYS_TIME.
stime A hora/data não está com o nome espaçado. Também fechado por CAP_SYS_TIME.
swapon Negar a troca inicial/parada para o arquivo/dispositivo. Também fechado por CAP_SYS_ADMIN.
swapoff Negar a troca inicial/parada para o arquivo/dispositivo. Também fechado por CAP_SYS_ADMIN.
sysfs Chamada obsoleta.
_sysctl Obsoleto, substituído por /proc/sys.
umount Deve ser uma operação privilegiada. Também fechado por CAP_SYS_ADMIN.
umount2 Deve ser uma operação privilegiada. Também fechado por CAP_SYS_ADMIN.
unshare Negar a clonagem de novos namespaces para processos. Também fechado por CAP_SYS_ADMIN, com exceção de unshare --user.
uselib Chamadas mais antigas relacionadas a bibliotecas compartilhadas, não usadas por muito tempo.
userfaultfd Tratamento de falhas de página do userspace, em grande parte necessário para migração de processo.
ustat Chamada obsoleta.
vm86 Na máquina virtual do modo real do kernel x86. Também fechado por CAP_SYS_ADMIN.
vm86old Na máquina virtual do modo real do kernel x86. Também fechado por CAP_SYS_ADMIN.

Próximas etapas

Para obter as práticas recomendadas associadas, confira Práticas recomendadas de segurança e atualizações de cluster no AKS e Práticas recomendadas de segurança de pod no AKS.

  • Last updated on