Kubernetes Security by Design

Arquitetura de referência, modelo de ameaças e guia de implementação para plataformas empresariais

Pedro Miguel Estoura · Arquitetura de Segurança · 27 de outubro de 2026
Versão: 1.0 · Natureza: artigo técnico e arquitetura de referência · Estado: proposta técnica, não certificação de conformidade

Ideia central: um cluster Kubernetes não se torna seguro pela soma de ferramentas instaladas. A segurança depende de decisões coerentes sobre identidades, privilégios, fronteiras de confiança, integridade de software, caminhos de rede, dados e operação — acompanhadas de evidência de que os controlos são aplicados.

1. O problema arquitetural

Kubernetes organiza e executa aplicações distribuídas. A mesma API que permite automatizar deployments, escalar serviços e recuperar workloads também oferece uma superfície de controlo particularmente sensível: quem consegue criar Pods, alterar roles, montar credenciais ou operar componentes privilegiados pode, em certas condições, aumentar substancialmente o alcance de um compromisso.

Por isso, o desenho de segurança tem de responder a cinco perguntas:

1. Quem pode alterar o estado do cluster, por qual identidade e mediante que autorização?
2. Que software pode ser executado, quem o produziu e como se prova a sua integridade?
3. Que comunicações são necessárias e onde termina cada fronteira de confiança?
4. Que dados e segredos são acessíveis a cada workload e durante quanto tempo?
5. Que evidências permitem detetar abuso, recuperar o serviço e validar continuamente os controlos?

O objetivo não é impedir toda a falha — algo impossível de garantir — mas reduzir a probabilidade de compromisso, conter o raio de impacto e acelerar a deteção e recuperação.

1.1 Âmbito e pressupostos

Esta arquitetura representa um ambiente empresarial com vários namespaces, aplicações web e APIs, pipeline CI/CD, registry privado, gestão de identidade corporativa, armazenamento persistente e observabilidade centralizada. É aplicável, com adaptações, a Kubernetes autogerido e a serviços geridos. Não pressupõe que o fornecedor dê controlo direto sobre etcd ou sobre todos os parâmetros do control plane. Os controlos variam segundo a distribuição, versão, infraestrutura, CNI e modelo de responsabilidade partilhada.

Não inclui uma escolha comercial de ferramenta, um desenho de alta disponibilidade específico, nem a certificação de um ambiente em produção.

2. Princípios que orientam o desenho

3. Arquitetura lógica de referência

O diagrama separa tráfego de utilizador, acesso administrativo, cadeia de entrega e telemetria. As setas são fluxos lógicos: não representam necessariamente ligações diretas ou protocolos idênticos em todos os deployments.

3.1 Fronteiras e planos

TB-01 — Internet para borda. Só serviços intencionalmente publicados entram pela camada de edge. TLS, controlo de exposição, limitação de pedidos e proteção de aplicações operam aqui. Um WAF não substitui autenticação, autorização por objeto ou validação no serviço.

TB-02 — Borda para workloads. O Gateway/Ingress encaminha para aplicações autorizadas. NetworkPolicies devem restringir quais os Pods que aceitam tráfego do controlador e quais os destinos que os serviços podem alcançar.

TB-03 — Workload para workload e dados. Namespaces ajudam a organizar e limitar âmbito administrativo, mas não constituem, isoladamente, uma barreira de rede nem isolamento forte de tenants. Exigem políticas de rede, identidade, autorização na aplicação e, quando necessário, isolamento por clusters ou nós distintos.

TB-04 — Pessoas e automações para Kubernetes API. Todo o acesso de gestão passa por identidades verificáveis, autenticação forte e autorização estrita. O endpoint administrativo deve ter exposição mínima, preferencialmente privada, e um caminho de acesso controlado.

TB-05 — Código para produção. O controlo começa no repositório e prossegue até ao admission do cluster. A assinatura de uma imagem só é útil quando a cadeia de confiança e a política de verificação são efetivamente aplicadas.

TB-06 — Cluster para plataformas externas. Segredos, bases de dados, KMS, telemetria e endpoints de terceiros são dependências explícitas, com políticas de egress e credenciais próprias.

4. Plano de controlo: a API é um ativo crítico

O kube-apiserver é o ponto central de controlo declarativo. O desenho tem de combinar autenticação, autorização e admissão. Uma autenticação bem-sucedida não equivale a autorização segura; uma autorização RBAC demasiado ampla permite alterar recursos que podem originar escalada indireta.

Decisões recomendadas

• Integrar pessoas com um Identity Provider (IdP) corporativo, autenticação multifator (MFA) e grupos governados; evitar credenciais administrativas partilhadas.
• Reservar cluster-admin para funções estritamente justificadas e acesso de emergência monitorizado.
• Não conceder * em recursos e verbos como solução de conveniência; restringir criação de Roles/RoleBindings, Secrets, Pods e recursos de admission.
• Usar identidades próprias, de curta duração quando suportado, para automações; evitar reutilizar credenciais humanas no CI/CD.
• Segregar a identidade que constrói e publica imagens da identidade que as promove para produção.
• Configurar audit logs de API, com cuidado para não registar corpos que revelem credenciais, e monitorizar cobertura, erros de envio e retenção.

Risco subtil: um utilizador sem permissão direta para ler Secrets pode conseguir obter informação sensível se tiver autorização para criar um Pod que monte um Secret acessível no namespace. O desenho de permissões deve, portanto, avaliar capacidades efetivas e vias indiretas de privilégio, não apenas listas de verbs. Fonte: Kubernetes Secrets Good Practices.

5. Plano de dados: segmentação e caminhos permitidos

As NetworkPolicies padrão operam predominantemente à camada 3/4 e dependem de um plugin de rede com suporte de enforcement. Não implementam, por si, mTLS, autorização de chamadas HTTP, filtragem por identidade de utilizador, controlo por FQDN ou inspeção de conteúdos. Algumas capacidades adicionais podem ser oferecidas por implementações específicas; devem ser explicitamente classificadas como dependências, não características universais do Kubernetes.

Setas contínuas representam fluxos propostos; as ligações pontilhadas ilustram comunicações a negar. É fundamental testar ambos os sentidos: ingress no destino e egress na origem. Uma política default-deny sem exceções apropriadas pode bloquear DNS, telemetria e dependências essenciais.

Exemplo 1 — Política base de isolamento

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

Esta política não é suficiente para operar uma aplicação; só estabelece a postura inicial de isolamento de Pods selecionados, desde que o CNI imponha NetworkPolicies. Complementar com regras restritas para DNS, Ingress, serviços internos, bases de dados e telemetria. Evitar aplicá-la diretamente em produção sem inventário de fluxos e testes prévios.

Exemplo 2 — Aceitar tráfego do frontend para a API

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-from-frontend
  namespace: app-prod
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Atenção: esta regra autoriza ingress na API a partir dos Pods com app: frontend no mesmo namespace. Para a ligação funcionar, o egress do frontend também tem de a permitir. Labels não são identidades criptográficas; controlar quem pode criar ou alterar Pods/labels é parte do modelo de segurança.

6. Segurança de Pods, nós e runtime

O nível restricted dos Pod Security Standards (PSS) constitui uma baseline exigente para workloads compatíveis. O Pod Security Admission (PSA) pode impor (enforce), advertir (warn) ou auditar (audit) os níveis privileged, baseline e restricted. Para workloads de infraestrutura que exigem privilégios, as exceções devem ser estreitas, com ownership, justificação, revisão e monitorização.

Exemplo 3 — Namespace com enforcement restricted

apiVersion: v1
kind: Namespace
metadata:
  name: app-prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Não aplicar indiscriminadamente restricted aos namespaces de infraestrutura antes de conhecer os requisitos dos operadores e agentes. A política de admission também não substitui os requisitos específicos de cada workload: imagens mínimas, utilizador não-root, capabilities limitadas, filesystem read-only quando possível, allowPrivilegeEscalation: false, seccomp, limites de recursos, configuração segura do host, patches e isolamento reforçado quando a sensibilidade o justifica.

Exemplo 4 — Security Context de um container compatível

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Este excerto é ilustrativo e deve ser colocado no local correto do manifesto do container; o suporte depende da imagem, do runtime e de possíveis necessidades de volumes graváveis. Exigir segurança funcional verificada, não apenas a presença de campos YAML.

7. Identidade de workloads e gestão de segredos

As contas de serviço (ServiceAccounts) oferecem identidade Kubernetes aos workloads, mas não significam automaticamente uma identidade federada reconhecida por sistemas externos. Para acesso a serviços cloud e cofres de segredos, preferir mecanismos de Workload Identity ou federação suportados pela plataforma; quando necessário, considerar identidades de workload baseadas em SPIFFE/SPIRE, com custo operacional e adequação avaliados caso a caso.

Decisões concretas:

1. Uma conta de serviço dedicada por aplicação ou função, com permissões apenas quando necessárias.
2. automountServiceAccountToken: false quando o Pod não necessita da API Kubernetes.
3. Tokens projetados e de curta duração quando aplicáveis; sem tokens estáticos em repositórios.
4. Segredos obtidos de cofre ou mecanismo aprovado; rotação e revogação com procedimentos operacionais explícitos.
5. Cifra em repouso para dados sensíveis na API/etcd e para volumes, com gestão separada de chaves e backups; em clusters geridos, verificar garantias do fornecedor.
6. Não tratar Base64 como cifragem. Evitar colocar segredos em logs, variáveis de ambiente quando os riscos específicos aconselhem montagens protegidas, ou em manifests versionados.

8. Supply chain: da alteração de código ao deployment

Um scanner de vulnerabilidades não prova que um artefacto é íntegro; uma assinatura não prova que o código está isento de vulnerabilidades. Por isso, são controlos complementares:

• Antes do merge: branch protection, revisão, secret scanning, análise estática (SAST), testes de segurança e revisão de Infrastructure as Code (IaC).
• No build: dependências controladas, isolamento de runners, privilégios mínimos, produção de Software Bill of Materials (SBOM) e proveniência.
• No registry: retenção, controlo de acessos, tags governadas e uso preferencial de digests imutáveis.
• No deploy: validação de políticas, imagens de origem aprovada, assinaturas e regras de exceção com prazo, responsável e rastreabilidade.
• Em runtime: inventário da imagem efetivamente executada, drift, deteção de comportamento e plano de revogação ou rollback.

9. Modelo de ameaças: cenários que o desenho deve conter

Nota metodológica: esta tabela identifica cenários e controlos recomendados, não riscos quantitativos de uma instalação observada. Probabilidade, impacto e risco residual exigem ativos, exposição, criticidade e evidência do ambiente real.

10. Controlos por fase — uma implementação pragmática

10.1 Matriz de evidência mínima

• IAM/RBAC: export controlado de Roles, ClusterRoles, Bindings, ServiceAccounts e revisão de permissões efetivas.
• Admission: política documentada, versão dos PSS e registo de rejeição de um deployment deliberadamente não conforme.
• Rede: CNI identificado, prova de enforcement, matriz dos fluxos aprovados e testes positivos/negativos.
• Supply chain: digest executado, assinatura validada, SBOM associado e evidência do pipeline.
• Secrets: caminho de entrega, política de acesso, rotação e verificação da cifragem em repouso segundo o modelo de serviço.
• Observabilidade: audit events no destino, deteções acionadas e monitorização de perda de eventos.
• Resiliência: backup recuperável, exercício de restauro e cumprimento de RTO/RPO acordados.

11. Critérios de avaliação de uma arquitetura real

Uma proposta não deve ser aprovada apenas por enumerar tecnologias. Eu usaria perguntas de decisão:

1. O API Server está exposto? Quem acede, a partir de onde, com que autenticação e logging?
2. Quem pode criar Pods, montar volumes privilegiados ou alterar RBAC e admission?
3. As políticas de rede são efetivamente impostas pelo CNI, incluindo egress e DNS?
4. As identidades e segredos dos workloads são separados e revogáveis?
5. Um artefacto não assinado ou proveniente de registry indevido é impedido de executar?
6. Como são geridas exceções e como se evita que se tornem permanentes?
7. Que eventos permitem reconstruir uma alteração maliciosa ou um incidente?
8. Que nível de isolamento é necessário entre ambientes, equipas ou tenants?
9. A recuperação foi demonstrada, e não apenas descrita num procedimento?
10. Quem é o owner de cada controlo — plataforma, segurança, desenvolvimento ou fornecedor?

Qualquer resposta desconhecido deve originar recolha de evidência proporcional à criticidade, não ser automaticamente classificada como falha crítica.

12. Padrões, orientações e fontes primárias

Este guia segue uma abordagem baseada em documentação oficial e boas práticas. As fontes abaixo sustentam os mecanismos descritos; a sua simples referência não demonstra conformidade da implementação.

1. Kubernetes — Security Overview: mecanismos nativos, API, políticas, Secrets e workloads.
2. Kubernetes — Security Checklist: verificações e controlos de segurança recomendados.
3. Kubernetes — Pod Security Standards e Pod Security Admission: níveis e modos de aplicação.
4. Kubernetes — Network Policies: dependências do CNI, semântica, isolamento e limitações.
5. Kubernetes — Secrets Good Practices: acesso, cifra, riscos e integração com cofres externos.
6. Kubernetes — Auditing: políticas e destinos de logs de auditoria.
7. Kubernetes — RBAC Good Practices: desenho de autorizações.
8. NIST — SP 800-190, Application Container Security Guide: visão de riscos de containers e recomendações.
9. CIS — Kubernetes Benchmark: baseline de hardening a selecionar por distribuição e versão.
10. OWASP — Kubernetes Security Cheat Sheet: práticas complementares de segurança.

13. Conclusão — arquitetura segura é capacidade demonstrada

O elemento central de Kubernetes Security by Design não é uma ferramenta, um manifesto ou um produto de mercado. É a coerência entre o que pode ser executado, por quem, com que privilégios, em que ligações, com que dados e sob que capacidade de observação e recuperação.

Um desenho de referência é útil quando se transforma em critérios de implementação: uma identidade privilegiada deve ser negada fora do contexto autorizado; uma imagem adulterada deve falhar a admissão; uma comunicação não prevista deve ser bloqueada; um incidente deve produzir evidência suficiente; e uma recuperação deve ser ensaiada com resultados medidos.

É esse o ponto em que passamos de uma arquitetura documentada para uma arquitetura de segurança verificável.

Nota editorial: diagramas originais, esquemáticos e intencionalmente agnósticos de fornecedor. Para uma implementação concreta, o artigo deve ser complementado com topologia de nós e zonas, versões, componentes escolhidos, matriz de fluxos, responsabilidades e resultados de testes. Nenhum comando ou manifesto desta publicação foi aplicado a um cluster real.