Segurança de imagens no Kubernetes: protegendo a cadeia de suprimentos de containers

Toda carga de trabalho em um cluster Kubernetes começa a vida como uma imagem de container. Esse único fato faz da segurança de imagens no Kubernetes a base da segurança da cadeia de suprimentos de containers: se uma imagem comprometida ou vulnerável chega ao scheduler, o Kubernetes vai fielmente baixá-la, executá-la e entregar a ela o acesso à rede, os secrets e os privilégios que você concedeu à carga de trabalho. O orquestrador não julga o que há dentro da imagem; ele confia nela. Proteger essa imagem, e comprovar de onde ela veio, é uma das ações de maior impacto que uma equipe de plataforma ou de segurança pode tomar.

Este artigo é um mergulho profundo na segurança de imagens dentro do panorama mais amplo da segurança do Kubernetes. Se você é responsável pelo pipeline que constrói e implanta containers, esta é a camada em que o escaneamento de imagens de container, o image signing e a política de admission se unem para proteger sua cadeia de suprimentos de containers.

Por que a imagem é uma superfície de ataque privilegiada no Kubernetes

Uma imagem de container é um instantâneo congelado de um sistema de arquivos: uma camada de sistema operacional, runtimes de linguagem, dependências da aplicação, seu código e qualquer configuração que tenha sido embutida pelo caminho. Ela é montada a partir de muitas fontes — imagens base públicas, registries de pacotes, bibliotecas de terceiros, artefatos de build internos — e cada uma delas é um lugar onde um atacante pode tentar injetar ou explorar algo.

O Kubernetes amplifica as consequências. Uma imagem vulnerável não é implantada uma única vez; ela é baixada em cada node que agenda a carga de trabalho e pode ser replicada em dezenas ou centenas de pods em segundos. As falhas na cadeia de suprimentos de software são proeminentes o suficiente para que o OWASP Top 10 (2025) as monitore como a categoria A03, refletindo com que frequência os atacantes têm como alvo dependências e sistemas de build em vez da aplicação em execução diretamente. Em um cluster, a imagem é a forma concentrada desse risco.

Anatomia do risco de imagem

Para proteger imagens de forma deliberada, ajuda dar nome aos distintos tipos de risco que elas carregam.

Pacotes do sistema operacional

A imagem base traz o equivalente a uma distribuição Linux inteira de bibliotecas e utilitários de sistema. Estes acumulam CVEs ao longo do tempo, e uma imagem base que estava limpa seis meses atrás quase certamente não está hoje. Pacotes de sistema operacional antigos e sem patch são a fonte mais comum de vulnerabilidades de imagem.

Dependências da aplicação

Sua aplicação incorpora bibliotecas open-source — npm, PyPI, Maven, módulos Go — e suas dependências transitivas. Uma versão sabidamente vulnerável de uma biblioteca no fundo da árvore é tão explorável dentro de um container quanto em qualquer outro lugar, e muitas vezes mais difícil de notar.

Configuração incorreta

A forma como a imagem é construída importa. Rodar como root, expor portas desnecessárias, deixar gerenciadores de pacotes e shells na imagem final ou definir permissões de arquivo excessivamente permissivas — tudo isso amplia a superfície de ataque mesmo quando nenhuma CVE isolada está presente.

Secrets embutidos

Secrets são embutidos em imagens com mais frequência do que qualquer um gostaria: uma chave de API em uma linha ENV, um token de .npmrc, uma chave privada copiada durante uma etapa de build e nunca removida. Como as camadas de imagem são imutáveis e mantidas em cache, um secret comitado uma vez pode persistir no histórico de camadas mesmo depois que uma camada posterior o "apaga".

Provenance

Por fim, há a pergunta que poucas imagens conseguem responder por conta própria: de onde isso realmente veio? Sem provenance, você não consegue distinguir uma imagem que seu sistema de CI construiu e aprovou de uma que um atacante enviou ao seu registry com o mesmo nome.

Comece pela base: imagens mínimas e non-root

As vitórias de segurança mais baratas acontecem antes de qualquer scanner rodar, ao escolher o que entra na imagem.

Prefira imagens base mínimas ou distroless. Uma imagem distroless contém sua aplicação e suas dependências de runtime e pouco mais — sem shell, sem gerenciador de pacotes, sem utilitários de uso geral. Isso reduz drasticamente a superfície de ataque (menos pacotes significa menos CVEs) e complica a vida de um atacante que de fato consiga execução de código, porque não há shell com o qual pivotar.

Rode como um usuário non-root. Se o processo dentro do container não precisa de root, não dê root a ele.

# Multi-stage build: compile in a full image, ship a minimal one

FROM golang:1.23 AS build

WORKDIR /src

COPY . .

RUN CGO_ENABLED=0 go build -o /app ./cmd/server

FROM gcr.io/distroless/static:nonroot

COPY --from=build /app /app

USER nonroot:nonroot

ENTRYPOINT ["/app"]

Um multi-stage build como esse mantém compiladores e ferramentas de build totalmente fora do artefato final, de modo que eles nunca possam se tornar parte da sua superfície de ataque em runtime. Combine imagens non-root com controles restritivos no nível do pod — veja segurança de pods no Kubernetes para saber como security contexts e admission standards impõem non-root e removem capabilities no momento do deploy.

Escaneamento de vulnerabilidades: SCA em toda a imagem

Você não pode corrigir o que não consegue ver, e o escaneamento de imagens de container é como você enxerga isso. Um escaneamento eficaz usa software composition analysis (SCA) para inventariar tudo na imagem — tanto pacotes do sistema operacional quanto dependências da aplicação — e cruzar esse inventário com dados de vulnerabilidades.

Dois princípios tornam o escaneamento de fato útil em vez de ruído:

Escaneie em mais de um lugar. Escaneie na CI para que os desenvolvedores recebam feedback no pull request que introduziu uma dependência ruim, e escaneie no registry para que as imagens sejam reavaliadas conforme novas CVEs são divulgadas contra artefatos que você já entregou. Uma imagem que passou na semana passada pode falhar nesta semana quando uma nova vulnerabilidade crítica é publicada; apenas o reescaneamento contínuo detecta isso.

Faça builds falharem diante de achados críticos. Um escaneamento que só produz um relatório é ignorado. Conecte o scanner ao pipeline de modo que novos achados de severidade crítica (e, quando apropriado, alta) quebrem o build.

# CI step: scan and fail on new critical/high findings

- name: Scan image

  run: |

    rainforest image scan registry.example.com/app:${GIT_SHA} \

      --severity CRITICAL,HIGH \

      --fail-on CRITICAL,HIGH \

      --ignore-unfixed

Restringir a problemas de alta severidade que tenham correção mantém o portão significativo em vez de afogar as equipes em achados sobre os quais elas não podem agir.

Provenance e assinatura de imagens

O escaneamento diz o que há dentro de uma imagem. O image signing e a provenance dizem de onde ela veio e se você deve confiar nela.

A ideia é simples. Quando seu pipeline constrói uma imagem, ele assina criptograficamente o digest resultante e registra attestations — declarações legíveis por máquina sobre como a imagem foi produzida: qual commit de origem, qual sistema de build, quais etapas rodaram. Esse é o cerne do framework SLSA (Supply-chain Levels for Software Artifacts), que descreve níveis crescentes de integridade de provenance para um build.

Depois, antes que qualquer coisa rode, você verifica a assinatura. Se uma imagem não estiver assinada por uma chave que sua organização controla, ou se sua provenance não corresponder às suas expectativas, ela é rejeitada. Isso fecha a brecha que um registry sozinho não consegue: mesmo que um atacante envie uma imagem maliciosa sob um nome legítimo, ela não carregará uma assinatura válida, e a verificação vai detectá-la.

A assinatura e a verificação pertencem ao pipeline (assinar no build, verificar no deploy) em vez de serem um ritual manual, para que a provenance seja aplicada automaticamente a cada carga de trabalho.

Segurança do registry

O registry é onde as imagens ficam entre o build e o deploy, então merece o mesmo cuidado que qualquer outro sistema de produção.

• Use registries privados para imagens internas, e seja deliberado sobre de quais registries externos você permite que imagens sejam baixadas.
• Imponha controle de acesso. O acesso de push deve ser limitado a sistemas de CI e a um pequeno conjunto de identidades confiáveis; direitos amplos de push transformam o registry em um ponto de injeção fácil.
• Use tags imutáveis. Uma vez que uma tag aponta para um digest, ela não deve ser reapontada. Tags mutáveis permitem que uma imagem mude por baixo dos panos depois de ter sido escaneada e aprovada.
• Proíba `:latest` em deployments. Fazer deploy de :latest significa que você não consegue dizer com certeza o que está rodando, não consegue reproduzir um deploy e não consegue ligar uma carga de trabalho em execução a um escaneamento específico. Fixe em uma tag imutável ou, melhor ainda, em um digest (app@sha256:...).

Fixar por digest é a opção mais forte: o digest é a identidade endereçada por conteúdo da imagem, então ele não pode mudar silenciosamente.

Admission control: aplique a política no portão

Tudo o que foi dito acima é apenas consultivo até que algo se recuse a rodar imagens que o violem. Esse algo é o admission control. Um admission controller do Kubernetes (tipicamente um motor de políticas rodando como um validating admission webhook) inspeciona toda especificação de pod antes de ela ser agendada e pode rejeitá-la.

Uma postura madura de segurança de imagens usa o admission control para bloquear:

• Imagens não assinadas — sem assinatura válida de uma chave confiável, sem admissão.
• Imagens não escaneadas — sem um resultado de escaneamento recente e aprovado, sem admissão.
• Imagens de alta severidade — imagens que carregam vulnerabilidades acima do seu limiar.
• Fontes não permitidas — imagens de registries que não estão na sua allowlist, ou referenciadas por tags mutáveis como :latest.

# Illustrative admission policy: require a valid signature and a passing scan

apiVersion: policy.example.com/v1

kind: ImagePolicy

metadata:

  name: require-signed-and-scanned

spec:

  match:

    registries: ["registry.example.com/*"]

  rules:

    - requireSignature: true # provenance must verify

    - requireScanPassed: true # no unresolved CRITICAL/HIGH

    - disallowTags: ["latest"] # digest or immutable tag only

  onViolation: deny

Este é o ponto em que a política se torna uma garantia: uma imagem que pulou o escaneamento ou não tem provenance simplesmente não consegue iniciar.

Drift em runtime

Mesmo uma imagem perfeitamente construída, assinada e admitida pode sofrer drift depois de estar rodando. Alguém faz exec em um container e instala um pacote; um processo escreve novos binários em uma camada gravável; uma carga de trabalho começa a se comportar de forma diferente da imagem a partir da qual foi construída. Essa divergência entre a imagem confiável e o container ao vivo é o drift em runtime, e ele mina toda garantia que você estabeleceu no momento do build e da admissão.

As defesas são majoritariamente preventivas e reforçam escolhas anteriores: rode containers com sistemas de arquivos raiz somente leitura sempre que possível, remova capabilities desnecessárias, proíba escalonamento de privilégios e mantenha imagens distroless que não oferecem shell para adulterar. Quanto menos um container em execução puder ser alterado, mais a imagem que você verificou continua sendo a imagem que está executando.

Shift left em todo o pipeline

Note o padrão em todas as seções: quanto mais cedo um problema é detectado, mais barato é corrigi-lo. Uma dependência vulnerável sinalizada no pull request de um desenvolvedor é uma mudança de cinco minutos; a mesma dependência descoberta em uma imagem de produção é um incidente. É isso que "shift left" significa na prática para imagens — empurrar as escolhas de imagem base, o SCA, a detecção de secrets e a assinatura o mais cedo possível no pipeline, ao mesmo tempo em que ainda se impõe a política nos portões do registry e do admission como uma rede de segurança.

A segurança de imagens não é, portanto, uma única ferramenta, mas uma cadeia de pontos de verificação: imagem base, build, escaneamento, assinatura, armazenamento, admissão e execução. Uma fraqueza em qualquer elo mina os demais, o que é exatamente por que a cadeia de suprimentos de containers precisa ser tratada como um sistema conectado.

Como a Rainforest ajuda

Proteger toda essa cadeia é mais fácil quando os pontos de verificação compartilham uma única visão do seu software. A Rainforest reúne container security e software composition analysis para que você possa escanear imagens em busca de vulnerabilidades em pacotes do sistema operacional e dependências da aplicação, revelar secrets embutidos e configurações incorretas, e acompanhar achados desde o pull request até o registry. Como a Rainforest também cobre sua infraestrutura como código e as dependências que suas aplicações incorporam, os manifests que implantam suas imagens e as bibliotecas dentro delas são avaliados como parte da mesma cadeia de suprimentos, e não isoladamente — que é como os riscos de cadeia de suprimentos monitorados pelo OWASP de fato chegam a um cluster.

Se você está estruturando a segurança de imagens no Kubernetes, agende uma demo e vamos percorrer juntos como proteger sua cadeia de suprimentos de containers de ponta a ponta, da imagem base à admissão.