Sicherheitskontexteinschränkungen konfigurieren

Mit Sicherheitskontexteinschränkungen (SCCs = Security Context Constraints) können Sie die Aktionen steuern, die von Pods in Ihrem Red Hat® OpenShift® on IBM Cloud®-Cluster ausgeführt werden, und festlegen, auf welche Komponenten die Pods zugreifen können. Weitere Informationen zu SCCs finden Sie in der Red Hat OpenShift Dokumentation.

Warum lege ich Einschränkungen für den Sicherheitskontext fest?
Als Clusteradministrator möchten Sie steuern, was in Ihrem Cluster passiert, insbesondere Aktionen, die sich auf die Sicherheit oder Bereitschaft des Clusters auswirken. Sicherheitskontexteinschränkungen können Ihnen dabei helfen, die Aktionen und den Zugriff der Pods in Ihrem Container zu steuern. Hierzu gehören beispielsweise die Nutzung von berechtigten Containern, Rootnamensbereichen, des Hostnetzbetriebs und der entsprechenden Ports, der Datenträgertypen, Hostdateisysteme und Linux-Berechtigungen (z. B. schreibgeschützte IDs oder Gruppen-IDs) usw.
Kann ich auch Benutzer oder Systemgruppen zu SCCs hinzufügen?
Verwenden Sie keine SCCs für den Benutzerzugriff auf Ihre Clusterressourcen. Unter Clusterzugriff zuweisen finden Sie stattdessen in den Informationen zum Festlegen der IBM Cloud IAM- und Infrastrukturberechtigungen.
Bei Systemgruppen wie system:authenticated sind diese Gruppen bereits SCCs zugeordnet. Sie können sehen, welche Gruppen einem SCC zugeordnet sind, indem Sie den SCC beschreiben. Wenn Sie den SCC, dem eine Systemgruppe zugeordnet ist, ändern, können Standardkomponenten, die der Systemgruppe angehören, Fehler aufgrund der Änderung in den Berechtigungen enthalten.
Sind standardmäßig irgendwelche SCCs festgelegt?
Standardmäßig umfassen Red Hat OpenShift on IBM Cloud-Cluster eine Standardgruppe von Red Hat OpenShift-SCCs. Darüber hinaus verfügen Cluster über SCCs(IBM), die den Pod-Sicherheitsrichtlinien ( Kubernetes ) von Community- Kubernetes-Clustern unter IBM Cloud Kubernetes Service sehr ähnlich sind. Diese IBM SCCs werden zur Verbesserung der Portierbarkeit in IBM Cloud Private-Pakete wie beispielsweise Cloud Paks eingebunden.
Welche SCCs werden standardmäßig auf meine Ressourcen angewendet?
Wenn Sie keinen Sicherheitskontext angeben, wird die Integritätsbedingung für den Sicherheitskontext Red Hat OpenShift restricted (oder restricted-v2 in 4.11 und höher) standardmäßig angewendet. Den Sicherheitskontext eines Pods können Sie ermitteln, indem Sie den describe-Befehl für den Pod ausführen und die SCC-Annotation wie z. B. im folgenden Beispiel suchen.
oc describe pod <pod_name>

Name:               <pod_name>
Namespace:          <project_name>
...
Annotations:        openshift.io/...
                    openshift.io/scc=restricted
...
Kann ich stattdessen die Sicherheitsrichtlinien für „ Kubernetes “-Pods verwenden?
Anzahl Kubernetes Pod-Sicherheitsrichtlinien (PSPs) basieren ursprünglich auf Red Hat OpenShift-SCCs. Red Hat OpenShift unterstützt allerdings nur SCCs, jedoch keine PSPs.

Die standardmäßigen Red Hat OpenShift-SCCs sind strenger als die standardmäßigen PSPs in Community-Kubernetes-Clustern. Aus diesem Grund müssen App-Bereitstellungen, die in Community-Kubernetes-Clustern ausgeführt werden, möglicherweise geändert werden, um sie in Red Hat OpenShift ausführen zu können.

Sicherheitskontexteinschränkungen anpassen

Informationen zum Erstellen, Bearbeiten, Auflisten, Löschen und Verwalten von Sicherheitskontextbeschränkungen finden Sie in der Red Hat OpenShift Dokumentation. Sie können auch Benutzer oder Gruppen für die Standardvorgaben für Sicherheitskontexte berechtigen, indem Sie rollenbasierte Zugriffssteuerung wie clusterroles, clusterrolebindings, roles und rolebindings verwenden. Sie können diese Einstellungen auch mit den oc adm policy-Unterbefehlen wie oc adm policy add-scc-to-user verwalten. Die OC-Version ist mit der des verwalteten Clusters identisch.

Richtlinien für die Zuweisung von Zugriff auf SCCs

  • Autorisieren Sie bestimmte Servicekonten für die SCC, die von Pods verwendet werden sollen, die unter diesem Servicekonto ausgeführt werden.
  • Wenn ein Servicekonto Zugriff auf mehrere SCCs benötigt, sollten Sie zusätzliche Servicekonten erstellen, damit alle Pods, die unter einem Servicekonto ausgeführt werden, dieselbe SCC verwenden.
  • Autorisieren Sie nicht alle Benutzer oder alle Servicekonten für die Verwendung von SCCs mit Ausnahme von restricted (4.10 und früher) oder restricted-v2 (4.11 und höher).
  • Ändern Sie die SCC-Berechtigung für Servicekonten in den openshift-*-Namensbereichen nicht. Red Hat OpenShift-Komponenten sind für die Ausführung unter bestimmten SCCs konzipiert und funktionieren möglicherweise nicht ordnungsgemäß unter einer anderen SCC.

Standardmäßige Red Hat OpenShift-Sicherheitskontexteinschränkungen

Red Hat OpenShift on IBM Cloud-Cluster werden standardmäßig mit den folgenden Sicherheitskontexteinschränkungen ausgeliefert.

Bereits vorhandene Red Hat OpenShift- oder IBM SCC-Einstellungen dürfen nicht bearbeitet werden. Eine Ausnahme bilden hierbei lediglich die Werte in den Feldern priority, users und groups.

Standardsicherheitskontextvorgaben Red Hat OpenShift
SCC-Name Beschreibung
anyuid Verhindert den Zugriff ähnlich wie die SCC restricted, ermöglicht Benutzern jedoch die Ausführung mit jeder UID und GID.
hostaccess Ermöglicht den Zugriff auf alle Host-Namensbereiche, erfordert jedoch, dass Pods mit einer UID und im SELinux-Kontext ausgeführt werden, die den Namensbereichen zugewiesen sind.

Wichtig: Erteilen Sie diese SCC nur für vertrauenswürdige Pods, die Hostzugriff auf Namensbereiche, Dateisysteme und Prozess-IDs erfordern.
hostmount-anyuid Verhindert den Zugriff ähnlich wie die SCC restricted, ermöglicht jedoch Host-Mounts und beliebige UIDs für einen Pod. Diese SCC wird primär vom Recycler für persistente Datenträger verwendet.

Wichtig: Erteilen Sie diese SCC nur für Pods, die Zugriff auf das Hostdateisystem als beliebige UID, einschließlich UID 0, erfordern.
hostnetwork Lässt die Nutzung des Hostnetzbetriebs und der Host-Ports zu, setzt jedoch weiterhin voraus, dass die Pods mit einem UID- und SELinux-Kontext ausgeführt werden, der dem Namensbereich zugeordnet ist.

Wichtig: Erteilen Sie diese SCC nur für Pods, die Hostnetzzugriff erfordern.
node-exporter Erteilt den benötigten Zugriff für die integrierte Prometheus-Knotenexportfunktion.
nonroot Verhindert den Zugriff ähnlich wie die SCC restricted, ermöglicht Benutzern jedoch die Ausführung mit jeder UID ohne Rootberechtigung. Entweder muss der Benutzer die UID angeben oder diese muss im Manifest der Laufzeitkomponente des Containers angegeben sein.
privileged Ermöglicht den Zugriff auf alle privilegierten Funktionen und Host-Funktionen sowie die Möglichkeit, sich als beliebiger Benutzer, in beliebiger Gruppe, mit beliebigen „ fsGroup “-Einstellungen und in jedem SELinux-Kontext anzumelden.

Wichtig: Erteilen Sie diese SCC ausschließlich für die Clusterverwaltung, die den größtmöglichen Zugriff erfordert.
restricted Verhindert den Zugriff auf alle Hostfunktionen und setzt voraus, dass die Pods mit einem UID- und SELinux-Kontext ausgeführt werden, der dem Namensbereich zugeordnet ist. Dies ist die SCC mit den stärksten Einschränkungen, die standardmäßig für authentifizierte Benutzer verwendet wird.
hostnetwork-v2 Ähnelt der hostnetwork-SCC, wurde jedoch geändert, um Unterschiede zum Restricted-Profil für Pod-Sicherheitsstandards zu minimieren.
nonroot-v2 Ähnelt der nonroot-SCC, wurde jedoch geändert, um Unterschiede zum Restricted-Profil für Pod-Sicherheitsstandards zu minimieren.
restricted-v2 Ähnelt der restricted-SCC, wurde jedoch geändert, um dem Restricted-Profil für Pod-Sicherheitsstandards zu entsprechen.

Standardmäßige IBM Sicherheitskontexteinschränkungen

Red Hat OpenShift on IBM Cloud-Cluster werden standardmäßig mit den folgenden IBM Sicherheitskontexteinschränkungen ausgeliefert.

Bereits vorhandene Red Hat OpenShift- oder IBM SCC-Einstellungen dürfen nicht bearbeitet werden. Eine Ausnahme bilden hierbei lediglich die Werte in den Feldern priority, users und groups.

Standardmäßige IBM Sicherheitskontexteinschränkungen
SCC-Name Beschreibung
ibm-anyuid-hostaccess-scc Ermöglicht die Ausführung von Pods mit allen UIDs und GIDs, allen Datenträgern sowie vollem Zugriff auf den Host.

Wichtig: Erteilen Sie diese SCC nur für Pods, die vollständigen Zugriff auf den Host und das Netz erfordern.
ibm-anyuid-hostpath-scc Lässt die Ausführung von Pods mit einer beliebigen UID und GID sowie einem beliebigen Datenträger (einschließlich Hostpfad) zu.

Wichtig: Erteilen Sie diese SCC nur für Pods, die Zugriff auf hostPath-Datenträger erfordern.
ibm-anyuid-scc Lässt die Ausführung von Pods mit einer beliebigen UID und GID zu, verhindert jedoch den Zugriff auf den Host.
ibm-privileged-scc Gewährt Zugriff auf alle privilegierten Host-Funktionen und ermöglicht die Ausführung von Pods mit allen UIDs und GUIDs sowie allen Datenträgern.

Wichtig: Erteilen Sie diese SCC nur für die Clusterverwaltung, die den größtmöglichen Zugriff erfordert.
ibm-restricted-scc Verhindert den Zugriff auf alle Hostfunktionen und setzt voraus, dass die Pods mit einem UID- und SELinux-Kontext ausgeführt werden, der dem Namensbereich zugeordnet ist. Diese SCC stellt die restriktivste IBM Sicherheitskontexteinschränkung dar.