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 Dokumentation zuRed Hat OpenShift.

Warum lege ich Sicherheitskontextbeschränkungen 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 irgendwelche SCCs standardmäßig eingestellt?: Standardmäßig umfassen Red Hat OpenShift on IBM Cloud-Cluster eine Standardgruppe von Red Hat OpenShift-SCCs. Darüber hinaus haben Cluster IBM SCCs, die den Kubernetes pod-Sicherheitsrichtlinien von Community Kubernetes-Clustern in 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 Kubernetes pod security policies 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

Um Sicherheitskontexteinschränkungen zu erstellen, zu bearbeiten, aufzulisten, zu löschen und anderweitig zu verwalten, siehe die Red Hat OpenShift docs. 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: Gewähren Sie diesen SCC nur vertrauenswürdigen Pods, die Host-Zugriff auf Namespaces, Dateisysteme und Prozess-IDs benötigen.
`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: Gewähren Sie diesen SCC nur für Pods, die als beliebige UID, einschließlich UID 0, Zugriff auf das Host-Dateisystem benötigen.
`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: Gewähren Sie diesen SCC nur für Pods, die Zugriff auf das Hostnetz benötigen.
`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 und Host-Funktionen und die Möglichkeit, als beliebiger Benutzer, beliebige Gruppe, beliebige `fsGroup`-Einstellung und mit beliebigem SELinux-Kontext zu laufen. Wichtig: Gewähren Sie diese SCC nur 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: Gewähren Sie diesen SCC nur für Pods, die vollen Zugriff auf den Host und das Netzwerk benötigen.
`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: Gewähren Sie diese SCC nur für Pods, die Zugriff auf `hostPath` Volumes benötigen.
`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: Gewähren 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.