Kubernetes Workload Hardening
Paste rendered Kubernetes YAML (Helm or kustomize output), kubectl get -o json, or a docker-compose file. The checker tests every workload against the official Pod Security Standards (Baseline and Restricted), reads Roles and RoleBindings against the RBAC good-practice list, and flags the hygiene gaps outside the PSS. Each finding names the resource, the field, why it matters and the fix. The Runtime caps tab decodes a /proc/<pid>/status capability mask into escape techniques.
Your manifest never leaves this tab. There are no network calls; the YAML parser and every check run in the page.
Read the running mask inside a pod with grep Cap /proc/1/status, then paste a value here. Decoding happens in the page.
How the check works
What it reads and what it reports
The page parses multi-document YAML, so helm template or kustomize build output drops straight in. It also reads kubectl get -o json (a single object or a List) and docker-compose. Every Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob and ReplicaSet is checked at its pod template.
- Pod Security Standards, field for field from the Kubernetes docs: host namespaces, HostProcess, privileged, the capability allow-list, hostPath, host ports, AppArmor, SELinux, the
/procmount type, seccomp, the safe sysctl set, restricted volume types, allowPrivilegeEscalation, runAsNonRoot and runAsUser. Each workload gets a verdict: the strictest PSS level it still meets. - RBAC good practices: wildcard verbs and resources, the escalate, bind and impersonate verbs, Secret read, pods/exec and pods/attach, nodes/proxy, creating pods, service account token issuance, CSR approval, webhook config writes, and bindings to anonymous or cluster-admin.
- Hygiene outside the PSS: a writable root filesystem, missing resource limits, a
:latestor untagged image, secrets written as literal env values, the auto-mounted service account token, and the default service account. - Network: namespaces with workloads but no NetworkPolicy in the input (informational, since the input may be partial), and datastore ports exposed by LoadBalancer or NodePort Services.
The Runtime caps tab decodes a capability bitmask to names, flags anything beyond Docker's 14 default capabilities, and maps the dangerous ones to known escape techniques.
Sources
- Pod Security Standards: kubernetes.io/docs/concepts/security/pod-security-standards
- RBAC good practices: kubernetes.io/docs/concepts/security/rbac-good-practices
- Docker default capabilities: moby/moby
daemon/pkg/oci/caps/defaults.go(commit c74ba95, 2025-07-24): the 14 caps a container keeps unless you add more. - Capability numbers: Linux
include/uapi/linux/capability.h(0 to 40, up to CAP_CHECKPOINT_RESTORE).
Hardening FAQ
What do I paste in?
Multi-document YAML works, so rendered Helm or kustomize output is fine. So is kubectl get -o json, as a single object or a List, and a docker-compose file.
Which standard does it check against?
The Kubernetes Pod Security Standards, Baseline and Restricted, field for field, plus RBAC good practices and hygiene checks that sit outside the PSS.
Is my manifest sent anywhere?
No. The YAML parser and every check run in JavaScript on the page. Manifests can hold secrets and internal names, so nothing is uploaded.
What is the capability decoder for?
Paste a CapEff, CapPrm or CapBnd hex mask from /proc/<pid>/status. It lists the capability names, flags the ones beyond Docker's default set, and maps dangerous ones to known escape techniques.
Checks reflect the Pod Security Standards and RBAC good practices as of October 2026. Sample manifests on this page are fictional.