Red Hat OpenShift 4.11 ile Gelen ‘’Yeni Security Context Constraints’’ Politikaları

Hazırlayan: Melek Sima Turunç – Sekom - AppDev&DevOps Uzmanı

Security Context Constraint (SCC), Red Hat OpenShift’in podlarına has bir RBAC (Role-based Access Control) teknolojisidir. SCC, mevcut podu bir grup kaynakla sınırlayan Red Hat OpenShift bileşenidir. Birincil amacı, bir podun host ortamına erişimini sınırlamaktır. Adminler, podların yetkilerini kontrol etmek ve bir podun sisteme kabul edilmesi için birlikte çalışması gereken koşulları tanımlamak için SCC'leri kullanırlar. Bu izinler, bir podun gerçekleştirebileceği eylemleri, podların hangi yetkilendirilmiş containerları çalıştırıp hangilerini çalıştıramayacağını, containerın SELinux bilgisini ve podun hangi kaynaklara erişebileceğini içerir.

Kubernetes 1.21'den itibaren opsiyonel olarak kullanılan PodSecurityPolicy, Kubernetes 1.25’in yayınlanmasıyla tamamen kaldırılmıştır ve yerini namespace level’da uygulanan pod security admission control bileşenine bırakmıştır. Red Hat OpenShift, Kubernetes’te gerçekleştirilen değişiklikle uyumlu olabilmek için API'lerini güncellemiştir

Hangi API'lerin kullanımdan kaldırıldığı ve artık hangi yayın sürümü için sunulmayacağı hakkında daha fazla bilgi için Kubernetes web sitesinde yer alan Deprecated API Migration Guide ’ı inceleyebilirsiniz. Ayrıca, API değişiklikleri için Red Hat OpenShift operatörlerinizi nasıl güncelleyeceğinizle ilgili gerekli bilgi için Updating your operators for OpenShift when Kubernetes changes APIs dokümanını inceleyebilirsiniz.

Pod Security Admission Control’ün kullanılmasıyla birlikte namespace ve pod’lar 3 farklı pod security standart ilkeleri ile tanımlanabilir olacaktır. Bunlar Privileged, Baseline ve Restricted’dır. Bu nedenle de Red Hat OpenShift 4.11 ile gelen yeni SCC politikaları (restricted-v2, nonroot-v2, and hostnetwork-v2) gereği namespace level’da security standartları ile yapılandırılmayan pod’lar kabul edilmeyecek ve çalışmayacaktır.

Default Security Context Constraints

Security context constraint(SCC)	Description
anyuid	Provides all features of the restricted SCC, but allows users to run with any UID and any GID. Allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.
hostaccess	This SCC allows host access to namespaces, file systems, and PIDs. It should only be used by trusted pods. Grant with caution.
hostmount-anyuid	Provides all the features of the restricted SCC, but allows host mounts and running as any UID and any GID on the system. This SCC allows host file system access as any UID, including UID 0. Grant with caution.
hostnetwork	Allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that is allocated to the namespace. If additional workloads are run on control plane hosts, use caution when providing access to hostnetwork. A workload that runs hostnetwork on a control plane host is effectively rooted in the cluster and must be trusted accordingly.
hostnetwork-v2	Like the hostnetwork SCC, but with the following differences: ALL capabilities are dropped from containers The NET_BIND_SERVICE capability can be added explicitly. seccompProfile is set to runtime/default by default allowPrivilegeEscalation must be unset or set to false in security contexts. Used for the Prometheus node exporter.
node-exporter	Used for the Prometheus node exporter. This SCC allows host file system access as any UID, including UID 0. Grant with caution.
nonroot	Provides all features of the restricted SCC, but allows users to run with any non-root UID. The user must specify the UID or it must be specified in the manifest of the container runtime. Like the nonroot SCC, but with the following differences: ALL capabilities are dropped from containers.
nonroot-v2	The NET_BIND_SERVICE capability can be added explicitly. seccompProfile is set to runtime/default by default. allowPrivilegeEscalation must be unset or set to false in security contexts.
privileged	Allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context. This is the most relaxed SCC and should be used only for cluster administration. Grant with caution. The privileged SCC allows: Users to run privileged pods Pods to mount host directories as volumes Pods to run as any user Pods to run with any MCS label Pods to use the host’s IPC namespace Pods to use the host’s PID namespace Pods to use any FSGroup Pods to use any supplemental group Pods to use any seccomp profiles Pods to request any capabilities Setting privileged: true in the pod specification does not necessarily select the privileged SCC. The SCC that has allowPrivilegedContainer: true and has the highest prioritization will be chosen if the user has permission to use it.
restricted	Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. The restricted SCC: Ensures that pods cannot run as privileged Ensures that pods cannot mount host directory volumes Requires that a pod is run as a user in a pre-allocated range of UIDs Requires that a pod is run with a pre-allocated MCS label Allows pods to use any FSGroup Allows pods to use any supplemental group In clusters that were upgraded from OpenShift Container Platform 4.10 or earlier, this SCC is available for use by any authenticated user. The restricted SCC is no longer available to users of new OpenShift Container Platform 4.11 installations unless the access is explicitly granted.
restricted-v2	Like the restricted SCC, but with the following differences: ALL capabilities are dropped from containers. The NET_BIND_SERVICE capability can be added explicitly. seccompProfile is set to runtime/default by default. allowPrivilegeEscalation must be unset or set to false in security contexts This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users. The restricted-v2 SCC is the most restrictive of the SCCs that is included by default with the system. However, you can create a custom SCC that is even more restrictive. For example, you can create an SCC that restricts readOnlyRootFilesystem to true.

Security Context Constraints Strategies

RunAsUser

MustRunAs - Requires a runAsUser to be configured. Uses the configured runAsUser as the default. Validates against the configured runAsUser.
MustRunAsRange - Requires minimum and maximum values to be defined if not using pre-allocated values. Uses the minimum as the default. Validates against the entire allowable range.
MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined in the image. No default was provided.
RunAsAny - No default provided. Allows any runAsUser to be specified.

SELinuxContext

MustRunAs - Requires seLinuxOptions to be configured if not using pre-allocated values. Uses seLinuxOptions as the default. Validates against seLinuxOptions
RunAsAny - No default provided. Allows any seLinuxOptions to be specified.

SupplementalGroups

MustRunAs - Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against all ranges.
RunAsAny - No default provided. Allows any SupplementalGroups to be specified.

FSGroup

MustRunAs - Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against the first ID in the first range
RunAsAny - No default provided. Allows any fsGroup ID to be specified.

Kaynak: Table 1

SCC Kaynaklı Alınan Hatalar ve Knowledgebase’lerinden Örnekler:

Red Hat OpenShift 4.11 workload’larının "Operation not permitted" kodu ile fail olması

Çözüm 1

Red Hat OpenShift Container Platform 4.11’e upgrade sonrasında restricted Security Context Constraint’inin restricted-v2 Security Context Constraint’ine migrate’i sonrasında SCC’nin düzgün çalışmamasından kaynaklı spesific workload’larda problem yaşanması

Çözüm 2

Red Hat OpenShift 4.11'de yeni pod yaratırken "allowPrivilegeEscalation: true" nedeniyle process’in fail olması.

Çözüm 3

Kaynak

Red Hat konusundaki güncellemelerden blog yazılarımız ile haberdar olabilirsiniz, Red Hat Enterprise Linux 9.1 ve 8.7 Yayınlandı blog yazımızı tıklayarak hemen okuyun!