DevOps

Runtime- und Cluster-Sicherheit

Pod Security Standards, Falco, eBPF-Runtime-Security, Admission Controller (OPA, Kyverno), Policy Enforcement

24 Interview-Fragen·
Senior
1

Welche drei Pod Security Standards-Level definiert Kubernetes?

Antwort

Kubernetes definiert drei Pod Security Standards-Level: Privileged (keine Einschränkungen), Baseline (minimal restriktiv, blockiert bekannte Privilegieneskalationen wie hostNetwork oder privilegierte Container) und Restricted (stark restriktiv, folgt Hardening Best Practices mit runAsNonRoot, seccomp usw.). Diese Level ermöglichen eine schrittweise Sicherheitsadoption je nach Anwendungsanforderungen.

2

Wie wendet man den Baseline-Level der Pod Security Standards mit kubectl auf einen Namespace an?

Antwort

Die Verwendung von pod-security.kubernetes.io-Labels auf dem Namespace aktiviert die Pod Security Standards. Es gibt drei Modi: enforce (blockiert), warn (warnt) und audit (protokolliert). Der kubectl label-Befehl wendet diese Labels mit dem gewünschten Level und der Version an.

3

Was ist der Hauptunterschied zwischen den Pod Security Standards-Leveln Baseline und Restricted?

Antwort

Der Restricted-Level erzwingt runAsNonRoot und verbietet die Ausführung als root, während Baseline root erlaubt, aber Privilegieneskalationen blockiert. Restricted fügt auch Einschränkungen für Capabilities (drop ALL), seccomp (RuntimeDefault) und erlaubte Volumes hinzu. Es ist der empfohlene Level für kritische Workloads.

4

Was ist die Hauptrolle von Falco in der Kubernetes-Runtime-Security?

5

Welche Technologie ermöglicht es Falco, Systemereignisse zu überwachen, ohne den Linux-Kernel zu modifizieren?

+21 Interview-Fragen

Meistere DevOps für dein nächstes Interview

Zugang zu allen Fragen, Flashcards, technischen Tests, Code-Review-Übungen und Interview-Simulatoren.

Kostenlos starten