Kubernetes YAML-Validator + DSGVO-Linter

Paste dein Manifest, bekomm sofort einen Compliance-Score. Prüft Security (Pod-Security-Standards), DSGVO Art. 32, BSI IT-Grundschutz APP.4.4, fehlende Resource-Limits und deprecated APIs.

Kubernetes YAML-Validator + DSGVO/BSI-Linter

Paste deine Kubernetes-Manifests rein — der Validator parst, prüft Security-Defaults (Pod-Security-Standards), Resource-Hygiene und DACH-spezifische Compliance-Aspekte (DSGVO, BSI IT-Grundschutz APP.4.4). Läuft 100 % im Browser, keine Daten verlassen deinen Rechner.

Ergebnis3 Dokumente, 11 Issues
Compliance-Score57/100
0
Critical
2
High
5
Medium
3
Low
1
Info
|
runAsNonRoot-not-set
Security · Medium

runAsNonRoot ist nicht explizit auf true gesetzt — Kubernetes erlaubt dann root.

Deployment/webapp (ns=default) → container/app

Fix-Vorschlag
securityContext:
  runAsNonRoot: true
allow-privilege-escalation
Security · Medium

allowPrivilegeEscalation ist nicht auf false gesetzt — Container kann root werden.

Deployment/webapp (ns=default) → container/app

Fix-Vorschlag
securityContext:
  allowPrivilegeEscalation: false
readonly-root-fs
Security · Low

readOnlyRootFilesystem ist nicht aktiviert — Runtime-Manipulationen möglich.

Deployment/webapp (ns=default) → container/app

Fix-Vorschlag
securityContext:
  readOnlyRootFilesystem: true
image-no-fixed-tag
Best-Practice · Medium

Image "nginx:latest" verwendet :latest oder kein Tag — kein deterministisches Deployment.

Deployment/webapp (ns=default) → container/app

Fix-Vorschlag
image: nginx:1.2.3  # oder SHA-Digest
imagePullPolicy-not-always
BSI · Low

imagePullPolicy ist nicht Always — Image-Updates werden u. U. nicht gezogen. BSI APP.4.4 (Schwachstellenmanagement).

Deployment/webapp (ns=default) → container/app

no-resource-requests
Resources · Medium

Keine resources.requests definiert — Scheduler kann nicht planen, Bin-Packing leidet.

Deployment/webapp (ns=default) → container/app

Fix-Vorschlag
resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
no-memory-limit
Resources · High

Kein resources.limits.memory — bei Memory-Leak kann der Pod den Node OOM-killen und alle anderen Pods mit reißen.

Deployment/webapp (ns=default) → container/app

Fix-Vorschlag
resources:
  limits:
    memory: "512Mi"
no-probes
BSI · Low

Keine livenessProbe oder readinessProbe — kein Selbst-Heilen, BSI Verfügbarkeits-Anforderung verletzt.

Deployment/webapp (ns=default) → container/app

secret-encryption-reminder
DSGVO · Info

Secret im Manifest. DSGVO Art. 32 verlangt Encryption at Rest — sicher dass etcd encryption-providers konfiguriert sind?

Secret/db-credentials

Referenz →
ingress-no-tls
DSGVO · High

Ingress ohne TLS-Config — Daten werden im Klartext übertragen. DSGVO Art. 32 verletzt.

Ingress/webapp-ingress

Fix-Vorschlag
spec:
  tls:
  - hosts:
    - app.example.de
    secretName: app-tls
no-network-policy
BSI · Medium

Pod-Workloads ohne NetworkPolicy — kein Netzwerk-Segmentierungs-Default. BSI APP.4.4 / Zero-Trust.

Manifest-Gesamtansicht

Fix-Vorschlag
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-default
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
Welche Regeln prüft der Linter
  • Security: privileged-Container, runAsRoot, hostNetwork/PID, gefährliche Capabilities (ALL, SYS_ADMIN, NET_ADMIN), readOnlyRootFilesystem, allowPrivilegeEscalation
  • DSGVO (Art. 32): Ingress ohne TLS, Secrets ohne Encryption-Hinweis
  • BSI APP.4.4 / IT-Grundschutz: imagePullPolicy, fehlende NetworkPolicies, fehlende Liveness/Readiness-Probes
  • Resources: fehlende requests, kritisch: fehlende memory.limits (OOM-Risiko)
  • Deprecated: alte apiVersions (extensions/v1beta1, PodSecurityPolicy, autoscaling/v2beta1, ...)
  • Best-Practice: Image-Tags (:latest, kein Tag, kein SHA-Digest)

Linter im CI: Dieser Validator deckt ≈ 30 wichtige Regeln ab, aber kein Tool ersetzt einen echten Cluster-Audit. Pexon Consulting macht Security-Audits mit kubesec, Polaris, Trivy und Kyverno-Policies — passend zu deiner DSGVO-/BSI-Schutzbedarfsanalyse. Security-Audit anfragen →

Warum ein Linter mit DACH-Compliance-Regeln

Englische Linter wie kubeval, kubeconform, kubesec oder Polaris validieren gegen das K8s-OpenAPI-Schema und allgemeine Best-Practices. Sie wissen nichts über DSGVO Art. 32 (Verschlüsselung), BSI IT-Grundschutz APP.4.4 (Container) oder branchenspezifische DACH-Anforderungen.

Dieser Validator bringt die typischen DACH-Compliance-Stolperer als eigene Regeln dazu:

  • DSGVO Art. 32: Ingress ohne TLS-Block, Secrets ohne Encryption-at-Rest-Hinweis.
  • BSI APP.4.4.A8 (Nutzung von Containerregistries): imagePullPolicy, Image-Tag-Hygiene.
  • BSI APP.4.4.A6 (Netzsegmentierung): fehlende NetworkPolicies bei Pod-Workloads.
  • Verfügbarkeits-Anforderungen: fehlende Liveness/Readiness-Probes.

Was dieser Linter NICHT ersetzt

  • Vollständige Schema-Validation: Für strikte CRD-Validation brauchst du kubeconform mit dem Schema deiner Cluster-Version.
  • Runtime-Security: Falco oder Sysdig erkennen Anomalien zur Laufzeit, ein YAML-Linter kann das nicht.
  • Cluster-Audit: kube-bench (CIS-Benchmarks), Trivy (Vulnerability-Scanning), Polaris-Cluster-Reports sehen das laufende System.
  • Policy-as-Code: Kyverno oder OPA-Gatekeeper enforcen Regeln im Admission-Controller — der Linter hier ist nur ein Pre-Commit-Helfer.