Skip to content

Commit 246374a

Browse files
committed
blog: Add blogpost for user namespaces in 1.25
Signed-off-by: Rodrigo Campos <[email protected]> Signed-off-by: Giuseppe Scrivano <[email protected]>
1 parent 9c5b45d commit 246374a

File tree

1 file changed

+80
-0
lines changed
  • content/en/blog/_posts/2022-10-03-add-userns-alpha

1 file changed

+80
-0
lines changed
Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
---
2+
layout: blog
3+
title: "Kubernetes 1.25: alpha support for running Pods with user namespaces"
4+
date: 2022-10-03
5+
slug: userns-alpha
6+
---
7+
8+
**Authors:** Rodrigo Campos (Microsoft), Giuseppe Scrivano (Red Hat)
9+
10+
Kubernetes v1.25 introduces the support for user namespaces.
11+
12+
This is a major improvement for running secure workloads in
13+
Kubernetes. Each pod will have access only to a limited subset of the
14+
available UIDs and GIDs on the system, thus adding a new security
15+
layer to protect from other pods running on the same system.
16+
17+
## How does it work?
18+
A process running on Linux can use up to 4294967296 different UIDs and
19+
GIDs.
20+
21+
User namespaces is a Linux feature that allows mapping a set of users
22+
in the container to different users in the host, thus restricting what
23+
IDs a process can effectively use.
24+
Furthermore, the capabilities granted in a new user namespace do not
25+
apply in the host initial namespaces.
26+
27+
## Why is it important?
28+
There are mainly two reasons why user namespaces are important:
29+
30+
- improve security since they restrict the IDs a pod can use, so each
31+
pod can run in its own separate environment with unique IDs.
32+
33+
- enable running workloads as root in a safer manner.
34+
35+
In a user namespace we can map the root user inside the pod to a
36+
non-zero ID outside the container, containers believe in running as
37+
root while they are a regular unprivileged ID from the host point of
38+
view.
39+
40+
The process can keep capabilities that are usually restricted to
41+
privileged pods and do it in a safe way since the capabilities granted
42+
in a new user namespace do not apply in the host initial namespaces.
43+
44+
## How do I enable user namespaces?
45+
At the moment, user namespaces support is opt-in, so you must enable
46+
it for a pod setting `hostUsers` to `false` under the pod spec stanza:
47+
```
48+
apiVersion: v1
49+
kind: Pod
50+
spec:
51+
hostUsers: false
52+
containers:
53+
- name: nginx
54+
image: docker.io/nginx
55+
```
56+
57+
The feature is behind a feature gate, so make sure to enable
58+
the `UserNamespacesStatelessPodsSupport` gate before you can use
59+
the new feature.
60+
61+
The runtime must also support user namespaces:
62+
63+
* containerd: support is planned for the 1.7 release. See containerd
64+
issue [#7063][containerd-userns-issue] for more details.
65+
66+
* CRI-O: v1.25 has support for user namespaces.
67+
68+
Support for this in `cri-dockerd` is [not planned][CRI-dockerd-issue] yet.
69+
70+
[CRI-dockerd-issue]: https://github.com/Mirantis/cri-dockerd/issues/74
71+
[containerd-userns-issue]: https://github.com/containerd/containerd/issues/7063
72+
73+
## How do I get involved?
74+
You can reach SIG Node by several means:
75+
- Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node)
76+
- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node)
77+
- [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/sig%2Fnode)
78+
79+
You can also contact us directly:
80+
- GitHub / Slack: @rata @giuseppe

0 commit comments

Comments
 (0)