Analisador de Dockerfile, GitHub Actions e Kubernetes

Selecione Dockerfile, GitHub Actions ou Kubernetes e cole a configuração. Revise as linhas ou campos indicados sobre versões de imagens, permissões e ajustes de execução no seu ambiente.

Funciona localmente no seu navegador
Os arquivos de configuração são analisados localmente no navegador. Não cole segredos de produção; revise-os separadamente com o Validador ENV.
Configuração de entrada

As regras são intencionalmente conservadoras. Compare cada achado com a imagem, a política do cluster, as permissões do workflow e o ambiente realmente usado.

Revisão da configuração
  • Escolha um tipo de configuração e execute o linter local.

Como revisar uma configuração de implantação antes de publicá-la

Escolha Dockerfile, GitHub Actions ou Kubernetes, cole a configuração ou carregue-a de um arquivo e clique em Analisar configuração. A página aponta as linhas e os campos problemáticos do texto colado: imagens e actions sem fixação, permissões amplas do token, contêineres privilegiados e proteções de execução ausentes.

O conjunto de regras roda na própria página. Nos testes a análise não enviou nenhuma requisição, então a configuração fica no navegador e a revisão continua funcionando sem rede.

  1. Escolha o tipo de entrada: Dockerfile, workflow do GitHub Actions (.yml/.yaml ou JSON) ou manifesto do Kubernetes (.yml/.yaml ou JSON).
  2. Cole o texto na caixa ou preencha-a com Escolher um arquivo de configuração ou Carregar exemplo.
  3. Clique em Analisar configuração. A linha de métricas conta os achados de alto risco, os itens a revisar e as ideias de hardening, e cada item da lista indica a linha ou o campo de origem.
  4. Clique em Copiar relatório para levar os achados como linhas [DANGER] caminho — mensagem, ou em Limpar para esvaziar a área de trabalho.

O que as regras realmente verificam

As regras de Dockerfile leem instruções inteiras

Um comando RUN continuado com barra invertida é avaliado como uma única instrução, então apt-get install … && rm -rf /var/lib/apt/lists/* não é reportado (as listas são removidas na mesma camada), enquanto uma instalação que nunca as remove é. A mesma passagem detecta o envio curl … | sh mesmo quando o pipe está na linha seguinte.

As outras verificações cobrem a imagem base (latest, ou sem tag e sem digest — scratch fica de fora), FROM ausente, USER root ou 0:0, USER ausente, ADD onde COPY bastaria, COPY . . sem .dockerignore e nomes que sugerem segredos em ENV ou ARG.

Regras de workflow e de manifesto

As verificações do workflow olham os gatilhos pull_request_target, as permissões do GITHUB_TOKEN declaradas no workflow ou no job (write-all é sinalizado), actions de terceiros fixadas em um SHA de commit e downloads enviados direto para um shell. Actions locais (./caminho) e referências docker:// não recebem exigência de versão, porque não há commit para fixar.

As verificações do manifesto cobrem apiVersion, kind ou nome ausentes, tipos de Service que expõem a carga fora do cluster, compartilhamento de namespaces do host, imagens sem fixação ou latest, contêineres privilegiados, allowPrivilegeEscalation ativado, readOnlyRootFilesystem não definido, runAsNonRoot não definido em nenhum nível e requests e limits de CPU e memória ausentes. Um envelope kind: List é aberto e seus itens são revisados um a um.

O que um relatório limpo significa

O conjunto de regras é deliberadamente conservador e procura erros práticos comuns, não conformidade total com políticas. Ele não escaneia imagens, não resolve políticas de admissão e não substitui um motor de políticas de CI, então um relatório sem achados significa que estas regras específicas não encontraram nada — não que a configuração esteja segura.

Os achados são heurísticas sobre o texto colado, então confira cada um com a imagem, a política do cluster e as permissões que você realmente usa. YAML com vários documentos é separado por linhas --- na coluna 0, e JSON é aceito onde YAML é aceito.

Ferramentas recentes: