Scanner de Seguridad K8s

Scanning Kubernetes Manifests for Security Vulnerabilities

Kubernetes provides powerful abstractions for deploying containerized workloads, but its default configurations are often insecure by design — favoring operational flexibility over security hardening. Containers run as root by default, host namespaces are accessible without restriction, and sensitive data can be stored in plaintext ConfigMaps. The Security Scanner analyzes your YAML manifests to detect security misconfigurations that could allow container escapes, privilege escalation, sensitive data exposure, or lateral movement within your cluster.

Each finding is classified by severity and mapped to relevant security benchmarks (CIS Kubernetes Benchmark, Pod Security Standards). The scanner provides specific remediation guidance showing exactly which fields to add or modify in your manifests to harden security posture. All analysis happens locally in your browser — your sensitive infrastructure definitions never leave your device.

Privileged Containers and Capability Misuse

The most critical Kubernetes security misconfigurations involve excessive container privileges:

• Privileged mode: securityContext.privileged: true gives the container full access to host devices and kernel capabilities — equivalent to running as root on the host machine. A container escape in privileged mode compromises the entire node.
• Dangerous capabilities: Linux capabilities like SYS_ADMIN, NET_ADMIN, and SYS_PTRACE grant specific kernel-level powers. Many are unnecessary for application workloads and should be dropped explicitly.
• Running as root: Containers without runAsNonRoot: true or runAsUser run their processes as UID 0. If an attacker gains code execution, they have root privileges within the container and can attempt privilege escalation.
• Writable root filesystem: Without readOnlyRootFilesystem: true, attackers can write malicious scripts, modify binaries, or install toolkits within the container.

The scanner detects all privilege-related misconfigurations and recommends the minimal security context needed for each container type.

Host Namespace Sharing and Volume Risks

Kubernetes allows pods to share host namespaces and mount host directories, creating attack paths that bypass container isolation:

• hostPID/hostIPC: Sharing the host's process or IPC namespace lets containers see and signal all processes on the node, enabling process injection attacks.
• hostNetwork: Sharing the host network namespace bypasses network policies and exposes all host ports to the container, including kubelet and API server ports.
• hostPath volumes: Mounting host directories like /, /etc, or /var/run/docker.sock gives containers direct access to node filesystems and container runtimes.
• Docker socket mount: Mounting /var/run/docker.sock allows containers to create sibling containers on the host — a common privilege escalation vector.

These configurations are occasionally legitimate (for node monitoring agents or log collectors) but must be explicitly justified and paired with additional security controls.

Secrets Management and Data Exposure

The scanner detects improper handling of sensitive data in Kubernetes manifests:

• Plaintext secrets in ConfigMaps: Storing passwords, API keys, or tokens in ConfigMap data rather than Secret resources — ConfigMaps are not encrypted at rest.
• Hardcoded credentials in environment variables: Embedding secrets directly in pod specs rather than referencing Secret resources, making them visible in kubectl describe output and audit logs.
• Overly broad Secret mounting: Mounting entire Secrets as volumes when only one key is needed, exposing additional sensitive data to the container unnecessarily.
• Missing encryption at rest: While detected at the cluster level, the scanner flags patterns that indicate secrets may not be properly managed.

Code Examples

Insecure Manifest vs Hardened Version

# INSECURE: Multiple security issues
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      hostNetwork: true              # Bypasses network policies
      containers:
        - name: api
          image: myapp:latest
          securityContext:
            privileged: true         # Full host access
          env:
            - name: DB_PASSWORD
              value: "s3cret123"     # Hardcoded secret
          volumeMounts:
            - name: docker-sock
              mountPath: /var/run/docker.sock
      volumes:
        - name: docker-sock
          hostPath:
            path: /var/run/docker.sock  # Container escape risk
---
# HARDENED: Security best practices applied
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
        - name: api
          image: myapp:2.1.0@sha256:abc123...
          securityContext:
            runAsNonRoot: true
            runAsUser: 1000
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: api-secrets
                  key: db-password