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
- The allocation of an `FSGroup` that owns the pod's volumes.
24
-
- The configuration of allowable supplemental groups.
25
-
- Whether a container requires the use of a read only root file system.
26
-
- The usage of volume types.
27
-
- The configuration of allowable `seccomp` profiles.
28
-
29
-
////
30
-
If you have `cluster-admin` privileges, you can adjust the default SCC policies to
31
-
be more permissive.
32
-
////
33
-
34
-
The cluster contains nine default SCCs:
35
-
36
-
* `anyuid`
37
-
* `hostaccess`
38
-
* `hostmount-anyuid`
39
-
* `hostnetwork`
40
-
+
41
-
[WARNING]
42
-
====
43
-
If additional workloads are run on control plane hosts (also known as the master hosts), use caution when providing access to `hostnetwork`. A workload that runs `hostnetwork` on a control plane host is effectively root on the cluster and must be trusted accordingly.
44
-
====
45
-
* `node-exporter`
46
-
* `nonroot`
47
-
* `privileged`
48
-
* `restricted`
49
-
* `pipelines-scc`
8
+
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
+
10
+
Security context constraints allow an administrator to control:
50
11
12
+
* Whether a pod can run privileged containers
13
+
* The capabilities that a container can request
14
+
* The use of host directories as volumes
15
+
* The SELinux context of the container
16
+
* The container user ID
17
+
* The use of host namespaces and networking
18
+
* The allocation of an `FSGroup` that owns the pod volumes
19
+
* The configuration of allowable supplemental groups
20
+
* Whether a container requires write access to its root file system
21
+
* The usage of volume types
22
+
* The configuration of allowable `seccomp` profiles
23
+
24
+
[id="default-sccs_{context}"]
25
+
== Default security context constraints
26
+
27
+
The cluster contains several default security context constraints (SCCs) as described in the table below. Additional SCCs might be installed when you install Operators or other components to {product-title}.
51
28
52
29
[IMPORTANT]
53
30
====
54
31
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.
| Provides all features of the `restricted` SCC, but allows users to run with any UID and any GID.
44
+
45
+
|`hostaccess`
46
+
|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.
47
+
48
+
[WARNING]
49
+
====
50
+
This SCC allows host access to namespaces, file systems, and PIDS. It should only be used by trusted pods. Grant with caution.
51
+
====
52
+
53
+
|`hostmount-anyuid`
54
+
|Provides all the features of the `restricted` SCC, but allows host mounts and running as any UID and any GID on the system.
55
+
56
+
[WARNING]
57
+
====
58
+
This SCC allows host file system access as any UID, including UID 0. Grant with caution.
59
+
====
60
+
61
+
|`hostnetwork`
62
+
|Allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.
63
+
64
+
[WARNING]
65
+
====
66
+
If additional workloads are run on control plane hosts (also known as the master hosts), use caution when providing access to `hostnetwork`. A workload that runs `hostnetwork` on a control plane host is effectively root on the cluster and must be trusted accordingly.
67
+
====
68
+
69
+
|`node-exporter`
70
+
|Used for the Prometheus node exporter.
71
+
72
+
[WARNING]
73
+
====
74
+
This SCC allows host file system access as any UID, including UID 0. Grant with caution.
75
+
====
76
+
77
+
|`nonroot`
78
+
|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.
79
+
80
+
|`privileged`
81
+
|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.
82
+
83
+
[WARNING]
84
+
====
85
+
This is the most relaxed SCC and should be used only for cluster administration. Grant with caution.
86
+
====
87
+
60
88
The `privileged` SCC allows:
61
89
62
90
* Users to run privileged pods
@@ -70,25 +98,32 @@ The `privileged` SCC allows:
70
98
* Pods to use any seccomp profiles
71
99
* Pods to request any capabilities
72
100
73
-
The `restricted` SCC:
74
-
75
-
* Ensures that pods cannot run as privileged.
76
-
* Ensures that pods cannot mount host directory volumes.
77
-
* Requires that a pod run as a user in a pre-allocated range of UIDs.
78
-
* Requires that a pod run with a pre-allocated MCS label.
79
-
* Allows pods to use any FSGroup.
80
-
* Allows pods to use any supplemental group.
81
-
82
101
[NOTE]
83
102
====
84
-
For more information about each SCC, see the `kubernetes.io/description`
85
-
annotation available on the SCC.
103
+
Setting `privileged: true` in the pod specification does not select the `privileged` SCC. Setting `privileged: true` in the pod specification matches on the `allowPrivilegedContainer` field of an SCC.
86
104
====
87
105
88
-
SCCs are composed of settings and strategies that control the security features
106
+
|`restricted`
107
+
|Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. This is the most restrictive SCC and it is used by default for authenticated users.
108
+
109
+
The `restricted` SCC:
110
+
111
+
* Ensures that pods cannot run as privileged
112
+
* Ensures that pods cannot mount host directory volumes
113
+
* Requires that a pod is run as a user in a pre-allocated range of UIDs
114
+
* Requires that a pod is run with a pre-allocated MCS label
115
+
* Allows pods to use any FSGroup
116
+
* Allows pods to use any supplemental group
117
+
118
+
|===
119
+
120
+
[id="scc-settings_{context}"]
121
+
== Security context constraints settings
122
+
123
+
Security context constraints (SCCs) are composed of settings and strategies that control the security features
89
124
a pod has access to. These settings fall into three categories:
90
125
91
-
[cols="1,4",options="header"]
126
+
[cols="1,3",options="header"]
92
127
|===
93
128
94
129
|Category
@@ -126,42 +161,43 @@ CRI-O has the following default list of capabilities that are allowed for each c
126
161
The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities or removing some of the default behaviors. Use the `allowedCapabilities`, `defaultAddCapabilities`, and `requiredDropCapabilities` parameters to control such requests from the pods and to dictate which capabilities can be requested, which ones must be added to each container, and which ones must be forbidden.
127
162
128
163
[id="authorization-SCC-strategies_{context}"]
129
-
== SCC Strategies
164
+
== Security context constraints strategies
130
165
131
166
.RunAsUser
132
167
133
-
. `MustRunAs` - Requires a `runAsUser` to be configured. Uses the configured
168
+
* `MustRunAs` - Requires a `runAsUser` to be configured. Uses the configured
134
169
`runAsUser` as the default. Validates against the configured `runAsUser`.
135
-
. `MustRunAsRange` - Requires minimum and maximum values to be defined if not
170
+
* `MustRunAsRange` - Requires minimum and maximum values to be defined if not
136
171
using pre-allocated values. Uses the minimum as the default. Validates against
137
172
the entire allowable range.
138
-
. `MustRunAsNonRoot` - Requires that the pod be submitted with a non-zero
173
+
* `MustRunAsNonRoot` - Requires that the pod be submitted with a non-zero
139
174
`runAsUser` or have the `USER` directive defined in the image. No default
140
175
provided.
141
-
. `RunAsAny` - No default provided. Allows any `runAsUser` to be specified.
176
+
* `RunAsAny` - No default provided. Allows any `runAsUser` to be specified.
142
177
143
178
.SELinuxContext
144
179
145
-
. `MustRunAs` - Requires `seLinuxOptions` to be configured if not using
180
+
* `MustRunAs` - Requires `seLinuxOptions` to be configured if not using
146
181
pre-allocated values. Uses `seLinuxOptions` as the default. Validates against
147
182
`seLinuxOptions`.
148
-
. `RunAsAny` - No default provided. Allows any `seLinuxOptions` to be
183
+
* `RunAsAny` - No default provided. Allows any `seLinuxOptions` to be
149
184
specified.
150
185
151
186
.SupplementalGroups
152
187
153
-
. `MustRunAs` - Requires at least one range to be specified if not using
188
+
* `MustRunAs` - Requires at least one range to be specified if not using
154
189
pre-allocated values. Uses the minimum value of the first range as the default.
155
190
Validates against all ranges.
156
-
. `RunAsAny` - No default provided. Allows any `supplementalGroups` to be
191
+
* `RunAsAny` - No default provided. Allows any `supplementalGroups` to be
157
192
specified.
158
193
159
194
.FSGroup
160
195
161
-
. `MustRunAs` - Requires at least one range to be specified if not using
196
+
* `MustRunAs` - Requires at least one range to be specified if not using
162
197
pre-allocated values. Uses the minimum value of the first range as the default.
163
198
Validates against the first ID in the first range.
164
-
. `RunAsAny` - No default provided. Allows any `fsGroup` ID to be specified.
199
+
* `RunAsAny` - No default provided. Allows any `fsGroup` ID to be specified.
You must have `cluster-admin` privileges to manage SCCs.
14
14
====
15
15
16
-
[IMPORTANT]
17
-
====
18
-
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.
0 commit comments