K8s Security Scanner
Scan Kubernetes YAML manifests for security vulnerabilities like privileged containers and secrets exposure
Enter your Kubernetes YAML manifest to scan for security vulnerabilities and misconfigurations
What is the K8s Security Scanner?
The K8s Security Scanner is a client-side tool that analyzes your Kubernetes YAML manifests for security vulnerabilities. It detects privileged containers, root execution, hostPath volumes, dangerous Linux capabilities, plaintext secrets, excessive ServiceAccount permissions, missing Ingress TLS, and other security misconfigurations — then calculates a security score with prioritized remediation recommendations.
How to Use
- Paste your Kubernetes YAML manifest into the input field (multi-document YAML supported)
- Click "Scan" or wait for automatic processing
- Review security findings with severity ratings (Critical, High, Medium, Low)
- Follow the recommendations to harden your manifests
- Export a full security report in JSON or Markdown format
Example: Deployment with Security Issues
This Deployment has multiple security vulnerabilities the scanner will detect:
apiVersion: apps/v1
kind: Deployment
metadata:
name: insecure-app
spec:
replicas: 1
selector:
matchLabels:
app: insecure-app
template:
spec:
hostNetwork: true
containers:
- name: app
image: my-app:latest
securityContext:
privileged: true
runAsUser: 0
capabilities:
add:
- SYS_ADMIN
- NET_ADMINWhat Security Issues Are Detected?
- Privileged containers — Full access to host resources, negating container isolation
- Run as root — Compromised container gains root access to the host
- hostPath volumes — Exposes host filesystem, enabling data exfiltration or host escape
- Dangerous capabilities — SYS_ADMIN, NET_ADMIN, ALL grant elevated kernel-level access
- Plaintext secrets — Base64-encoded secrets in manifests are trivially decodable
- Excessive ServiceAccount permissions — Automounted tokens let compromised pods access K8s API
- cluster-admin bindings — Unrestricted cluster access via ClusterRoleBinding
- Missing Ingress TLS — Traffic transmitted unencrypted between clients and the cluster
- Host network/PID namespace — Pod shares network stack or process list with the node
- Writable root filesystem — Attackers can modify the container filesystem
Security Scoring
Each manifest receives a security score from 0 to 100 based on detected findings. Severity weights are: Critical (25 points deducted), High (15 points), Medium (8 points), Low (3 points). The score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
Kubernetes Security Best Practices
- Set
runAsNonRoot: trueand specify a non-zerorunAsUser - Set
readOnlyRootFilesystem: trueand use emptyDir for writable paths - Drop all capabilities with
drop: ["ALL"]and add only required ones - Never use
privileged: true— use specific capabilities instead - Avoid hostPath volumes — use PersistentVolumeClaims or emptyDir
- Set
automountServiceAccountToken: falseon pods that don't need API access - Use external secret managers instead of storing secrets in manifests
- Always configure TLS on Ingress resources
- Avoid hostNetwork and hostPID unless absolutely required
Supported Resource Types
The scanner inspects Deployment, StatefulSet, DaemonSet, Job, CronJob, ReplicaSet, Pod, Secret,
ClusterRoleBinding, Ingress, and ServiceAccount resources. Multi-document YAML files separated by
--- are fully supported.
Privacy and Security
All scanning happens entirely in your browser using JavaScript. Your Kubernetes manifests — which may contain sensitive secrets, internal service names, RBAC configurations, and infrastructure topology — are never transmitted to any server. No data is stored, logged, or shared.
Frequently Asked Questions
What security issues does the K8s Security Scanner detect?
The scanner detects privileged containers, containers running as root (runAsUser: 0), hostPath volume mounts, dangerous Linux capabilities (SYS_ADMIN, NET_ADMIN, ALL), plaintext secrets in manifests, excessive ServiceAccount permissions, missing Ingress TLS configuration, host network/PID namespace usage, and containers without readOnlyRootFilesystem.
How is the security score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues (privileged containers, run-as-root, cluster-admin bindings) deduct 25 points, High issues (hostPath, dangerous capabilities, plaintext secrets) deduct 15, Medium issues (missing TLS, automounted service account tokens) deduct 8, and Low issues (writable root filesystem) deduct 3. The grade maps to: A (90+), B (75+), C (60+), D (40+), F (below 40).
Why are privileged containers dangerous?
Privileged containers run with all Linux capabilities and have direct access to host devices. A compromised privileged container can escape the container boundary, access host filesystems, modify kernel parameters, and potentially take over the entire node. This effectively negates all container isolation benefits.
Why is running as root flagged as critical?
When a container runs as root (UID 0) and a container escape vulnerability is exploited, the attacker gains root access to the host. Setting runAsNonRoot: true and specifying a non-zero runAsUser ensures that even if the container is compromised, the attacker's privileges on the host are limited.
What are dangerous capabilities and why are they risky?
Linux capabilities are fine-grained permissions that break up root's power. Capabilities like SYS_ADMIN (allows mounting filesystems, modifying kernel parameters), NET_ADMIN (modify network configuration), and ALL (grants every capability) can be exploited for container breakout. Best practice is to drop ALL capabilities and add only the specific ones required.
Why are hostPath volumes a security concern?
hostPath volumes mount directories from the host node's filesystem into the pod. A compromised container with hostPath access can read sensitive host files (/etc/shadow, Docker socket, kubelet credentials), modify host binaries, or escape isolation entirely. Use PersistentVolumeClaims or emptyDir instead.
Why does the scanner flag plaintext secrets in manifests?
Kubernetes Secret resources stored in YAML manifests are only base64-encoded, not encrypted. This means secrets are trivially readable by anyone with access to the manifest file or the git repository. Use external secret managers (HashiCorp Vault, AWS Secrets Manager, sealed-secrets) to inject secrets at runtime instead.
Does it support multi-document YAML files?
Yes. The scanner fully supports multi-document YAML separated by --- delimiters. Each document is analyzed independently for security issues. This is the standard format for Kubernetes manifests that bundle multiple resources (Deployments, Services, Secrets, etc.) in a single file.
Is my Kubernetes manifest sent to any server?
No. All scanning happens entirely in your browser using JavaScript. Your Kubernetes manifests — which may contain sensitive information like secret values, internal service names, namespace topology, and infrastructure details — never leave your device. No data is stored, logged, or transmitted.
What is the difference between K8s Manifest Inspector and K8s Security Scanner?
The K8s Manifest Inspector focuses on operational best practices: resource limits, probes, image tags, and imagePullPolicy. The K8s Security Scanner focuses on security vulnerabilities: privilege escalation, container breakout risks, secrets exposure, RBAC misconfigurations, and network security. Together they provide comprehensive manifest analysis.