Kubernetes YAML validator and visualizer

What the validator does

Paste any number of manifests separated by ---, including kind: List exports from kubectl get -o yaml. The tool does two things.

1. Draws the relationships. It works out how your objects connect the same way the cluster does:

   • an Ingress routes to Services;
   • a Service selects the pods whose labels match its selector;
   • HPAs, PDBs and NetworkPolicies target workloads;
   • pod specs use ConfigMaps, Secrets, PersistentVolumeClaims and ServiceAccounts.

   Anything referenced but missing from the input appears as a dashed box, which is often the first clue to a 503 or a pod stuck in CreateContainerConfigError.

2. Reviews every workload. Deployments, StatefulSets, DaemonSets, Jobs, CronJobs and bare Pods are checked against security and reliability rules. Each finding has a severity, the line where the object starts, and a snippet to fix it. When the fix needs no decision from you (such as privileged: false or dropping all capabilities), Apply fix edits the YAML for you, keeping your comments and the other documents unchanged. Every line changed by the fixes you apply stays highlighted until you edit by hand, and Undo reverts the last fix (or all of them). Fixes that need a real value, like an image version or a health check path, stay manual.

What it checks

The security checks follow the Kubernetes Pod Security Standards and cover the main controls of the restricted profile. For a full guarantee, let Pod Security Admission enforce it in the cluster (see below).

Example: what the sample finds

The sample has two Deployments behind one Ingress. web is in good shape: non-root, read-only filesystem, all capabilities dropped, requests and limits set. It only gets reminders to add a liveness probe, to drop replicas now that an HPA manages it, and to add a PodDisruptionBudget.

worker shows the classic mistakes in one place:

image: acme/worker:latest          # unpinned image
env:
  - name: DB_PASSWORD
    value: hunter2                 # secret in plain text
securityContext:
  privileged: true                 # full access to the node
volumes:
  - hostPath:
      path: /var/run/docker.sock   # controls every container on the node

The Ingress also routes /api to a Service named api that doesn’t exist, so that path would return 503. The diagram shows it as a dashed box.

Fixing the most common findings

A pod-level and container-level securityContext that satisfies the restricted profile:

spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

If the app writes temporary files, mount an emptyDir at /tmp instead of making the root filesystem writable. If the image’s default user is root, set runAsUser: 10001 or rebuild the image with a non-root USER.

Going further

A quick review catches most problems before they reach a cluster. To enforce the rules:

• In the cluster: label namespaces with pod-security.kubernetes.io/enforce: restricted, or use a policy engine such as Kyverno or Gatekeeper.
• Before applying: run kubectl apply --dry-run=server -f manifests/ to validate against the cluster’s real API versions and admission policies.