VoriTools

Dockerfile, GitHub Actions & Kubernetes Linter

Select Dockerfile, GitHub Actions or Kubernetes and paste the configuration. Review the reported lines or fields for image pinning, permissions and runtime settings in your environment.

Runs locally in your browser
View category: DevOps & Diagnostics (18)
Configuration files are parsed locally in your browser. Do not paste production secrets; use the existing ENV Validator to review those separately.
Configuration input

The rules are intentionally conservative. Review every finding against the image, cluster policy, workflow permissions, and environment you actually use.

Configuration review
  • Choose a configuration type and run the local linter.

How to review a deployment configuration before it ships

Choose Dockerfile, GitHub Actions or Kubernetes, paste the configuration or load it from a file, then press Analyze configuration. The page reports the lines and fields your pasted text gets wrong: unpinned images and actions, broad token permissions, privileged containers and missing runtime hardening.

The ruleset runs in the page. In testing the analysis sent no request, so the configuration stays in the browser and the check keeps working with the network dropped.

  1. Pick the input type: Dockerfile, GitHub Actions workflow (.yml/.yaml or JSON) or Kubernetes manifest (.yml/.yaml or JSON).
  2. Paste the text into the box, or fill it with Choose a configuration file or Load example.
  3. Press Analyze configuration. The metric row counts high-risk findings, review items and hardening ideas, and each list entry names the line or field it came from.
  4. Press Copy report to take the findings as plain [DANGER] path — message lines, or Clear to empty the workbench.

What the rules actually check

Dockerfile rules read whole instructions

A RUN command continued with a backslash is judged as one instruction, so apt-get install … && rm -rf /var/lib/apt/lists/* is not reported (the lists are removed in the same layer), while an install that never removes them is. The same pass catches curl … | sh piping even when the pipe sits on the following line.

The other checks cover the base image (latest, or no tag and no digest — scratch exempt), a missing FROM, USER root or 0:0, a missing USER, ADD where COPY would do, COPY . . without a .dockerignore, and secret-like names in ENV or ARG.

Workflow and manifest rules

Workflow checks look at pull_request_target triggers, GITHUB_TOKEN permissions declared at workflow or job level (write-all is flagged), third-party actions pinned to a commit SHA, and downloads piped straight into a shell. Local actions (./path) and docker:// references are not asked for a version, because there is no commit reference to pin.

Manifest checks cover missing apiVersion, kind or name, Service types that expose the workload beyond the cluster, host namespace sharing, unpinned or latest images, privileged containers, allowPrivilegeEscalation left enabled, readOnlyRootFilesystem not set, runAsNonRoot unset at both levels, and missing CPU and memory requests and limits. A kind: List wrapper is opened and its items are reviewed individually.

What a clean report does and does not mean

The ruleset is intentionally conservative and looks for common practical mistakes, not full policy compliance. It does not scan images, resolve admission policies or replace a CI policy engine, so a report without findings means these specific rules found nothing — not that the configuration is safe to deploy.

Findings are heuristics on pasted text, so check each one against the image, cluster policy and permissions you actually use. Multi-document YAML is split on --- lines at column 0, and JSON is accepted wherever YAML is.

Recent tools: