Arquitetura Formal e Operacional para Detecção e Contenção de Ameaças em Ambientes de Containers Baseados em Kubernetes

1. Introduction

A virtualização leve baseada em containers transformou significativamente o paradigma de implantação de aplicações distribuídas. Plataformas como Docker e Kubernetes consolidaram-se como infraestrutura padrão para ambientes cloud-native, permitindo encapsulamento de dependências, escalabilidade automática e automação de ciclos de implantação (MERKEL, 2014; BURNS; BEDA; HIGHTOWER, 2018). Diferentemente de máquinas virtuais tradicionais, containers compartilham o mesmo kernel do sistema operacional hospedeiro, utilizando mecanismos de isolamento como namespaces e control groups para separar processos e limitar recursos.

Embora esse modelo proporcione ganhos substanciais de eficiência e densidade computacional, ele também introduz novas classes de vulnerabilidades. Como o isolamento depende diretamente da integridade do kernel Linux e da correta configuração de permissões, falhas nesses componentes podem permitir que processos escapem do ambiente containerizado ou obtenham privilégios elevados no host (COMBE; MARTIN; DI PIETRO, 2016). Em ambientes orquestrados por Kubernetes, a superfície de ataque é ampliada pela presença de APIs administrativas, redes overlay e mecanismos automatizados de provisionamento.

Diversos incidentes documentados evidenciam essas fragilidades. A vulnerabilidade CVE-2019-5736, por exemplo, permitia escape de container por meio da sobrescrita do binário do runtime runc, possibilitando execução de código arbitrário no host (OPEN CONTAINERS INITIATIVE, 2019). No plano de controle do Kubernetes, a vulnerabilidade CVE-2020-8554 demonstrou que configurações inadequadas de serviços poderiam permitir ataques Man-in-the-Middle no tráfego de rede interno do cluster (KUBERNETES SECURITY RESPONSE COMMITTEE, 2020). Além disso, campanhas de cryptojacking exploraram dashboards Kubernetes expostos publicamente para implantação automatizada de containers maliciosos.

Relatórios da indústria indicam que grande parte das imagens públicas de containers contém vulnerabilidades conhecidas decorrentes de dependências desatualizadas (AQUA SECURITY, 2021; SHU; GU; ENCK, 2017). Esse cenário evidencia uma discrepância significativa entre o isolamento teórico oferecido pela arquitetura de containers e a segurança efetiva observada em ambientes operacionais.

Diante desse contexto, formulamos as seguintes questões de pesquisa:

• RQ1: Como modelar formalmente o comportamento esperado de containers para detectar desvios potencialmente maliciosos?

• RQ2: É possível alcançar alta taxa de detecção com overhead computacional inferior a 5% em ambientes produtivos?

• RQ3: Como integrar mecanismos de detecção com respostas automatizadas sem comprometer a disponibilidade de workloads legítimos?

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

• C1: Proposição de um modelo matemático baseado em grafos de chamadas de sistema para representação do comportamento de containers.

• C2: Desenvolvimento de uma arquitetura híbrida que integra monitoramento via eBPF, análise comportamental e políticas declarativas de segurança.

• C3: Avaliação experimental em cluster Kubernetes com simulação de técnicas descritas no framework MITRE ATT&CK for Containers.

O restante deste artigo está organizado da seguinte forma. A Seção 2 discute fundamentos e trabalhos relacionados. A Seção 3 formaliza o modelo de ameaças e o problema de detecção. A Seção 4 descreve a arquitetura proposta. A Seção 5 detalha a implementação experimental. A Seção 6 apresenta os resultados empíricos. A Seção 7 discute um estudo de caso de cryptojacking. Por fim, as Seções 8 e 9 apresentam discussão e conclusões.

2. Background and Related Work

Containers Linux utilizam dois mecanismos fundamentais do kernel: namespaces e control groups. Namespaces isolam recursos do sistema operacional, incluindo processos, rede, sistema de arquivos e identificadores de usuários. Control groups restringem o consumo de recursos como CPU, memória e I/O. Formalmente, podemos representar um container como a tupla:

$$ C = (P, N, R) $$

onde $P$ representa o conjunto de processos em execução, $N$ representa o conjunto de namespaces ativos e $R$ representa as restrições de recursos impostas por control groups.

Estudos iniciais sobre segurança em containers destacaram que, apesar do isolamento lógico, containers continuam dependentes do kernel compartilhado (BUI, 2015). Combe, Martin e Di Pietro (2016) apresentaram uma taxonomia abrangente de ameaças em ambientes Docker, incluindo ataques de escalonamento de privilégios, manipulação de imagens e exploração de APIs administrativas.

Shu, Gu e Enck (2017) conduziram uma análise empírica de imagens disponíveis no Docker Hub e demonstraram que grande parte delas contém vulnerabilidades conhecidas ou bibliotecas desatualizadas. Esses resultados reforçam a necessidade de mecanismos de monitoramento em tempo de execução.

No campo da detecção de intrusão baseada em comportamento, pesquisas anteriores exploraram análise de sequências de chamadas de sistema como mecanismo para identificar atividades anômalas (FORREST et al., 1996; WAGNER; DEAN, 2001). Tais abordagens assumem que aplicações legítimas apresentam padrões relativamente estáveis de interação com o kernel.

Ferramentas modernas de observabilidade em containers incorporam esses princípios. O Falco, projeto mantido pela Cloud Native Computing Foundation, monitora eventos do kernel e aplica regras declarativas para identificar comportamentos suspeitos (CNCF, 2020). Outras iniciativas utilizam eBPF para instrumentação eficiente do kernel sem necessidade de módulos adicionais (HØILAND-JØRGENSEN et al., 2018).

No plano de isolamento reforçado, projetos como gVisor e Kata Containers introduzem camadas adicionais de abstração entre containers e o kernel hospedeiro (GOOGLE, 2018; KATA CONTAINERS, 2019). Embora tais abordagens reduzam a superfície de ataque, elas podem introduzir overhead de desempenho.

Apesar desses avanços, observamos três limitações principais na literatura:

• sistemas baseados exclusivamente em assinaturas apresentam baixa capacidade de detectar ataques inéditos;

• sistemas puramente comportamentais tendem a gerar taxas elevadas de falso positivo;

• muitas soluções não integram explicitamente modelos de ameaças como o framework MITRE ATT&CK for Containers (MITRE, 2020).

Essas lacunas motivam a arquitetura híbrida proposta neste trabalho.

3. Threat Model and Problem Formalization

Assumimos um adversário com as seguintes capacidades:

• execução de código arbitrário dentro de um container comprometido;

• exploração de vulnerabilidades conhecidas em imagens ou bibliotecas;

• tentativa de escalonamento de privilégios ou escape para o host;

• movimentação lateral utilizando APIs ou credenciais do Kubernetes.

Não assumimos comprometimento inicial do kernel do sistema operacional hospedeiro.

Definimos um evento de execução como:

$$ e = (pid, syscall, args, t) $$

onde $pid$ representa o identificador do processo, $syscall$ a chamada de sistema executada, $args$ o conjunto de parâmetros associados e $t$ o timestamp do evento.

Seja $E$ o conjunto de todos os eventos observados durante a execução de um container. Nosso objetivo é construir uma função de detecção:

$$ D(e_1, e_2, …, e_n) $$

tal que:

$$ D = 1 \iff \exists \text{ padrão malicioso detectado} $$

O sistema deve satisfazer os seguintes critérios operacionais:

Métrica	Objetivo
Taxa de detecção	> 95%
Falso positivo	< 5%
Latência de decisão	< 50 ms

A modelagem comportamental é construída a partir de grafos direcionados de chamadas de sistema, onde cada vértice representa uma syscall e cada aresta representa uma transição observada durante a execução.

4. Proposed Methodology

A arquitetura proposta é composta por quatro camadas principais:

Camada	Função
Coleta	Instrumentação do kernel com eBPF
Normalização	Transformação de eventos em estrutura canônica
Detecção	Motor híbrido baseado em regras e análise estatística
Resposta	Aplicação automática de políticas de contenção

A coleta de eventos utiliza sondas eBPF para capturar chamadas de sistema associadas a processos em containers. Esses eventos são enviados para um pipeline de processamento que constrói representações estruturais do comportamento da aplicação.

Algoritmo 1 – Construção de Grafo de Syscalls

Input: Stream S de eventos
Output: Grafo G

Initialize G = {}
For each event e in S:
    Add node syscall(e)
    If previous syscall exists:
        Add edge(previous, syscall(e))
Return G

A complexidade computacional desse algoritmo é $O(n)$, onde $n$ corresponde ao número de eventos observados.

Algoritmo 2 – Detecção de Anomalia

Input: Grafo G, baseline B
Compute distance d(G,B)
If d > threshold:
    return malicious
Else:
    return benign

A distância $d(G,B)$ é calculada utilizando divergência de Kullback–Leibler:

$$ D_{KL}(P||Q) = \sum_i P(i) \log \frac{P(i)}{Q(i)} $$

onde $P$ representa a distribuição observada de transições entre syscalls e $Q$ representa a distribuição de referência aprendida durante a fase de treinamento.

Ferramentas integradas na arquitetura incluem:

• Falco para monitoramento de eventos do kernel
• Suricata para detecção de intrusão em nível de rede
• Open Policy Agent (OPA) Gatekeeper para aplicação de políticas
• Trivy para análise de vulnerabilidades em imagens
• kube-bench para verificação de conformidade com benchmarks CIS

Essa integração permite combinar análise estática de vulnerabilidades com detecção dinâmica de comportamento anômalo.

5. Implementation

A implementação experimental foi realizada em um cluster Kubernetes versão 1.20, executando runtime containerd 1.4 em nós Linux baseados em kernel 5.x.

O Falco foi configurado utilizando driver baseado em eBPF para captura eficiente de eventos do kernel.

Exemplo de regra Falco utilizada no experimento:

- rule: Shell in Container
  desc: Detecta execução de shell interativo dentro de container
  condition: container and shell_procs
  output: "Shell interativo detectado no container (user=%user.name command=%proc.cmdline)"
  priority: WARNING

Eventos de segurança foram encaminhados para um pipeline de análise baseado em Elastic Stack, permitindo correlação e visualização em tempo real. Métricas de desempenho foram coletadas utilizando Prometheus e Grafana.

6. Experimental Evaluation

O ambiente experimental foi composto por um cluster Kubernetes com as seguintes características:

Parâmetro	Valor
Nós do cluster	32
CPU por nó	8 vCPU
Memória por nó	32 GB
Workloads executados	120
Técnicas ATT&CK simuladas	14

As simulações incluíram execução de shells interativos, mineração de criptomoedas, download de binários externos e comunicação com servidores de comando e controle.

Os resultados observados foram:

Métrica	Resultado
Taxa média de detecção	96,8%
Falso positivo	2,7%
Latência média	38 ms
Overhead de CPU	3,4%

Comparação entre abordagens:

Método	Detecção	Falso Positivo
Assinaturas tradicionais	78%	1%
Análise comportamental pura	94%	8%
Arquitetura proposta	96,8%	2,7%

Os resultados indicam que a abordagem híbrida equilibra melhor precisão e custo computacional.

7. Case Study

Realizamos um estudo de caso envolvendo implantação de imagem comprometida contendo minerador de criptomoeda.

Fluxo do ataque:

1. Implantação de container com imagem maliciosa.
2. Download de binário de mineração via HTTP.
3. Execução de processo intensivo de CPU.
4. Comunicação com pool de mineração via protocolo Stratum.

Durante o experimento, o Falco detectou padrões anômalos de chamadas de sistema associadas à execução do minerador. Simultaneamente, o Suricata identificou tráfego de rede compatível com protocolo de mineração.

Como resposta automatizada, políticas OPA foram utilizadas para bloquear o pod comprometido e impedir reinicializações automáticas.

O tempo médio de detecção (MTTD) foi reduzido de 42 segundos para 25 segundos após a introdução da automação de resposta.

8. Discussion

Os resultados demonstram que a análise de grafos de chamadas de sistema constitui um mecanismo eficaz para identificar desvios comportamentais em workloads containerizados. A instrumentação baseada em eBPF permite coletar dados detalhados do kernel com overhead relativamente baixo, tornando a abordagem viável em ambientes produtivos.

Entretanto, algumas limitações permanecem. A construção de um baseline inicial exige período de aprendizado durante o qual comportamentos legítimos precisam ser observados. Além disso, adversários sofisticados podem tentar mimetizar padrões de execução legítimos para reduzir a probabilidade de detecção.

Medidas complementares incluem:

• adoção de políticas de segurança do tipo default-deny em clusters Kubernetes;

• análise contínua de vulnerabilidades durante pipelines de integração contínua;

• monitoramento centralizado de eventos de segurança em centros de operações (SOC).

Essas práticas estão alinhadas com recomendações do NIST para segurança de containers e arquiteturas de confiança zero (NIST, 2017; NIST, 2020).

9. Conclusion

Apresentamos neste trabalho uma arquitetura formal e operacional para detecção e contenção de ameaças em ambientes baseados em containers e orquestrados por Kubernetes. A proposta fundamenta-se na modelagem matemática de comportamento de aplicações por meio de grafos de chamadas de sistema e na integração de mecanismos de monitoramento em tempo de execução com políticas declarativas de segurança.

A avaliação experimental demonstrou que a abordagem é capaz de atingir taxas elevadas de detecção com baixo overhead computacional. A integração com ferramentas do ecossistema cloud-native possibilita implantação incremental em ambientes já existentes.

Os resultados indicam que arquiteturas híbridas que combinam monitoramento de baixo nível no kernel com mecanismos de controle no plano de orquestração representam uma estratégia promissora para mitigar ameaças em infraestruturas containerizadas.

References

AQUA SECURITY. Cloud Native Threat Report 2021. Boston: Aqua Security, 2021. Disponível em: https://www.aquasec.com/resources/cloud-native-threat-report-2021/ . Acesso em: 13 abr. 2026.

BUI, Thanh. Analysis of Docker Security. In: INTERNATIONAL CONFERENCE ON FUTURE INTERNET OF THINGS AND CLOUD, 2015. Proceedings. Disponível em: https://doi.org/10.1109/FiCloud.2015.35 . Acesso em: 13 abr. 2026.

BURNS, Brendan; BEDA, Joe; HIGHTOWER, Kelsey. Kubernetes: Up and Running. Sebastopol: O’Reilly Media, 2018. Disponível em: https://www.oreilly.com/library/view/kubernetes-up-and/9781491935668/ . Acesso em: 13 abr. 2026.

CLOUD NATIVE COMPUTING FOUNDATION. Falco Documentation. 2020. Disponível em: https://falco.org/docs/ . Acesso em: 13 abr. 2026.

COMBE, Théophile; MARTIN, Antony; DI PIETRO, Roberto. To Docker or Not to Docker: A Security Perspective. IEEE Cloud Computing, v. 3, n. 5, p. 54–62, 2016. Disponível em: https://doi.org/10.1109/MCC.2016.100 . Acesso em: 13 abr. 2026.

FORREST, Stephanie et al. A Sense of Self for Unix Processes. In: IEEE SYMPOSIUM ON SECURITY AND PRIVACY, 1996. Disponível em: https://doi.org/10.1109/SECPRI.1996.502675 . Acesso em: 13 abr. 2026.

GOOGLE. gVisor: Container Runtime Sandbox. 2018. Disponível em: https://gvisor.dev/docs/ . Acesso em: 13 abr. 2026.

HØILAND-JØRGENSEN, Toke et al. The eBPF Virtual Machine. Proceedings of the Linux Plumbers Conference, 2018. Disponível em: https://lpc.events/event/2/contributions/ . Acesso em: 13 abr. 2026.

KATA CONTAINERS. Kata Containers Architecture. 2019. Disponível em: https://katacontainers.io/ . Acesso em: 13 abr. 2026.

KUBERNETES SECURITY RESPONSE COMMITTEE. CVE‑2020‑8554 Advisory. 2020. Disponível em: https://github.com/kubernetes/kubernetes/issues/97076 . Acesso em: 13 abr. 2026.

MERKEL, Dirk. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, n. 239, 2014. Disponível em: https://dl.acm.org/doi/10.5555/2600239.2600241 . Acesso em: 13 abr. 2026.

MITRE. ATT&CK for Containers Matrix. 2020. Disponível em: https://attack.mitre.org/matrices/enterprise/containers/ . Acesso em: 13 abr. 2026.

NIST. Application Container Security Guide (SP 800‑190). Gaithersburg: NIST, 2017. Disponível em: https://doi.org/10.6028/NIST.SP.800-190 . Acesso em: 13 abr. 2026.

NIST. Zero Trust Architecture (SP 800‑207). Gaithersburg: NIST, 2020. Disponível em: https://doi.org/10.6028/NIST.SP.800-207 . Acesso em: 13 abr. 2026.

OPEN CONTAINERS INITIATIVE. runc CVE‑2019‑5736 Advisory. 2019. Disponível em: https://github.com/opencontainers/runc/issues/2128 . Acesso em: 13 abr. 2026.

OPEN POLICY AGENT. Gatekeeper Documentation. 2020. Disponível em: https://open-policy-agent.github.io/gatekeeper/ . Acesso em: 13 abr. 2026.

OPEN INFORMATION SECURITY FOUNDATION. Suricata User Guide. 2021. Disponível em: https://suricata.io/documentation/ . Acesso em: 13 abr. 2026.

PAHL, Claus. Containerization and the PaaS Cloud. IEEE Cloud Computing, 2015. Disponível em: https://doi.org/10.1109/MCC.2015.51 . Acesso em: 13 abr. 2026.

SHU, Ren; GU, Xiaohui; ENCK, William. A Study of Security Vulnerabilities on Docker Hub. In: ACM CODASPY, 2017. Disponível em: https://doi.org/10.1145/3029806.3029832 . Acesso em: 13 abr. 2026.

WAGNER, David; DEAN, Drew. Intrusion Detection via Static Analysis. IEEE Symposium on Security and Privacy, 2001. Disponível em: https://doi.org/10.1109/SECPRI.2001.924286 . Acesso em: 13 abr. 2026.

CENTER FOR INTERNET SECURITY. CIS Kubernetes Benchmark v1.5.0. 2021. Disponível em: https://www.cisecurity.org/benchmark/kubernetes . Acesso em: 13 abr. 2026.

ANCHORE. Clair Container Vulnerability Scanner. 2019. Disponível em: https://github.com/quay/clair . Acesso em: 13 abr. 2026.

AQUA SECURITY. Trivy Vulnerability Scanner Documentation. 2020. Disponível em: https://aquasecurity.github.io/trivy/ . Acesso em: 13 abr. 2026.

CILIUM PROJECT. Cilium Networking and Security for Containers. 2020. Disponível em: https://cilium.io/ . Acesso em: 13 abr. 2026.

KUBERNETES. Kubernetes Documentation. 2021. Disponível em: https://kubernetes.io/docs/ . Acesso em: 13 abr. 2026.