---
title: "Segurança de containers e Kubernetes: checklist com 25 itens"
description: "Checklist prático de segurança para Docker e Kubernetes: imagens, build, registry, configuração de pods, RBAC, rede, segredos e monitoramento em produção."
url: "https://security.transitax.com/blog/seguranca-containers-kubernetes-checklist"
---

Nuvem

# Segurança de containers e Kubernetes: checklist com 25 itens

Checklist prático de segurança para Docker e Kubernetes: imagens, build, registry, configuração de pods, RBAC, rede, segredos e monitoramento em produção.

[Equipe de Pesquisa TransiTax Security](https://security.transitax.com/sobre#pesquisa)Publicado em 20 de maio de 2026Atualizado em 10 de junho de 20263 min de leitura

Resumo

-   Trocar a imagem base por uma mínima e atualizada elimina a maior parte das CVEs de uma imagem de uma vez.
-   Pods nunca devem rodar como root, privilegiados ou com acesso ao host sem justificativa documentada.
-   RBAC amplo e ausência de network policy transformam o comprometimento de um pod no comprometimento do cluster.
-   Admission controllers aplicam as regras antes do deploy; varredura contínua encontra o que escapou.

Neste artigo

1.  [Imagem](#imagem)
2.  [Build e registry](#build-e-registry)
3.  [Configuração do pod](#configuracao-do-pod)
4.  [Identidade e RBAC](#identidade-e-rbac)
5.  [Rede](#rede)
6.  [Segredos](#segredos)
7.  [Operação](#operacao)
8.  [Priorize pelo que está exposto](#priorize-pelo-que-esta-exposto)

Containers e Kubernetes mudaram a forma como aplicações são empacotadas e operadas, e trouxeram uma superfície de ataque própria: imagens com centenas de pacotes que ninguém escolheu, manifestos YAML com permissões generosas e um plano de controle que, se comprometido, entrega tudo.

Este checklist está organizado na ordem em que o container vive: construção da imagem, armazenamento, configuração no cluster e operação.

## [Imagem](#imagem)

1.  **Use uma imagem base mínima.** Distroless, Alpine, Wolfi ou variantes slim reduzem drasticamente o número de pacotes e de CVEs. Trocar a imagem base costuma eliminar mais de 90% das vulnerabilidades de uma vez. [Imagens endurecidas](https://security.transitax.com/funcionalidades/imagens-endurecidas) levam isso ao limite.
2.  **Fixe a imagem base por digest**, não por tag. Tags podem ser movidas.
3.  **Use build em múltiplos estágios.** Compiladores, gerenciadores de pacotes e ferramentas de build ficam no estágio de build, fora da imagem final.
4.  **Rode como usuário sem privilégios.** Declare `USER` com um UID diferente de zero no Dockerfile.
5.  **Nunca copie secrets para a imagem.** Nem `.env`, nem chaves, nem tokens de registry privado. Use secrets de build, que não ficam nas camadas.
6.  **Mantenha um `.dockerignore`** para não levar `.git`, arquivos locais e credenciais para o contexto de build.

```dockerfile
FROM node:22-slim@sha256:<digest> AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian12@sha256:<digest>
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER 10001
CMD ["dist/server.js"]
```

## [Build e registry](#build-e-registry)

7.  **Analise a imagem no CI**, antes do push, com política que falha o build em vulnerabilidades críticas com correção disponível. Veja [varredura de imagens de container](https://security.transitax.com/funcionalidades/imagens-de-container).
8.  **Continue analisando depois do push.** CVEs novas aparecem para imagens antigas. O registry precisa de varredura contínua.
9.  **Assine as imagens** e verifique a assinatura no deploy.
10.  **Gere SBOM de cada imagem** e anexe como atestado. Veja o [guia de SBOM](https://security.transitax.com/blog/sbom-guia-pratico).
11.  **Restrinja quem pode fazer push** no registry. Pipelines, não pessoas.

## [Configuração do pod](#configuracao-do-pod)

12.  **`runAsNonRoot: true`** e um `runAsUser` explícito.
13.  **`allowPrivilegeEscalation: false`**.
14.  **Remova todas as capabilities** e adicione só as necessárias.
15.  **`readOnlyRootFilesystem: true`**, com volumes temporários onde a aplicação precisa escrever.
16.  **Sem `privileged`, `hostNetwork`, `hostPID` ou `hostPath`** sem justificativa documentada.
17.  **Defina requests e limits** de CPU e memória, para que um pod comprometido não derrube o nó.

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

18.  **Aplique os Pod Security Standards** no nível `restricted` por namespace, com o admission controller nativo.

## [Identidade e RBAC](#identidade-e-rbac)

19.  **Desative o automount do token da service account** nos pods que não falam com a API do Kubernetes.
20.  **Nada de `cluster-admin` para aplicações.** Roles com verbos e recursos específicos, por namespace.
21.  **Use identidade de workload** (IRSA na AWS, Workload Identity no GKE e no AKS) em vez de chaves de nuvem montadas como secret.

## [Rede](#rede)

22.  **Network policy padrão de negação** em cada namespace, liberando só o tráfego necessário.
23.  **Plano de controle privado** ou restrito por IP, com autenticação integrada ao provedor de identidade.

## [Segredos](#segredos)

24.  **Secrets do Kubernetes não são criptografados por padrão**, apenas codificados em base64. Ative a criptografia em repouso no etcd ou use um gerenciador externo com sincronização, e nunca coloque secrets em ConfigMaps.

## [Operação](#operacao)

25.  **Monitore em runtime.** Varredura estática não vê um processo inesperado rodando dentro do container. A [proteção em runtime](https://security.transitax.com/funcionalidades/protecao-em-runtime) bloqueia injeção e SSRF na aplicação, e a avaliação contínua do cluster detecta mudanças fora do pipeline.

## [Priorize pelo que está exposto](#priorize-pelo-que-esta-exposto)

Um cluster médio tem dezenas de imagens com centenas de CVEs. Comece pelas imagens que:

1.  **Estão rodando** (imagens no registry que não rodam em lugar nenhum descem na fila)
2.  **Estão expostas** por Ingress ou LoadBalancer
3.  **Têm permissões na nuvem** que alcançam dados sensíveis

Essa combinação forma um [caminho de ataque](https://security.transitax.com/funcionalidades/caminhos-de-ataque-na-nuvem), e cortar o caminho no ponto certo vale mais que corrigir cem CVEs isoladas. A [avaliação de clusters Kubernetes](https://security.transitax.com/funcionalidades/seguranca-kubernetes) da TransiTax Security cruza exatamente esses sinais.

Quer ver isso rodando no seu código?

Em 30 minutos mostramos a TransiTax Security num repositório seu, separando o que é explorável do que é ruído.

[Falar com um especialista](https://security.transitax.com/contato)

Escrito por

Equipe de Pesquisa TransiTax Security

Engenheiros de segurança de aplicações e de nuvem que acompanham registros de pacotes, bases de vulnerabilidades e técnicas de ataque. [Conheça a equipe](https://security.transitax.com/sobre#pesquisa).

Neste artigo

1.  [Imagem](#imagem)
2.  [Build e registry](#build-e-registry)
3.  [Configuração do pod](#configuracao-do-pod)
4.  [Identidade e RBAC](#identidade-e-rbac)
5.  [Rede](#rede)
6.  [Segredos](#segredos)
7.  [Operação](#operacao)
8.  [Priorize pelo que está exposto](#priorize-pelo-que-esta-exposto)
9.  [Perguntas frequentes](#perguntas-frequentes)

## Perguntas frequentes

Respostas diretas às dúvidas mais comuns sobre o tema.

### Como reduzir vulnerabilidades em imagens Docker?

Troque a imagem base por uma versão mínima e atualizada, use build em múltiplos estágios, remova ferramentas desnecessárias da imagem final e reconstrua as imagens com frequência.

### Container rodando como root é realmente um problema?

Sim. Se a aplicação for comprometida, o atacante tem privilégios máximos dentro do container e mais chances de escapar para o nó, especialmente combinado com capabilities e montagens do host.

### Secrets do Kubernetes são seguros?

Por padrão, eles são apenas codificados em base64 e ficam legíveis para quem tem acesso ao etcd ou permissão de leitura de secrets. Ative criptografia em repouso e restrinja o acesso por RBAC.

### O que é Pod Security Standards?

É o conjunto de políticas nativas do Kubernetes (privileged, baseline e restricted) que definem o que um pod pode ou não fazer, aplicadas por namespace pelo admission controller integrado.

### Preciso de admission controller?

É altamente recomendado. Ele impede que pods fora da política sejam criados, em vez de apenas detectar depois do deploy.

## Continue lendo

-   [CSPM: as 12 configurações erradas mais comuns na AWS, Azure e Google Cloud17 de junho de 2026Nuvem](https://security.transitax.com/blog/cspm-aws-azure-gcp)
-   [O que é SAST: guia completo de análise estática de código16 de setembro de 2026Fundamentos](https://security.transitax.com/blog/o-que-e-sast)
-   [Pentest com IA: como funciona e quando substituir o pentest manual10 de setembro de 2026Pentest](https://security.transitax.com/blog/pentest-com-ia)

## Veja o que é explorável no seu código

Em 30 minutos mostramos a plataforma num repositório seu, separamos o risco real do ruído e montamos uma proposta em reais.

[Falar com um especialista](https://security.transitax.com/contato)

Resposta em até 1 dia útil.