Zutritt zur Podsicherheit

Die Pod-Sicherheitszulassung implementiert die Kubernetes Pod-Sicherheitsstandards, die das Verhalten von Pods einschränken, und liefert Warnmeldungen und kube-apiserver Audit-Ereignisse für Pods, die gegen die für den jeweiligen Namespace konfigurierte Pod-Sicherheitsprofilrichtlinie verstoßen.

Red Hat OpenShift on IBM Cloud version 4.11 und höher bietet Unterstützung für Kubernetes pod security admission. Weitere Informationen finden Sie unter Pod-Sicherheitszulassung und Pod-Sicherheitsstandards in der Dokumentation Kubernetes.

Pod Security Admission ist für Red Hat OpenShift on IBM Cloud Version 4.11 und höher immer aktiviert. Frühere Versionen von Kubernetes verwenden Pod-Sicherheitsrichtlinien.

Verstehen von Sicherheitsprofilen

Die Kubernetes pod security standards definieren die folgenden drei Profile.

Privilegiert
Die Standard-Pod-Sicherheitskonfiguration erzwingt global das Pod-Sicherheitsprofil privileged Kubernetes, das nicht eingeschränkt ist und bekannte Privilegienerweiterungen zulässt, und erzeugt Warnungen und Audit-Ereignisse auf der Grundlage der vom Profil restricted festgelegten Richtlinien.
Grundlegende Verpflichtungen
Das Profil baseline ist ein restriktives Profil, das bekannte Privilegienerweiterungen verhindert. Erlaubt die standardmäßige (minimal spezifizierte) Pod-Konfiguration.
Eingeschränkt
Das Profil restricted ist stark eingeschränkt und entspricht den aktuellen Best Practices für Pod-Hardening.

Weitere Informationen über Pod-Sicherheitsprofile finden Sie unter Profildetails in der Dokumentation Kubernetes.

Pod Security Admission enthält drei Modi, die festlegen, welche Maßnahmen die Steuerungsebene ergreift, wenn eine mögliche Verletzung festgestellt wird.

durchsetzen
Verstöße gegen die Richtlinien führen zur Ablehnung des Pods.
prüfen
Richtlinienverstöße führen dazu, dass dem im Audit-Protokoll aufgezeichneten Ereignis ein Audit-Vermerk hinzugefügt wird, sind aber ansonsten zulässig.
warn
Verstöße gegen die Richtlinie führen zu einer Warnung für den Benutzer, sind aber ansonsten zulässig.

Wenn sich Sicherheitsstandards oder Profilimplementierungen ändern, um neue Funktionen zu berücksichtigen, können Sie Pod Security Admission so konfigurieren, dass eine bestimmte Version der Rollen verwendet wird. Die folgenden Versionen werden unterstützt.

  • Eine Kubernetes major.minor Version (zum Beispiel v1.25)
  • latest

Was ist, wenn die Zulassung zur Pod Security nicht die richtige Wahl für mich ist?

Während Pod Security Admission immer aktiviert ist, kann es sich um einen von mehreren Admission Controllern handeln. Sie können die Zulassungssteuerungen von Drittanbietern Kubernetes so konfigurieren, dass sie andere Sicherheitsrichtlinienmodelle implementieren, die Ihrem Anwendungsfall entsprechen.

Wenn Sie die Pod-Sicherheitszulassung so konfigurieren, dass sie unter Verwendung des Profils privileged durchgesetzt, gewarnt und geprüft wird, erlaubt die Steuerungsebene allen Pods den Betrieb. Sie können dann andere Zulassungssteuerungen so konfigurieren, dass sie diese ablehnen.

Sie können einen Zutrittskontroller eines Drittanbieters installieren, solange er keine der folgenden Aktionen ausführt.

  • Es installiert keine eigenen Pod-Sicherheitsrichtlinien (PSPs).
  • Sie verlässt sich nicht auf die PSPs, um Teile der Politik durchzusetzen.

Konfigurieren von Namespace-Labels für die Pod-Sicherheitszulassung

Sie können den Modus der Zulassungskontrolle, den Sie für die Pod-Sicherheit verwenden möchten, in jedem Namensraum festlegen. Kubernetes definiert eine Reihe von Bezeichnungen, die Sie festlegen können, um zu definieren, welches der vordefinierten Pod Security Standard-Profile Sie für einen Namensraum verwenden möchten. Die von Ihnen gewählte Bezeichnung legt fest, welche Maßnahmen die Steuerungsebene ergreift, wenn eine potenzielle Verletzung festgestellt wird.

Standardmäßig fügt Red Hat OpenShift on IBM Cloud die privileged Pod Security-Labels zu den folgenden Namespaces hinzu. Diese Namensräume werden mit Hilfe des Profils privileged in enforce, audit und warn umbenannt.

  • kube-system
  • ibm-system
  • ibm-operators
  • calico-system
  • tigera-operator
  • calico-apiserver (Version 4.16 und höher)

Entfernen oder ändern Sie nicht die Bezeichnungen für diese Namensräume oder einen der Namensräume openshift-*.

Ein Namensraum kann so beschriftet werden, dass das Pod-Sicherheitsprofil für einen oder alle Pod Security Admission modes festgelegt wird.

Sie können zum Beispiel einen Namensraum so kennzeichnen, dass er das Profil privileged erzwingt, zusätzlich zur Verwendung von warn oder audit durch Verwendung des Profils baseline.

Diese Kennzeichnung ermöglicht Administratoren und Anwendungsentwicklern einen Trockenlauf von Anwendungen, indem sie nur nach Warnungen und Audit-Einträgen im baseline Profil suchen, ohne Pods abzulehnen. Anschließend können Sie die notwendigen Änderungen an Ihren Workloads vornehmen, bevor Sie den Erzwingungsmodus auf baseline ändern.

Die Namensraumbezeichnungen für den Pod Security Admission haben die Form pod-security.kubernetes.io/<MODE>: <LEVEL> und pod-security.kubernetes.io/<MODE>-version: <VERSION>.

  • pod-security.kubernetes.io/enforce
  • pod-security.kubernetes.io/enforce-version
  • pod-security.kubernetes.io/audit
  • pod-security.kubernetes.io/audit-version
  • pod-security.kubernetes.io/warn
  • pod-security.kubernetes.io/warn-version

Um einen Namespace zu kennzeichnen, um das Profil privileged durchzusetzen und Warnungen und Audit-Ereignisse für Verletzungen des Profils baseline zu erzeugen, verwenden Sie die folgenden Kennzeichnungen.

  • pod-security.kubernetes.io/enforce: privileged
  • pod-security.kubernetes.io/enforce-version: latest
  • pod-security.kubernetes.io/audit: baseline
  • pod-security.kubernetes.io/audit-version: latest
  • pod-security.kubernetes.io/warn: baseline
  • pod-security.kubernetes.io/warn-version: latest

Standardkonfiguration des Pod Security Admission Plug-ins

Red Hat OpenShift on IBM Cloud verwendet standardmäßig die folgenden PodSecurityConfiguration.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

Konfigurieren der Pod-Sicherheitszulassung

Sie können das Pod-Sicherheitsverhalten auf der Namespace-Ebene mit vordefinierten Pod-Sicherheitslabels konfigurieren. Weitere Informationen zur Konfiguration finden Sie unter Steuerung der Synchronisierung der Pod-Sicherheitszulassung in der Dokumentation Red Hat OpenShift. Beachten Sie, dass die Schritte für jede Clusterversion unterschiedlich sind. Stellen Sie daher sicher, dass Sie die Schritte für die richtige Version anzeigen.

Weitere Informationen zur Konfiguration von apiserver Protokollen für Red Hat OpenShift on IBM Cloud finden Sie unter Kubernetes API-Server-Auditprotokolle.

Die Pod-Sicherheitszulassung bietet die Möglichkeit, Pods, die gegen die Sicherheitsprofile verstoßen, zu erzwingen, zu warnen und Audit-Ereignisse zu erzeugen. In OpenShift 4.11 erzwingt die Standardkonfiguration das privilegierte Profil, erzeugt aber auch Warnungen und Prüfungsereignisse auf der Grundlage des Profils restricted. Dieses Verhalten kann auf Namespace-Ebene durch die Verwendung von vordefinierten Pod-Sicherheitskennzeichnungen für Namespaces gesteuert werden. Wenn die Pod-Sicherheitsprofile erzwungen werden, werden möglicherweise Warnungen wie die im folgenden Beispiel angezeigt.

`Warning: would violate PodSecurity "restricted:latest": host namespaces (hostNetwork=true, hostPID=true), privileged (container "container-00" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "container-00" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "container-00" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "host" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "container-00" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "container-00" must not set runAsUser=0), seccompProfile (pod or container "container-00" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")`

In diesem Beispiel wird der Pod dennoch erstellt und kann ausgeführt werden, solange das Dienstkonto für ein SecurityContextConstraint Profil autorisiert ist. Die Warnung weist darauf hin, dass Änderungen am securityContext-Profil des Pods und des Containers erforderlich sind, damit der Pod unter dem angegebenen Pod-Sicherheitsprofil ausgeführt werden kann, z. B. das Setzen der Option allowPrivilegeEscalation=false, oder dass ein Pod-Sicherheitsprofil verwendet werden muss, das diese Fähigkeiten zulässt.

Red Hat OpenShift enthält auch einen Controller, der Namespace-Labels auf der Grundlage der SCC-Berechtigungen der Dienstkonten in einem bestimmten Namespace anwendet. Es werden sowohl die Pod-Sicherheitszulassung als auch die SCCs angewendet. Sie können in erster Linie SCCs verwenden und den Pod Security Admission Synchronization Controller einsetzen, um das Pod Security Label auf dem Namespace anzupassen. Oder Sie können in erster Linie Pod-Sicherheitsprofile mit einer Namespace-Rollenbindung verwenden, die es allen Dienstkonten im Namespace ermöglicht, eine gleichwertige (oder privilegiertere) SCC zu verwenden. Definieren Sie keine Rollenbindungen oder Cluster-Rollenbindungen, die global gelten, wie z. B. alle autorisierten Benutzer oder alle Dienstkonten in allen Namensräumen, da diese Bindungen Red Hat OpenShift Komponenten beeinflussen können, die unter einer bestimmten SCC ausgeführt werden sollen.

Zusätzliche Ressourcen