Meine Kubernetes Sicherheitscheckliste

Kubernetes ist nicht unsicher, aber es ist auch nicht standardmäßig sicher. Ein neuer Cluster lässt Pods als Root laufen, mit allen anderen Pods kommunizieren und das Dateisystem des Hosts montieren, wenn Sie fragen. Die meisten Cluster, die ich überprüfe, haben mindestens ein paar dieser Türen offen.

Ich überprüfe die Dinge in jeder Reihe, von wichtigsten bis zu weniger dringend.

1. Die Wer kann was tun (RBAC)

• Keine geteilten Admin-Konfigurationen. Die Leute melden sich mit SSO an und bekommen Rollen basierend auf Gruppen.
• Niemand benutzt cluster-admin Tag für Tag. Bewahren Sie ihn für den Zugang zum Glasbrecher auf, protokolliert und alarmiert.
• Mindestprivilegien für Dienstkonten. Die meisten Anwendungen müssen überhaupt nicht mit der Kubernetes API sprechen. Ausgestattet automountServiceAccountToken: false Für die.
• Achten Sie auf gefährliche Berechtigungen: Zugang zu secrets über Namensräume hinweg, pods/exec, die Schaffung von Kapseln in kube-system, escalate und bind Verben und Wildcards (*).
• Überprüfen Sie es regelmäßig. Werkzeuge wie kubectl auth can-i --list, rbac-tool oder KubiScan helfen, überprivilegierte Konten zu finden.

2. Die Verriegelung der Kapseln

Kubernetes hat dafür einen eingebauten Mechanismus: Sicherheitseinweisung, mit drei Ebenen: privileged, baseline und restricted- Ich weiß . Aktivieren Sie es pro Namespace mit Labels:

apiVersion: v1
kind: Namespace
metadata:
  name: shop
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Die restricted Die Kommission hat die Kommission aufgefordert, die in den letzten Jahren durchgeführten Maßnahmen zu überprüfen. Der Sicherheitskontext einer konformen Kapsel sieht so aus:

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
- name: app
  securityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities:
      drop: ["ALL"]

Ziel restricted auf allen Anwendungsnamenräumen. Bleib dran. privileged nur für Systemkomponenten, die sie wirklich benötigen (CNI, Speichertreiber, Überwachungsagenten), in ihren eigenen Namensräumen.

Ein Container, der als Root läuft, mit allen Fähigkeiten, ist eine Schwachstelle davon entfernt, den Knoten zu besitzen.

3. Die Netzwerkrichtlinien

Standardmäßig kann jede Kapsel mit jeder anderen Kapsel im Cluster sprechen. Wenn ein Angreifer in einen gerät, kann er alles erreichen.

Beginnen Sie mit Standardweise ablehnen in jedem Namespaces, dann erlauben, was benötigt wird:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: shop
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

Dann fügen Sie Richtlinien hinzu, die zum Beispiel das Gateway erlauben, die API zu erreichen, die API, die Datenbank zu erreichen, und alles, was DNS erreicht. Denken Sie daran: Netzwerkrichtlinien funktionieren nur, wenn Ihr CNI sie unterstützt (Cilium, Calico und die meisten modernen CNIs tun dies).

Beschränkung Ausgang (ausgehender Verkehr) ist genauso wertvoll: Eine kompromittierte Kapsel, die nicht ins Internet gelangen kann, kann keine Tools herunterladen oder Daten einfach senden.

4. Die Geheimnisse

• Verschlüsseln Sie Geheimnisse in Ruhe in etcd, mit KMS auf verwalteten Clustern.
• Geheimnisse in Git nicht speichern in einfacher YAML. Verwenden Sie Externe Geheimnisse, Versiegelte Geheimnisse oder SOPS.
• Grenzwerte get und list über Geheimnisse in RBAC. Geheimnisse in einem Namensraum aufzulisten, enthüllt sie alle.
• Ich bevorzuge Arbeitslast-Identität Über statische Cloud-Zugriffsrechte in Geheimnissen.

5. Die Bildpolitik

• Nur Bilder aus vertrauenswürdigen Registern erlaubt.
• Nein, nicht latest - Die Marken. Pin-Versionen, im Idealfall Verdauungen.
• Unterschriftliche Bilder erforderlich (Cosign) für die Produktion.
• Bildscannen in CI und kontinuierlich im Register.

Diese werden mit einer Zulassungspolitik-Engine wie Kürbis oder OPA-Torwächter, oder mit Kubernetes eingebaut Validierung der Zulassungsrichtlinie für einfachere Regeln.

6. Die Beobachtung der Ausführung (Runtime-Sicherheit)

Die Präventionsmaßnahmen können umgangen werden. Die Sicherheitsvorkehrungen im Laufzeitbereich erkennen verdächtige Verhaltensweisen auf:

• Falco (CNCF) beobachtet Systemanrufe und Warnungen über Dinge wie eine in einem Container entstandene Shell, unerwartete ausgehende Verbindungen oder schreibt an sensible Verzeichnisse.
• Schwarz (aus dem Cilium-Projekt) verwendet eBPF für Beobachtbarkeit und kann auch Richtlinien durchsetzen, wie zum Beispiel den Abbau eines Prozesses, der etwas Verbotenes tut.

Schicken Sie ihre Warnungen an den gleichen Ort wie Ihre anderen Warnungen und schalten Sie sie ein, sonst werden sie Lärm.

7. Sieben. Steuerungsebene und Knoten

• API-Server nicht öffentlich ausgesetzt, oder zumindest auf bekannte IP-Bereiche beschränkt.
• Audit-Logging aktiviert, und die Baumstämme irgendwo in der Mitte verschifft.
• Halten Sie Kubernetes auf dem neuesten Stand. Sicherheitsfixes landen nur in unterstützten Versionen.
• Verhärtetes Knotenbild, minimaler Betriebssystem (wie Bottlerocket, Talos oder Container-optimiertes Betriebssystem), regelmäßig ersetzt.
• Blockieren Sie den Zugriff auf Endpunkte mit Cloud-Metadaten von Pods, die es nicht brauchen, oder IMDSv2 auf AWS durchsetzen.

8. Die Zeit ist gekommen. Benchmarks

• CIS Kubernetes Benchmark: eine detaillierte Reihe von Empfehlungen. Kube-Benk Sie überprüft eine Cluster-Analyse.
• Kubescape und Trivy (trivy k8s) Scannen Sie Cluster auf Fehlkonfigurationen und verknüpfen Sie sie mit Rahmenbedingungen wie NSA/CISA-Hardening Guidance.

Überprüfen Sie sie regelmäßig. Ziel nicht auf 100%, sondern auf das Verständnis aller Ergebnisse.

Also, wo fange ich an?

Wenn Sie nur drei Dinge tun können: Menschen mit wenigsten Privilegien RBAC zu SSO wechseln, Pod Security durchzusetzen restricted Sie können die Daten über die Anwendungsnamensräume und die Netzwerkrichtlinien für die Standardverweigerung hinzufügen. Das schließt die größten Sicherheitslücken in den meisten Clustern.

Ich denke, Kubernetes gibt dir alle Schlösser, die du brauchst. Sie kommen einfach nicht verschlossen in der Box.

Desly