Analizador de Dockerfile, GitHub Actions y Kubernetes

Selecciona Dockerfile, GitHub Actions o Kubernetes y pega la configuración. Revisa las líneas o campos señalados sobre versiones de imágenes, permisos y ajustes de ejecución en tu entorno.

Se ejecuta localmente en tu navegador
Los archivos de configuración se analizan localmente en tu navegador. No pegues secretos de producción; revísalos por separado con el validador ENV.
Configuración de entrada

Las reglas son deliberadamente conservadoras. Contrasta cada hallazgo con la imagen, la política del clúster, los permisos del workflow y el entorno que utilizas realmente.

Revisión de configuración
  • Elige un tipo de configuración y ejecuta el linter local.

Cómo revisar una configuración de despliegue antes de publicarla

Elige Dockerfile, GitHub Actions o Kubernetes, pega la configuración o cárgala desde un archivo y pulsa Analizar configuración. La página señala las líneas y campos problemáticos del texto pegado: imágenes y acciones sin fijar, permisos amplios del token, contenedores privilegiados y controles de ejecución ausentes.

El conjunto de reglas se ejecuta en la página. En las pruebas el análisis no envió ninguna petición, así que la configuración permanece en el navegador y la revisión sigue funcionando sin red.

  1. Elige el tipo de entrada: Dockerfile, workflow de GitHub Actions (.yml/.yaml o JSON) o manifiesto de Kubernetes (.yml/.yaml o JSON).
  2. Pega el texto en el cuadro o rellénalo con Elegir un archivo de configuración o Cargar ejemplo.
  3. Pulsa Analizar configuración. La fila de métricas cuenta los hallazgos de alto riesgo, los puntos a revisar y las ideas de endurecimiento, y cada entrada de la lista indica la línea o el campo del que procede.
  4. Pulsa Copiar informe para llevarte los hallazgos como líneas [DANGER] ruta — mensaje, o Limpiar para vaciar el espacio de trabajo.

Qué comprueban realmente las reglas

Las reglas de Dockerfile leen instrucciones completas

Un comando RUN continuado con barra invertida se juzga como una sola instrucción, así que apt-get install … && rm -rf /var/lib/apt/lists/* no se reporta (las listas se eliminan en la misma capa), mientras que una instalación que nunca las elimina sí. La misma pasada detecta el conducto curl … | sh aunque la barra vertical esté en la línea siguiente.

El resto de comprobaciones cubren la imagen base (latest, o sin etiqueta ni digest — scratch queda exento), un FROM ausente, USER root o 0:0, un USER ausente, ADD donde bastaría COPY, COPY . . sin .dockerignore y nombres que sugieren secretos en ENV o ARG.

Reglas de workflow y de manifiesto

Las comprobaciones del workflow miran los disparadores pull_request_target, los permisos de GITHUB_TOKEN declarados en el workflow o en el job (write-all se marca), las acciones de terceros fijadas a un SHA de commit y las descargas canalizadas directamente a un shell. A las acciones locales (./ruta) y a las referencias docker:// no se les pide versión, porque no hay un commit que fijar.

Las comprobaciones del manifiesto cubren apiVersion, kind o nombre ausentes, tipos de Service que exponen la carga fuera del clúster, uso compartido de namespaces del host, imágenes sin fijar o latest, contenedores privilegiados, allowPrivilegeEscalation activado, readOnlyRootFilesystem sin definir, runAsNonRoot sin definir en ninguno de los dos niveles y requests y limits de CPU y memoria ausentes. Un envoltorio kind: List se abre y sus elementos se revisan uno a uno.

Qué significa un informe limpio

El conjunto de reglas es deliberadamente conservador y busca errores prácticos habituales, no el cumplimiento total de una política. No analiza imágenes, no resuelve políticas de admisión ni sustituye a un motor de políticas de CI, así que un informe sin hallazgos significa que estas reglas concretas no encontraron nada, no que la configuración sea segura.

Los hallazgos son heurísticas sobre el texto pegado, así que contrasta cada uno con la imagen, la política del clúster y los permisos que usas realmente. El YAML con varios documentos se separa por líneas --- en la columna 0, y se acepta JSON allí donde se acepta YAML.

Herramientas recientes: