Container- und Kubernetes-Sicherheit

Container verwenden gemeinsam den Kernel des Hosts und sind dadurch weniger isoliert als VMs. Containersicherheit umfasst die Sicherheit der Images (keine verwundbaren Pakete), den Laufzeitschutz (Erkennung abnormalen Verhaltens), Netzwerkrichtlinien (Beschränkung der Pod-Kommunikation) und die RBAC-Konfiguration.

Trivy scannt Container-Images auf CVEs in Betriebssystempaketen, Schwachstellen in Anwendungsabhängigkeiten, Fehlkonfigurationen und Secrets. Integrieren Sie Trivy in CI/CD, um Images mit kritischen Schwachstellen zu blockieren, bevor sie die Produktion erreichen.

Verwenden Sie minimale Basis-Images (alpine, distroless). Führen Sie den Container als Benutzer ohne Root-Rechte aus (USER 1000). Vermeiden Sie COPY . . – geben Sie Dateien konkret an. Multi-Stage-Builds verringern die Größe des finalen Images. Scannen Sie vor dem Push. Schreiben Sie niemals Secrets oder Anmeldedaten in Layer fest.

Kubernetes-RBAC steuert den Zugriff auf den API-Server. ClusterRoles und Roles definieren Berechtigungen für Ressourcen (Pods, Secrets, Deployments). ClusterRoleBindings und RoleBindings weisen sie Benutzern, Gruppen oder ServiceAccounts zu. Vermeiden Sie cluster-admin, außer für Automatisierung.

PSS definiert drei Profile: Privileged (uneingeschränkt), Baseline (minimale Einschränkungen) und Restricted (gehärtet). Wenden Sie sie über Namespace-Labels des PodSecurity Admission Controllers an. Das Restricted-Profil verhindert die Ausführung als Root, untersagt die Rechteausweitung und erfordert schreibgeschützte Dateisysteme.

Standardmäßig können alle Pods mit allen anderen Pods kommunizieren. Kubernetes NetworkPolicies definieren anhand eines Pod-Selectors Regeln für eingehenden und ausgehenden Datenverkehr. Implementieren Sie standardmäßige Deny-Regeln und erlauben Sie ausdrücklich nur erforderliche Kommunikationspfade, um den möglichen Schadensumfang zu begrenzen.

Kubernetes Secrets sind standardmäßig Base64-codiert, nicht verschlüsselt. Aktivieren Sie die Verschlüsselung ruhender Daten für etcd. Verwenden Sie den External Secrets Operator oder den Vault Agent Injector, um Secrets aus HashiCorp Vault oder Cloud-Secret-Managern zu beziehen, statt Kubernetes Secrets zu verwenden.

Admission Controller fangen API-Anfragen ab, bevor Objekte erstellt werden. OPA/Gatekeeper erzwingt benutzerdefinierte Richtlinien, beispielsweise erforderliche Labels oder das Blockieren privilegierter Container. Kyverno bietet Policy-as-Code mit einer einfacheren YAML-Syntax für gängige K8s-Sicherheitsanforderungen.

Falco erkennt mithilfe von eBPF anomales Verhalten zur Laufzeit: in Containern gestartete Shells, unerwartete ausgehende Verbindungen, unter /etc geschriebene Dateien, Versuche zur Rechteausweitung und die Ausführung bekannter Angriffstools. Die Alarmregeln sind anpassbare YAML-Dateien.

Aktivieren Sie die Audit-Protokollierung des API-Servers, um jede Anfrage mit Benutzer, Aktion, Ressource und Zeitstempel zu erfassen. Leiten Sie die Protokolle an ein SIEM weiter, um ungewöhnliche API-Aktivitäten zu erkennen: das Auflisten von ServiceAccount-Tokens, die Aufzählung von Secrets, die Ausweitung von Rollen und kubectl exec in Produktions-Pods.

Signieren Sie Container-Images mit Cosign (Sigstore), um die Integrität der Lieferkette sicherzustellen. Policy Controller (Connaisseur, Kyverno) können erzwingen, dass nur signierte Images aus vertrauenswürdigen Registrys in den Cluster aufgenommen werden, und dadurch das Abrufen nicht vertrauenswürdiger Images blockieren.

Was bewirkt eine Kubernetes NetworkPolicy mit einem leeren podSelector und den policyTypes Ingress/Egress?

Container- und Kubernetes-Sicherheit erfordern die Absicherung der Image-Lieferkette, die Durchsetzung von RBAC und Pod-Sicherheitsstandards, die Implementierung von Netzwerkrichtlinien, einen angemessenen Umgang mit Secrets und Laufzeiterkennung, um Angriffe zu erkennen, die präventive Kontrollen umgehen.