Red Hat OpenShift 4.11 ile Gelen ‘’Yeni Security Context Constraints’’ Politikaları
04 Oca 2023
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 :
|
| 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:
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:
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:
This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users. |
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ı
- 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ı
- Red Hat OpenShift 4.11’de yeni pod yaratırken “allowPrivilegeEscalation: true” nedeniyle process’in fail olması.
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!
