You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In {product-title}, you can use security context constraints (SCCs) to control permissions for the pods in your cluster.
10
+
11
+
Default SCCs are created during installation and when you install some Operators or other components. As a cluster administrator, you can also create your own SCCs by using the OpenShift CLI (`oc`).
12
+
13
+
[IMPORTANT]
14
+
====
15
+
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or
16
+
ifndef::openshift-rosa[]
17
+
{product-title}
18
+
endif::[]
19
+
ifdef::openshift-rosa[]
20
+
ROSA
21
+
endif::openshift-rosa[]
22
+
is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see xref:../authentication/managing-security-context-constraints.adoc#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
26
+
endif::[]
27
+
====
28
+
29
+
ifdef::openshift-dedicated[]
30
+
[NOTE]
31
+
====
32
+
In {product-title} deployments, you can create your own SCCs only for clusters that use the Customer Cloud Subscription (CCS) model. You cannot create SCCs for {product-title} clusters that use a Red Hat cloud account, because SCC resource creation requires `cluster-admin` privileges.
Similar to the way that RBAC resources control user access, administrators can use _security context constraints_ (SCCs) to control permissions for pods. These permissions include actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system.
9
+
Similar to the way that RBAC resources control user access, administrators can use security context constraints (SCCs) to control permissions for pods. These permissions determine the actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system.
10
10
11
11
Security context constraints allow an administrator to control:
12
12
13
-
* Whether a pod can run privileged containers with the `allowPrivilegedContainer` flag.
14
-
* Whether a pod is constrained with the `allowPrivilegeEscalation` flag.
13
+
* Whether a pod can run privileged containers with the `allowPrivilegedContainer` flag
14
+
* Whether a pod is constrained with the `allowPrivilegeEscalation` flag
15
15
* The capabilities that a container can request
16
16
* The use of host directories as volumes
17
17
* The SELinux context of the container
@@ -35,10 +35,17 @@ The cluster contains several default security context constraints (SCCs) as desc
35
35
36
36
[IMPORTANT]
37
37
====
38
-
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or {product-title} is upgraded. During upgrades between some versions of {product-title}, the values of the default SCCs are reset to the default values, which discards all customizations to those SCCs.
38
+
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or
39
+
ifndef::openshift-rosa[]
40
+
{product-title}
41
+
endif::[]
42
+
ifdef::openshift-rosa[]
43
+
ROSA
44
+
endif::openshift-rosa[]
45
+
is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
= Creating security context constraints for CCS clusters
12
+
endif::[]
8
13
9
14
You can create security context constraints (SCCs) by using the OpenShift CLI (`oc`).
10
15
16
+
[IMPORTANT]
17
+
====
18
+
Creating and modifying your own SCCs are advanced operations that might cause instability to your cluster. If you have questions about using your own SCCs, contact Red Hat Support. For information about contacting Red Hat support, see _Getting support_.
19
+
====
20
+
21
+
ifdef::openshift-dedicated[]
22
+
[NOTE]
23
+
====
24
+
In {product-title} deployments, you can create your own SCCs only for clusters that use the Customer Cloud Subscription (CCS) model. You cannot create SCCs for {product-title} clusters that use a Red Hat cloud account, because SCC resource creation requires `cluster-admin` privileges.
25
+
====
26
+
endif::openshift-dedicated[]
27
+
11
28
.Prerequisites
12
29
13
30
* Install the OpenShift CLI (`oc`).
14
31
* Log in to the cluster as a user with the `cluster-admin` role.
15
32
16
33
.Procedure
17
34
18
-
. Define the SCC in a YAML file named `scc_admin.yaml`:
35
+
. Define the SCC in a YAML file named `scc-admin.yaml`:
19
36
+
20
-
.`SecurityContextConstraints` object definition
21
37
[source,yaml]
22
38
----
23
39
kind: SecurityContextConstraints
@@ -39,11 +55,7 @@ groups:
39
55
- my-admin-group
40
56
----
41
57
+
42
-
Optionally, you can drop specific capabilities for an SCC by setting the
43
-
`requiredDropCapabilities` field with the desired values. Any specified
44
-
capabilities are dropped from the container. To drop all capabilities, specify `ALL`. For example, to create an SCC
45
-
that drops the `KILL`, `MKNOD`, and `SYS_CHROOT` capabilities, add
46
-
the following to the SCC object:
58
+
Optionally, you can drop specific capabilities for an SCC by setting the `requiredDropCapabilities` field with the desired values. Any specified capabilities are dropped from the container. To drop all capabilities, specify `ALL`. For example, to create an SCC that drops the `KILL`, `MKNOD`, and `SYS_CHROOT` capabilities, add the following to the SCC object:
47
59
+
48
60
[source,yaml]
49
61
----
@@ -65,7 +77,7 @@ CRI-O supports the same list of capability values that are found in the link:htt
0 commit comments