From 330279ad17e47d8aedba45f3220812edf17f9030 Mon Sep 17 00:00:00 2001
From: xin gu <418294249@qq.com>
Date: Sat, 16 Dec 2023 22:23:39 +0800
Subject: [PATCH] sync user-namespaces

---
 .../workloads/pods/user-namespaces.md         | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/content/zh-cn/docs/concepts/workloads/pods/user-namespaces.md b/content/zh-cn/docs/concepts/workloads/pods/user-namespaces.md
index 97920977f2032..cc288fc5d5f15 100644
--- a/content/zh-cn/docs/concepts/workloads/pods/user-namespaces.md
+++ b/content/zh-cn/docs/concepts/workloads/pods/user-namespaces.md
@@ -279,6 +279,58 @@ Pod 的 UID/GID 不会与主机的文件所有者/组相匹配。
 
 [CVE-2021-25741]: https://github.com/kubernetes/kubernetes/issues/104980
 
+<!--
+## Integration with Pod security admission checks
+
+{{< feature-state state="alpha" for_k8s_version="v1.29" >}}
+
+For Linux Pods that enable user namespaces, Kubernetes relaxes the application of
+[Pod Security Standards](/docs/concepts/security/pod-security-standards) in a controlled way.
+This behavior can be controlled by the [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`UserNamespacesPodSecurityStandards`, which allows an early opt-in for end
+users. Admins have to ensure that user namespaces are enabled by all nodes
+within the cluster if using the feature gate.
+
+If you enable the associated feature gate and create a Pod that uses user
+namespaces, the following fields won't be constrained even in contexts that enforce the
+_Baseline_ or _Restricted_ pod security standard. This behavior does not
+present a security concern because `root` inside a Pod with user namespaces
+actually refers to the user inside the container, that is never mapped to a
+privileged user on the host. Here's the list of fields that are **not** checks for Pods in those
+circumstances:
+
+- `spec.securityContext.runAsNonRoot`
+- `spec.containers[*].securityContext.runAsNonRoot`
+- `spec.initContainers[*].securityContext.runAsNonRoot`
+- `spec.ephemeralContainers[*].securityContext.runAsNonRoot`
+- `spec.securityContext.runAsUser`
+- `spec.containers[*].securityContext.runAsUser`
+- `spec.initContainers[*].securityContext.runAsUser`
+- `spec.ephemeralContainers[*].securityContext.runAsUser`
+-->
+## 集成Pod安全准入检查 {#integration-with-pod-security-admission-checks}
+
+针对那些启用了用户命名空间的 Linux Pod，Kubernetes 有选择地放松了对 Pod 安全标准的应用，
+以一种受控的方式实现。这一行为可以通过特性门控 `UserNamespacesPodSecurityStandards` 来管理，
+该特性门控允许最终用户提前加入此项功能。如果要使用这个特性门控，
+管理员必须确保集群中的所有节点都启用了用户命名空间。
+
+如果你启用了相关的特性门控并创建了一个使用用户命名空间的 Pod，
+即使在强制执行 _Baseline_ 或 _Restricted_ Pod 安全标准的上下文中，
+以下字段也不会受到限制。这种行为不会引起安全问题，
+因为在具有用户命名空间的 Pod 中的 `root` 实际上指的是容器内的用户，
+这个用户从不映射到宿主机上的特权用户。以下是在这些情况下**不**进行检查的 Pod 字段列表：
+
+- `spec.securityContext.runAsNonRoot`
+- `spec.containers[*].securityContext.runAsNonRoot`
+- `spec.initContainers[*].securityContext.runAsNonRoot`
+- `spec.ephemeralContainers[*].securityContext.runAsNonRoot`
+- `spec.securityContext.runAsUser`
+- `spec.containers[*].securityContext.runAsUser`
+- `spec.initContainers[*].securityContext.runAsUser`
+- `spec.ephemeralContainers[*].securityContext.runAsUser`
+
 <!--
 ## Limitations
 -->