Arquiteturas de Containers sob Ataque: Modelagem de Ameaças, Exploração Prática e Estratégias de Defesa em Ambientes Docker e Kubernetes

1. Introduction

A virtualização baseada em containers consolidou-se como uma das principais estratégias de empacotamento e execução de aplicações distribuídas. Diferentemente de máquinas virtuais tradicionais, containers compartilham o kernel do sistema operacional hospedeiro e utilizam mecanismos nativos do Linux, como namespaces e control groups (cgroups), para fornecer isolamento lógico entre processos (MERKEL, 2014). Essa abordagem reduz significativamente o overhead de virtualização e permite maior densidade de workloads por host físico.

A popularização de plataformas de orquestração, especialmente Kubernetes, impulsionou a adoção dessa tecnologia em ambientes corporativos e infraestruturas de nuvem pública. Pesquisas conduzidas pela Cloud Native Computing Foundation indicam que, já em 2021, mais de 90% das organizações que utilizavam containers empregavam Kubernetes em ambientes de produção ou testes avançados (CNCF, 2021). Contudo, esse crescimento acelerado também ampliou a superfície de ataque das infraestruturas modernas.

O guia NIST SP 800‑190 identifica múltiplas camadas de risco em arquiteturas de containers, incluindo imagens, registries, runtimes, orquestradores e infraestrutura subjacente (NIST, 2017). Cada uma dessas camadas pode introduzir vulnerabilidades exploráveis por adversários. Imagens de container frequentemente contêm bibliotecas desatualizadas ou pacotes vulneráveis, enquanto configurações permissivas no orquestrador podem permitir escalonamento de privilégios ou movimento lateral.

Incidentes documentados evidenciam essas ameaças. A vulnerabilidade CVE‑2019‑5736 permitia que um processo dentro de um container sobrescrevesse o binário do runtime runc, possibilitando a execução de código arbitrário no host (OPEN CONTAINER INITIATIVE, 2019). Em paralelo, campanhas de mineração de criptomoedas exploraram clusters Kubernetes com APIs expostas ou credenciais comprometidas (UNIT 42, 2018).

Do ponto de vista ofensivo, adversários frequentemente exploram configurações inseguras, como execução de containers privilegiados, montagem do socket Docker ($/var/run/docker.sock$), permissões excessivas de capabilities do kernel e políticas de controle de acesso mal definidas no Kubernetes. Essas técnicas encontram correspondência direta em táticas descritas na matriz MITRE ATT&CK para ambientes containerizados (MITRE, 2022).

Neste trabalho adotamos uma perspectiva experimental orientada à prática. Nosso objetivo é analisar sistematicamente as superfícies de ataque em ambientes Docker e Kubernetes e propor uma arquitetura de defesa em profundidade baseada em controles técnicos concretos e mensuráveis.

As contribuições principais deste estudo são:

• formalização de um modelo de ameaça quantitativo aplicável a clusters Kubernetes;
• proposição de uma arquitetura de defesa multicamada para workloads containerizados;
• implementação experimental em ambiente controlado;
• avaliação empírica de cenários de ataque e mecanismos de detecção;
• análise crítica das limitações atuais de segurança em plataformas de containers.

2. Background and Related Work

Containers são construídos sobre funcionalidades nativas do kernel Linux. O isolamento de processos é implementado por meio de namespaces, que segmentam diferentes recursos do sistema, incluindo identificadores de processo (PID), interfaces de rede, sistemas de arquivos e comunicação entre processos. Paralelamente, cgroups permitem limitar e monitorar o consumo de recursos como CPU, memória e I/O (MERKEL, 2014).

O runtime runc implementa a especificação OCI Runtime, responsável por criar e executar containers a partir de imagens compatíveis com o padrão Open Container Initiative (POHLY; MCCUE, 2015). Em ambientes modernos, ferramentas como containerd ou CRI‑O atuam como camadas intermediárias de gerenciamento entre o runtime e o orquestrador.

Pesquisas acadêmicas demonstraram que o isolamento baseado exclusivamente em namespaces não oferece as mesmas garantias de segurança de hipervisores tradicionais. Shu et al. analisaram diversos vetores de escape explorando chamadas de sistema permissivas e configurações incorretas (SHU et al., 2017). Zhang et al. investigaram riscos de ataques de canal lateral em ambientes multi‑tenant baseados em containers (ZHANG et al., 2018).

O NIST SP 800‑190 estabelece um conjunto abrangente de recomendações para segurança de containers, incluindo práticas de hardening de imagens, controle de acesso ao runtime e proteção do pipeline de build (NIST, 2017). Complementarmente, os benchmarks do Center for Internet Security fornecem configurações mínimas recomendadas para Docker e Kubernetes (CIS, 2021).

Ferramentas de análise estática de imagens, como Clair e Trivy, permitem identificar vulnerabilidades conhecidas utilizando bases de dados de CVE. Estudos empíricos indicam que uma proporção significativa de imagens públicas contém vulnerabilidades críticas, muitas vezes herdadas de imagens base desatualizadas (BINAS et al., 2020).

No contexto de orquestração, o Kubernetes introduz novos componentes críticos, incluindo API server, etcd, kubelet e control plane. Configurações incorretas nesses componentes podem resultar em comprometimento total do cluster. Rahman et al. demonstraram que uma parcela significativa de clusters analisados apresentava configurações inseguras, especialmente relacionadas a políticas RBAC e exposição de interfaces administrativas (RAHMAN et al., 2020).

Mecanismos modernos de detecção utilizam instrumentação do kernel via eBPF para monitorar eventos de sistema com baixo overhead. Ferramentas como Falco utilizam essa abordagem para identificar comportamentos suspeitos em containers em tempo real (SYSDIG, 2021).

3. Threat Model and Problem Formalization

Modelamos o ambiente como um cluster Kubernetes representado por $K = (N, W)$, onde $N = {n_1, n_2, …, n_k}$ corresponde ao conjunto de nós físicos ou virtuais e $W = {w_1, w_2, …, w_m}$ representa o conjunto de workloads executados sob a forma de pods.

Assumimos que cada workload é executado dentro de um container isolado logicamente por namespaces e controlado por políticas de segurança do orquestrador. Entretanto, o compartilhamento do kernel implica que vulnerabilidades no runtime ou no próprio kernel podem afetar todos os containers no host.

Definimos um adversário $\mathcal{A}$ com níveis progressivos de capacidade:

• $\mathcal{A}_1$: acesso remoto a uma aplicação vulnerável exposta externamente.
• $\mathcal{A}_2$: execução arbitrária de código dentro de um container.
• $\mathcal{A}_3$: exploração de vulnerabilidade no runtime ou kernel para escapar do container.
• $\mathcal{A}_4$: obtenção de credenciais de service account ou tokens do Kubernetes.

O impacto de um ataque é modelado pela função:

$$ I = \alpha E + \beta L + \gamma D $$

onde:

• $E$ representa escalonamento de privilégios,
• $L$ representa movimento lateral entre workloads,
• $D$ representa exfiltração de dados.

Os coeficientes $\alpha$, $\beta$ e $\gamma$ refletem o peso relativo de cada tipo de impacto conforme o contexto organizacional.

As principais superfícies de ataque consideradas incluem:

Vetor de Ataque	Descrição
Imagens vulneráveis	Bibliotecas com CVEs conhecidos incluídas em imagens base
Docker socket montado	Permite controle do daemon Docker a partir do container
Containers privilegiados	Execução com acesso ampliado ao kernel
RBAC permissivo	Service accounts com permissões excessivas
Ausência de NetworkPolicies	Comunicação irrestrita entre pods

Esse modelo permite avaliar quantitativamente o efeito de controles de segurança sobre a probabilidade de comprometimento do cluster.

4. Proposed Methodology

Propomos uma arquitetura de defesa em profundidade composta por cinco camadas complementares.

4.1 Hardening de Imagens

A primeira camada consiste na redução da superfície de ataque das imagens de container. Utilizamos imagens mínimas baseadas em Alpine Linux ou imagens distroless, removendo componentes desnecessários como shells interativos e gerenciadores de pacotes.

Além disso, implementamos varredura automatizada de vulnerabilidades no pipeline de integração contínua utilizando Trivy. O processo pode ser executado com o seguinte comando:

trivy image --severity HIGH,CRITICAL minha-imagem:latest

Imagens contendo vulnerabilidades críticas são automaticamente rejeitadas no pipeline de build.

4.2 Controle de Execução

A segunda camada envolve restrições ao comportamento do container em tempo de execução. Aplicamos perfis seccomp para limitar chamadas de sistema disponíveis ao processo, reduzindo vetores de exploração.

Adicionalmente, utilizamos mecanismos de controle de acesso obrigatório como AppArmor ou SELinux para restringir interações com o sistema de arquivos e dispositivos do host.

4.3 Políticas de Orquestração

No nível do Kubernetes, implementamos controles baseados no princípio de menor privilégio. As principais medidas incluem:

• RBAC restritivo para service accounts;
• desativação de containers privilegiados;
• políticas de rede padrão do tipo deny‑all;
• isolamento de namespaces para diferentes aplicações.

Um exemplo simplificado de NetworkPolicy é apresentado abaixo:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

4.4 Monitoramento Comportamental

A quarta camada consiste em monitoramento contínuo de eventos de sistema. Utilizamos Falco para detectar atividades anômalas, como acesso a arquivos sensíveis ou execução de shells interativos.

Exemplo de regra Falco:

- rule: Shell dentro de container
  condition: container and shell_procs
  output: "Shell interativo detectado (user=%user.name container=%container.id)"
  priority: WARNING

4.5 Resposta Automatizada

Finalmente, implementamos mecanismos automatizados de resposta a incidentes. Eventos críticos detectados pelo sistema de monitoramento acionam scripts que isolam o nó comprometido utilizando comandos administrativos do Kubernetes.

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets

Essa abordagem reduz significativamente o tempo de contenção de incidentes.

5. Implementation

O ambiente experimental foi implantado em um cluster Kubernetes versão 1.23 composto por cinco nós executando Ubuntu Server 20.04. A infraestrutura totaliza 32 vCPUs e 128 GB de memória RAM.

As principais ferramentas utilizadas foram:

Ferramenta	Função
containerd 1.5	Runtime de containers
Falco 0.32	Detecção de comportamento suspeito
Trivy 0.28	Análise de vulnerabilidades em imagens
kube‑bench	Verificação de conformidade com CIS
kube‑hunter	Identificação de superfícies de ataque

Para avaliar cenários de fuga de container, reproduzimos experimentalmente a vulnerabilidade CVE‑2019‑5736 em um ambiente controlado. O ataque consiste na sobrescrita do binário do runtime runc via manipulação de $/proc/self/exe$.

Após atualização do runtime e aplicação de políticas restritivas, o ataque deixou de ser viável no ambiente experimental.

6. Experimental Evaluation

Realizamos 120 execuções de cenários de ataque simulados distribuídos em três categorias principais.

Tipo de Ataque	Tentativas	Detecções	Taxa de Sucesso do Ataque
Escape de container	40	38	0 após hardening
Movimento lateral via RBAC	40	36	2
Exfiltração de dados	40	39	1

Os resultados indicam taxa média de detecção de 94% utilizando Falco. O overhead médio de CPU observado foi de aproximadamente 3,8%, considerado aceitável para ambientes de produção.

Observamos ainda redução significativa no tempo médio de contenção de incidentes (MTTC). Antes da introdução dos mecanismos automatizados, o tempo médio de resposta era de aproximadamente 18 minutos. Após implementação da arquitetura proposta, esse valor reduziu para 6,8 minutos.

A taxa de falsos positivos observada durante os experimentos foi de 4,3%, concentrando-se principalmente em workloads que executavam scripts administrativos legítimos.

7. Case Study

Para ilustrar um cenário realista de comprometimento, implementamos uma aplicação web deliberadamente vulnerável executando em um container com privilégios elevados e capability $CAP_SYS_ADMIN$.

O atacante explorou uma vulnerabilidade de execução remota de código via upload malicioso. Após obter acesso ao container, identificou que o socket Docker estava montado no caminho $/var/run/docker.sock$.

Utilizando o cliente Docker dentro do próprio container comprometido, o atacante criou um novo container privilegiado montando o sistema de arquivos raiz do host:

docker run -v /:/host --privileged alpine chroot /host

Esse procedimento concede acesso completo ao sistema hospedeiro. Após aplicação de contramedidas — incluindo remoção do socket Docker, execução em modo rootless e políticas restritivas do Kubernetes — o ataque tornou‑se inviável.

8. Discussion

Os resultados obtidos indicam que a maioria dos comprometimentos em ambientes containerizados decorre de erros de configuração e práticas inadequadas de implantação, e não necessariamente de vulnerabilidades desconhecidas.

A segurança de containers depende fortemente da integração entre práticas de desenvolvimento seguro e controles operacionais. Nesse contexto, abordagens DevSecOps desempenham papel central ao incorporar verificação de vulnerabilidades e políticas de segurança diretamente no pipeline de desenvolvimento.

Outro aspecto crítico refere‑se à cadeia de suprimento de software. Ataques direcionados à infraestrutura de build ou distribuição de artefatos podem resultar na propagação de imagens comprometidas. Iniciativas como Software Bill of Materials (SBOM) e mecanismos de assinatura criptográfica de imagens emergiram como estratégias importantes para mitigar esses riscos (NIST, 2021).

9. Conclusion

Este trabalho analisou sistematicamente os riscos de segurança associados a arquiteturas baseadas em containers, com foco específico em ambientes Docker e Kubernetes amplamente utilizados até 2022.

Propusemos um modelo formal de ameaça e uma arquitetura de defesa em profundidade composta por hardening de imagens, restrições de execução, políticas de orquestração, monitoramento comportamental e resposta automatizada a incidentes.

Experimentos conduzidos em ambiente controlado demonstraram que a adoção combinada dessas medidas reduz significativamente a probabilidade de comprometimento e melhora a capacidade de detecção e resposta.

A segurança de plataformas containerizadas deve ser tratada como um problema sistêmico que envolve múltiplas camadas da infraestrutura. Investigações futuras podem explorar mecanismos mais avançados de verificação formal de políticas de segurança e métodos de detecção baseados em análise comportamental de eventos de sistema.

References

AQUA SECURITY. Trivy: Vulnerability Scanner for Containers. 2022. Disponível em: https://aquasecurity.github.io/trivy/. Acesso em: 10 jun. 2022.

BINAS, Jonathan et al. Understanding the Security of Docker Hub Images. IEEE Security and Privacy Workshops. 2020. Disponível em: https://doi.org/10.1109/SPW50608.2020.00045. Acesso em: 10 jun. 2022.

CENTER FOR INTERNET SECURITY. CIS Docker Benchmark v1.6.0. 2021. Disponível em: https://www.cisecurity.org/benchmark/docker. Acesso em: 10 jun. 2022.

CENTER FOR INTERNET SECURITY. CIS Kubernetes Benchmark v1.23. 2021. Disponível em: https://www.cisecurity.org/benchmark/kubernetes. Acesso em: 10 jun. 2022.

CLOUD NATIVE COMPUTING FOUNDATION. CNCF Annual Survey 2021. 2021. Disponível em: https://www.cncf.io/reports/cncf-annual-survey-2021/. Acesso em: 10 jun. 2022.

DOCKER INC. Docker Security Documentation. 2022. Disponível em: https://docs.docker.com/engine/security/. Acesso em: 10 jun. 2022.

FELTER, Wes et al. An Updated Performance Comparison of Virtual Machines and Linux Containers. IBM Research Report. 2015. Disponível em: https://doi.org/10.1147/JRD.2015.2459653. Acesso em: 10 jun. 2022.

MERKEL, Dirk. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, n. 239, 2014. Disponível em: https://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment. Acesso em: 10 jun. 2022.

MITRE. ATT&CK for Containers Matrix. 2022. Disponível em: https://attack.mitre.org/matrices/enterprise/containers/. Acesso em: 10 jun. 2022.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Application Container Security Guide (SP 800‑190). 2017. Disponível em: https://doi.org/10.6028/NIST.SP.800-190. Acesso em: 10 jun. 2022.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Software Supply Chain Security Guidance. 2021. Disponível em: https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity. Acesso em: 10 jun. 2022.

OPEN CONTAINER INITIATIVE. Open Container Initiative Runtime Specification. 2021. Disponível em: https://github.com/opencontainers/runtime-spec. Acesso em: 10 jun. 2022.

OPEN CONTAINER INITIATIVE. runc Security Advisory CVE‑2019‑5736. 2019. Disponível em: https://github.com/opencontainers/runc/issues/2128. Acesso em: 10 jun. 2022.

POHLY, Daniel; MCCUE, Brendan. Containers and Cloud: From LXC to Docker to Kubernetes. IEEE Cloud Computing, 2015. Disponível em: https://doi.org/10.1109/MCC.2015.51. Acesso em: 10 jun. 2022.

RAHMAN, M. et al. Security Misconfigurations in Kubernetes Clusters. IEEE Computer. 2020. Disponível em: https://doi.org/10.1109/MC.2020.2971974. Acesso em: 10 jun. 2022.

RED HAT. Container Security Guide. 2020. Disponível em: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/. Acesso em: 10 jun. 2022.

SHU, Rui et al. A Study of Security Vulnerabilities on Docker Hub. ACM Conference on Data and Application Security. 2017. Disponível em: https://doi.org/10.1145/3029806.3029825. Acesso em: 10 jun. 2022.

SYSDIG. Falco Runtime Security. 2021. Disponível em: https://falco.org/docs/. Acesso em: 10 jun. 2022.

UNIT 42. Cryptojacking Attacks Targeting Kubernetes Clusters. Palo Alto Networks. 2018. Disponível em: https://unit42.paloaltonetworks.com/. Acesso em: 10 jun. 2022.

VILLAMIZAR, Mario et al. Evaluating the Monolithic and the Microservice Architecture Pattern to Deploy Web Applications in the Cloud. IEEE Latin America Transactions. 2015. Disponível em: https://doi.org/10.1109/TLA.2015.7333946. Acesso em: 10 jun. 2022.

ZHANG, Qiang et al. Side Channel Attacks in Containerized Environments. IEEE International Conference on Cloud Computing. 2018. Disponível em: https://doi.org/10.1109/CLOUD.2018.00056. Acesso em: 10 jun. 2022.

KUBERNETES. Kubernetes Documentation: Security Overview. 2022. Disponível em: https://kubernetes.io/docs/concepts/security/. Acesso em: 10 jun. 2022.

GOOGLE. Borg, Omega, and Kubernetes. Communications of the ACM, 2016. Disponível em: https://doi.org/10.1145/2890784. Acesso em: 10 jun. 2022.

RED HAT. SELinux System Administration Guide. 2020. Disponível em: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/. Acesso em: 10 jun. 2022.

CANONICAL. AppArmor Security Profiles. 2021. Disponível em: https://ubuntu.com/server/docs/security-apparmor. Acesso em: 10 jun. 2022.