O teu cluster Kubernetes está em produção, as cargas de trabalho estão a correr e os programadores entregam funcionalidades todas as semanas. De repente, surge um CVE numa das tuas imagens base. Uma política RBAC mal configurada expõe um namespace. Um Helm chart de terceiros que ninguém analisou implementa um contentor a correr como root. Soa-te familiar?
É isto que acontece quando a segurança fica para segundo plano nos ambientes Kubernetes. O DevSecOps muda a equação ao integrar a segurança em todas as fases do ciclo de vida dos contentores — não como uma barreira que atrasa as equipas, mas como salvaguardas automatizadas que fazem do caminho seguro o caminho mais fácil.
O verdadeiro problema: segurança à escala do Kubernetes
Os modelos de segurança tradicionais não funcionam no Kubernetes. Eis porquê:
Os contentores são efémeros. Um contentor pode viver 30 segundos ou 30 dias. Não podes depender de análises de vulnerabilidades periódicas quando a tua superfície de ataque muda sempre que um pod reinicia.
O Kubernetes é declarativo. As más configurações de segurança não são bugs em runtime — ficam registadas no Git como YAML. Um securityContext em falta num manifesto de Deployment é uma vulnerabilidade embutida na tua fonte de verdade.
O raio de impacto é enorme. Um contentor comprometido num cluster Kubernetes não é como uma VM comprometida. Com acesso ao service mesh, segredos partilhados e movimento lateral através da rede do cluster, uma única intrusão pode propagar-se em cascata por toda a tua infraestrutura.
As equipas andam depressa. Equipas de engenharia que fazem deploy 50 vezes por dia não vão tolerar revisões de segurança manuais. Se a segurança as atrasar, vão arranjar forma de a contornar.
O pipeline DevSecOps para Kubernetes
Para a parte de CI/CD, vê o nosso guia sobre como construir um pipeline CI/CD seguro com GitOps. Um pipeline DevSecOps de nível de produção para Kubernetes tem cinco camadas. Cada camada apanha classes diferentes de vulnerabilidades e, em conjunto, dão defesa em profundidade.
Camada 1: análise de código e dependências
Antes de construíres um único contentor, analisa o código-fonte e as suas dependências.
Os testes estáticos de segurança de aplicações (SAST) analisam o teu código-fonte em busca de vulnerabilidades sem o executar. Ferramentas como Semgrep, SonarQube ou CodeQL apanham injeção de SQL, XSS, segredos hardcoded e padrões criptográficos inseguros.
A análise de composição de software (SCA) compara a tua árvore de dependências com bases de dados de CVE. Isto importa imenso — 80% do código de uma aplicação típica vem de dependências open source, e todos os dias são descobertas novas vulnerabilidades.
A deteção de segredos impede que chaves de API, palavras-passe de bases de dados e certificados cheguem ao Git num commit. Ferramentas como GitLeaks ou TruffleHog analisam cada commit em busca de padrões que correspondam a segredos. Isto deve ser um hook de pre-commit — trava os segredos antes de chegarem ao repositório remoto.
O princípio-chave: analisa cedo, analisa automaticamente e faz falhar o pipeline perante descobertas críticas.
Camada 2: segurança das imagens de contentor
As imagens de contentor são a unidade de implementação do Kubernetes. Cada imagem no teu cluster deve ser de confiança, mínima e livre de vulnerabilidades conhecidas.
A escolha da imagem base é a tua primeira defesa. Imagens distroless (gcr.io/distroless) ou baseadas em Alpine reduzem a superfície de ataque de milhares de pacotes para meia dúzia. Uma imagem típica baseada em Ubuntu tem 100+ pacotes de que não precisas. Cada um é uma vulnerabilidade potencial.
A análise de imagens com ferramentas como Trivy, Grype ou Snyk examina cada camada da tua imagem de contentor em busca de CVE conhecidos. Isto deve acontecer em dois sítios: durante o CI/CD (antes de a imagem chegar ao registo) e de forma contínua (analisando as imagens que já estão no registo à medida que são publicados novos CVE).
A assinatura e verificação de imagens garante que só correm imagens de confiança no teu cluster. O Cosign (do projeto Sigstore) assina as imagens durante o CI/CD, e os admission controllers verificam as assinaturas antes de permitirem a implementação. Isto evita ataques à cadeia de fornecimento em que um registo comprometido serve imagens maliciosas.
Um passo prático do pipeline tem este aspeto:
# GitLab CI example
scan-image:
stage: security
script:
- trivy image --severity HIGH,CRITICAL --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- cosign sign --key cosign.key $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
rules:
- if: $CI_COMMIT_BRANCH == "main"Camada 3: segurança dos manifestos Kubernetes
Os teus manifestos Kubernetes definem a postura de segurança de cada carga de trabalho. As más configurações aqui são, isoladamente, a maior fonte de incidentes de segurança em Kubernetes.
Os Pod Security Standards (os substitutos das PodSecurityPolicies, entretanto descontinuadas) definem três níveis: Privileged, Baseline e Restricted. No mínimo, aplica Baseline em todos os namespaces e Restricted nas cargas de trabalho de produção.
O que aplicar:
- Os contentores não podem correr como root (runAsNonRoot: true)
- A escalada de privilégios está desativada (allowPrivilegeEscalation: false)
- Sistema de ficheiros raiz só de leitura (readOnlyRootFilesystem: true)
- Nenhum contentor privilegiado (privileged: false)
- Limites de recursos definidos (evita ataques de esgotamento de recursos)
- Nenhum mount hostPath (evita a fuga do contentor)
- Nem hostNetwork nem hostPID (evita contornar o isolamento de namespaces)
Os motores de políticas como OPA Gatekeeper, Kyverno ou Kubewarden aplicam estas regras no momento da admissão. Quando um programador submete um Deployment que viola a política, o admission controller rejeita-o com uma mensagem de erro clara que explica o que corrigir.
A análise de manifestos em CI/CD apanha más configurações antes de chegarem ao cluster. Ferramentas como Checkov, Kubesec ou Datree analisam ficheiros YAML e Helm charts em busca de problemas de segurança durante a revisão do pull request.
# Kyverno policy example: require non-root containers
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-run-as-non-root
spec:
validationFailureAction: Enforce
rules:
- name: run-as-non-root
match:
any:
- resources:
kinds: ["Pod"]
validate:
message: "Containers must not run as root"
pattern:
spec:
containers:
- securityContext:
runAsNonRoot: trueCamada 4: segurança de rede
As network policies do Kubernetes são o equivalente a firewalls para o teu cluster. Por omissão, qualquer pod pode comunicar com qualquer outro pod — o oposto de zero trust.
As Network Policies devem seguir o princípio do menor privilégio. Começa por negar todo o tráfego de entrada e de saída e, depois, permite explicitamente apenas os caminhos de comunicação de que a tua aplicação precisa.
Um service mesh (Istio, Linkerd ou Cilium) acrescenta TLS mútuo (mTLS) entre todos os serviços de forma automática. Isto cifra todo o tráfego dentro do cluster e fornece verificação criptográfica de identidade — mesmo que um atacante comprometa a rede, não consegue escutar a comunicação entre serviços.
O controlo de egress é muitas vezes esquecido. Se um contentor for comprometido, a primeira coisa que um atacante faz é estabelecer uma reverse shell para um servidor externo de command-and-control. Network policies de egress que restringem o tráfego de saída a endpoints conhecidos impedem este movimento lateral.
Camada 5: segurança em runtime e monitorização
Tudo o que está acima é preventivo. A segurança em runtime é detetiva — apanha as ameaças que passaram por todas as outras camadas.
A deteção de ameaças em runtime com o Falco monitoriza em tempo real as chamadas ao sistema de cada contentor. As regras do Falco detetam comportamentos suspeitos: uma shell aberta num contentor, uma ligação de rede inesperada, um binário executado que não fazia parte da imagem original, a leitura de um ficheiro sensível.
O audit logging ao nível da API do Kubernetes regista cada ação feita sobre o cluster. Quem criou aquele pod privilegiado? Quando foi alterado aquele binding RBAC? Os logs de auditoria respondem a estas perguntas e alimentam o teu SIEM para correlação com outros eventos de segurança.
Os scanners de conformidade contínua como Polaris, kube-bench (CIS benchmarks — tratamos a fundo a automação da conformidade para SOC2, ISO 27001 e CIS) ou Falco Talon verificam continuamente se a configuração do cluster cumpre os teus padrões de segurança e aplicam ações de remediação automáticas quando detetam drift.
Medir a maturidade DevSecOps
Não consegues melhorar o que não medes. Acompanha estas métricas:
Tempo médio de remediação (MTTR) — Quanto tempo passa desde a publicação de um CVE até à implementação da correção? As equipas de elite conseguem-no em menos de 24 horas para CVE críticos.
Taxa de conformidade com as políticas — Que percentagem das cargas de trabalho passa todas as políticas de admissão sem exceções? Aponta para 95%+ e acompanha quais as equipas que precisam de apoio.
Densidade de vulnerabilidades por imagem — Número médio de CVE HIGH/CRITICAL por imagem em produção. Deve ter tendência descendente ao longo do tempo, à medida que as equipas adotam imagens distroless e patching automatizado.
Taxa de aprovação nos security gates — Que percentagem dos pipelines CI/CD passa nos controlos de segurança à primeira? Uma taxa baixa significa que os programadores precisam de melhores ferramentas ou de formação. Uma taxa alta significa que os teus controlos podem não ser suficientemente rigorosos.
Frequência de implementação — O DevSecOps não deve atrasar as equipas. Se a frequência de implementação cair depois de introduzires controlos de segurança, a tua automação precisa de trabalho.
Erros comuns a evitar
Não trates a análise de segurança como uma formalidade. Correr o Trivy uma vez e ignorar os resultados é pior do que não analisar de todo — cria uma falsa sensação de segurança.
Não uses exceções generalizadas. Quando uma política bloqueia uma implementação, a resposta não é uma exceção para o namespace inteiro. Corrige o manifesto.
Não te esqueças do runtime. O melhor pipeline pré-implementação não consegue apanhar vulnerabilidades zero-day nem cadeias de fornecimento comprometidas. A deteção em runtime é a tua última linha de defesa.
Não ignores a experiência do programador. Se as ferramentas de segurança produzem 500 descobertas por análise sem qualquer priorização, os programadores vão ignorá-las. Afina as ferramentas para mostrarem primeiro as descobertas acionáveis de severidade alta.
As ferramentas que funcionam de facto
Depois de implementarmos DevSecOps em dezenas de ambientes Kubernetes, isto é o que vemos a funcionar em produção:
| Categoria | Ferramenta | Porquê | |----------|------|-----| | Análise de imagens | Trivy | Rápido, preciso, suporta vários alvos, gratuito | | Aplicação de políticas | Kyverno | Nativo de Kubernetes, políticas legíveis, sem a curva de aprendizagem do Rego | | Deteção em runtime | Falco | Padrão da indústria, biblioteca de regras rica, baixo overhead | | Análise de segredos | GitLeaks | Integração pre-commit, rápido, poucos falsos positivos | | SAST | Semgrep | Rápido, regras extensíveis, suporta 30+ linguagens | | Network policy | Cilium | Baseado em eBPF, alto desempenho, substitui o kube-proxy | | mTLS / Service mesh | Linkerd | Leve, configuração mínima, simplesmente funciona | | Conformidade | kube-bench | Automação dos CIS benchmarks, simples de correr | | Assinatura de imagens | Cosign | Assinatura keyless com OIDC, ecossistema Sigstore |
Por onde começar
Se os teus clusters Kubernetes não têm hoje qualquer automação de segurança, não tentes implementar as cinco camadas de uma vez. Começa pelas vitórias de maior impacto e menor esforço:
Semana 1-2: Acrescenta a análise de imagens com Trivy ao teu pipeline CI/CD. Faz falhar os builds apenas em vulnerabilidades CRITICAL — podes apertar mais tarde.
Semana 3-4: Implementa o Kyverno com os Pod Security Standards em modo Audit. Vê o que falharia sem partir nada.
Mês 2: Muda o Kyverno para modo Enforce nas políticas Baseline. Acrescenta o GitLeaks como hook de pre-commit.
Mês 3: Implementa o Falco para deteção em runtime. Começa com o conjunto de regras predefinido e afina a partir daí.
Mês 4+: Acrescenta network policies, implementa a assinatura de imagens e alarga a cobertura de SAST.
O objetivo é a melhoria contínua, não a perfeição no primeiro dia. Cada camada que acrescentas reduz a tua superfície de ataque e torna a camada seguinte mais fácil de implementar.
Conclusão
DevSecOps para Kubernetes não é um produto que se compra — é uma prática que se constrói. As equipas que o fazem bem partilham três características: automatizam tudo, medem tudo e tratam a segurança como uma funcionalidade, não como uma restrição.
O investimento paga-se a si próprio. Apanhar um CVE crítico em CI/CD custa à tua equipa 15 minutos. Apanhá-lo em produção, depois de uma intrusão, custa semanas de resposta a incidentes, notificações a clientes e danos reputacionais.
Começa por uma camada. Automatiza-a. Mede-a. Depois acrescenta a seguinte.