Skip to content

Commit f5a0585

Browse files
author
Michael Burke
committed
Nodes 4.17 User Namespace Work
1 parent 91a09ed commit f5a0585

File tree

3 files changed

+243
-0
lines changed

3 files changed

+243
-0
lines changed

‎_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2522,6 +2522,8 @@ Topics:
25222522
File: run-once-duration-override-install
25232523
- Name: Uninstalling the Run Once Duration Override Operator
25242524
File: run-once-duration-override-uninstall
2525+
- Name: Running pods in Linux user namespaces
2526+
File: nodes-pods-user-namespaces
25252527
- Name: Automatically scaling pods with the Custom Metrics Autoscaler Operator
25262528
Dir: cma
25272529
Distros: openshift-enterprise,openshift-origin

‎modules/nodes-pods-user-namespaces-configuring.adoc

Lines changed: 215 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,215 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * nodes/pods/nodes-pods-user-namespaces.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="nodes-pods-user-namespaces-configuring_{context}"]
7+
= Configuring Linux user namespace support
8+
9+
10+
.Prerequisites
11+
12+
* You enabled the required Technology Preview features for your cluster by editing the `FeatureGate` CR named `cluster`:
13+
+
14+
[source,terminal]
15+
----
16+
$ oc edit featuregate cluster
17+
----
18+
+
19+
.Example `FeatureGate` CR
20+
[source,yaml]
21+
----
22+
apiVersion: config.openshift.io/v1
23+
kind: FeatureGate
24+
metadata:
25+
name: cluster
26+
spec:
27+
featureSet: TechPreviewNoUpgrade <1>
28+
----
29+
<1> Enables the required `UserNamespacesSupport` and `ProcMountType` features.
30+
+
31+
[WARNING]
32+
====
33+
Enabling the `TechPreviewNoUpgrade` feature set on your cluster cannot be undone and prevents minor version updates. This feature set allows you to enable these Technology Preview features on test clusters, where you can fully test them. Do not enable this feature set on production clusters.
34+
====
35+
+
36+
After you save the changes, new machine configs are created, the machine config pools are updated, and scheduling on each node is disabled while the change is being applied.
37+
38+
* You enabled the crun container runtime on the worker nodes. crun is currently the only released OCI runtime with support for user namespaces.
39+
+
40+
[source,yaml]
41+
----
42+
apiVersion: machineconfiguration.openshift.io/v1
43+
kind: ContainerRuntimeConfig
44+
metadata:
45+
name: enable-crun-worker
46+
spec:
47+
machineConfigPoolSelector:
48+
matchLabels:
49+
pools.operator.machineconfiguration.openshift.io/worker: "" <1>
50+
containerRuntimeConfig:
51+
defaultRuntime: crun <2>
52+
----
53+
<1> Specifies the machine config pool label.
54+
<2> Specifies the container runtime to deploy.
55+
56+
.Procedure
57+
58+
. Edit the default user ID (UID) and group ID (GID) range of the {product-title} namespace where your pod is deployed by running the following command:
59+
+
60+
[source,terminal]
61+
----
62+
$ oc edit ns/<namespace_name>
63+
----
64+
+
65+
.Example namespace
66+
[source,yaml]
67+
----
68+
apiVersion: v1
69+
kind: Namespace
70+
metadata:
71+
annotations:
72+
openshift.io/description: ""
73+
openshift.io/display-name: ""
74+
openshift.io/requester: system:admin
75+
openshift.io/sa.scc.mcs: s0:c27,c24
76+
openshift.io/sa.scc.supplemental-groups: 1024/10000 <1>
77+
openshift.io/sa.scc.uid-range: 1024/10000 <2>
78+
# ...
79+
name: userns
80+
# ...
81+
----
82+
<1> Edit the default GID to match the value you specified in the pod spec. The range for a Linux user namespace must be lower than 65,535. The default is `1000000000/10000`.
83+
<2> Edit the default UID to match the value you specified in the pod spec. The range for a Linux user namespace must be lower than 65,535. The default is `1000000000/10000`.
84+
+
85+
[NOTE]
86+
====
87+
The range 1024/10000 means 10,000 values starting with ID 1024, so it specifies the range of IDs from 1024 to 11,023.
88+
====
89+
90+
. Enable the use of Linux user namespaces by creating a pod configured to run with a `restricted` profile and with the `hostUsers` parameter set to `false`.
91+
92+
.. Create a YAML file similar to the following:
93+
+
94+
.Example pod specification
95+
[source,yaml]
96+
----
97+
apiVersion: v1
98+
kind: Pod
99+
metadata:
100+
name: userns-pod
101+
102+
# ...
103+
104+
spec:
105+
containers:
106+
- name: userns-container
107+
image: registry.access.redhat.com/ubi9
108+
command: ["sleep", "1000"]
109+
securityContext:
110+
capabilities:
111+
drop: ["ALL"]
112+
allowPrivilegeEscalation: false <1>
113+
runAsNonRoot: true <2>
114+
seccompProfile:
115+
type: RuntimeDefault
116+
runAsUser: 1024 <3>
117+
runAsGroup: 1024 <4>
118+
hostUsers: false <5>
119+
120+
# ...
121+
----
122+
<1> Specifies that a pod cannot request privilege escalation. This is required for the `restricted-v2` security context constraints (SCC).
123+
<2> Specifies that the container will run with a user with any UID other than 0.
124+
<3> Specifies the UID the container is run with.
125+
<4> Specifies which primary GID the containers is run with.
126+
<5> Requests that the pod is to be run in a user namespace. If `true`, the pod runs in the host user namespace. If `false`, the pod runs in a new user namespace that is created for the pod. The default is `true`.
127+
128+
.. Create the pod by running the following command:
129+
+
130+
----
131+
$ oc create -f <file_name>.yaml
132+
----
133+
134+
.Verification
135+
136+
. Check the pod user and group IDs being used in the pod container you created. The pod is inside the Linux user namespace.
137+
138+
.. Start a shell session with the container in your pod:
139+
+
140+
[source,terminal]
141+
----
142+
$ oc rsh -c <container_name> pod/<pod_name>
143+
----
144+
+
145+
.Example command
146+
[source,terminal]
147+
----
148+
$ oc rsh -c userns-container_name pod/userns-pod
149+
----
150+
151+
.. Display the user and group IDs being used inside the container:
152+
+
153+
[source,terminal]
154+
----
155+
sh-5.1$ id
156+
----
157+
+
158+
.Example output
159+
[source,terminal]
160+
----
161+
uid=1024(1024) gid=1024(1024) groups=1024(1024)
162+
----
163+
164+
.. Display the user ID being used in the container user namespace:
165+
+
166+
[source,terminal]
167+
----
168+
sh-5.1$ lsns -t user
169+
----
170+
+
171+
.Example output
172+
[source,terminal]
173+
----
174+
NS TYPE NPROCS PID USER COMMAND
175+
4026532447 user 3 1 1024 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000 <1>
176+
----
177+
<1> The UID for the process is `1024`, the same as you set in the pod spec.
178+
179+
. Check the pod user ID being used on the node where the pod was created. The node is outside of the Linux user namespace. This user ID should be different from the UID being used in the container.
180+
181+
.. Start a debug session for that node:
182+
+
183+
[source,terminal]
184+
----
185+
$ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9
186+
----
187+
+
188+
.Example command
189+
[source,terminal]
190+
----
191+
$ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9
192+
----
193+
194+
.. Set `/host` as the root directory within the debug shell:
195+
+
196+
[source,terminal]
197+
----
198+
sh-5.1# chroot /host
199+
----
200+
201+
.. Display the user ID being used in the node user namespace:
202+
+
203+
[source,terminal]
204+
----
205+
sh-5.1# lsns -t user
206+
----
207+
+
208+
.Example command
209+
[source,terminal]
210+
----
211+
NS TYPE NPROCS PID USER COMMAND
212+
4026531837 user 233 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 28
213+
4026532447 user 1 4767 2908816384 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000 <1>
214+
----
215+
<1> The UID for the process is `2908816384`, which is different from what you set in the pod spec.

‎nodes/pods/nodes-pods-user-namespaces.adoc

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
:_mod-docs-content-type: ASSEMBLY
2+
:context: nodes-pods-user-namespaces
3+
[id="nodes-pods-user-namespaces"]
4+
= Running pods in Linux user namespaces
5+
include::_attributes/common-attributes.adoc[]
6+
7+
toc::[]
8+
9+
Linux user namespaces allow administrators to isolate the container user and group identifiers (UIDs and GIDs) so that a container can have a different set of permissions in the user namespace than on the host system where it is running. This allows containers to run processes with full privileges inside the user namespace, but the processes can be unprivileged for operations on the host machine.
10+
11+
By default, a container runs in the host system's root user namespace. Running a container in the host user namespace can be useful when the container needs a feature that is available only in that user namespace. However, it introduces security concerns, such as the possibility of container breakouts, in which a process inside a container breaks out onto the host where the process can access or modify files on the host or in other containers.
12+
13+
Running containers in individual user namespaces can mitigate container breakouts and several other vulnerabilities that a compromised container can pose to other pods and the node itself.
14+
15+
You can configure Linux user namespace use by setting the `hostUsers` parameter to `false` in the pod spec, as shown in the following procedure.
16+
17+
:FeatureName: Support for Linux user namespaces
18+
include::snippets/technology-preview.adoc[]
19+
20+
// The following include statements pull in the module files that comprise
21+
// the assembly. Include any combination of concept, procedure, or reference
22+
// modules required to cover the user story. You can also include other
23+
// assemblies.
24+
25+
include::modules/nodes-pods-user-namespaces-configuring.adoc[leveloffset=+1]
26+

0 commit comments

Comments
 (0)