Merge pull request #36459 from Michelle951/michelle05

[zh] sync security-context.md

Author: k8s-ci-robot

content/zh-cn/docs/tasks/configure-pod-container/security-context.md

@@ -154,7 +154,7 @@ The output shows that the processes are running as user 1000, which is the value
 -->
 输出显示进程以用户 1000 运行，即 `runAsUser` 所设置的值：
 
-```shell
+```none
 PID   USER     TIME  COMMAND
     1 1000      0:00 sleep 1h
     6 1000      0:00 sh
@@ -177,7 +177,7 @@ the value of `fsGroup`.
 -->
 输出显示 `/data/demo` 目录的组 ID 为 2000，即 `fsGroup` 的设置值：
 
-```shell
+```none
 drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo
 ```
 
@@ -205,7 +205,7 @@ The output shows that `testfile` has group ID 2000, which is the value of `fsGro
 -->
 输出显示 `testfile` 的组 ID 为 2000，也就是 `fsGroup` 所设置的值：
 
-```shell
+```none
 -rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile
 ```
 
@@ -498,7 +498,7 @@ The output shows the process IDs (PIDs) for the Container:
 -->
 输出显示容器中进程 ID（PIDs）：
 
-```shell
+```
 USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
 root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
 root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js
@@ -582,7 +582,7 @@ The output shows capabilities bitmap for the process:
 -->
 输出显示的是进程的权能位图：
 
-```shell
+```
 ...
 CapPrm:	00000000aa0435fb
 CapEff:	00000000aa0435fb
@@ -612,12 +612,12 @@ for definitions of the capability constants.
 
 <!--
 Linux capability constants have the form `CAP_XXX`.
-But when you list capabilities in your Container manifest, you must
+But when you list capabilities in your container manifest, you must
 omit the `CAP_` portion of the constant.
 For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
 -->
 {{< note >}}
-Linux 权能常数定义的形式为 `CAP_XXX`。但是你在 Container 清单中列举权能时，
+Linux 权能常数定义的形式为 `CAP_XXX`。但是你在 container 清单中列举权能时，
 要将权能名称中的 `CAP_` 部分去掉。例如，要添加 `CAP_SYS_TIME`，
 可在权能列表中添加 `SYS_TIME`。
 {{< /note >}}
@@ -633,7 +633,7 @@ in the `securityContext` section of your Pod or Container manifest. The
 Valid options for `type` include `RuntimeDefault`, `Unconfined`, and
 `Localhost`. `localhostProfile` must only be set if `type: Localhost`. It
 indicates the path of the pre-configured profile on the node, relative to the
-kubelet's configured Seccomp profile location (configured with the `-root-dir`
+kubelet's configured Seccomp profile location (configured with the `--root-dir`
 flag).
 
 Here is an example that sets the Seccomp profile to the node's container runtime
@@ -706,6 +706,83 @@ To assign SELinux labels, the SELinux security module must be loaded on the host
 要指定 SELinux，需要在宿主操作系统中装载 SELinux 安全性模块。
 {{< /note >}}
 
+<!--
+### Efficient SELinux volume relabeling
+-->
+### 高效重打 SELinux 卷标签
+
+{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
+
+<!--
+By default, the contrainer runtime recursively assigns SELinux label to all
+files on all Pod volumes. To speed up this process, Kubernetes can change the
+SELinux label of a volume instantly by using a mount option
+`-o context=<label>`.
+-->
+默认情况下，容器运行时递归地将 SELinux 标签赋予所有 Pod 卷上的所有文件。
+为了加快该过程，Kubernetes 使用挂载可选项 `-o context=<label>` 可以立即改变卷的 SELinux 标签。
+
+<!--
+To benefit from this speedup, all these conditions must be met:
+-->
+要使用这项加速功能，必须满足下列条件：
+
+<!--
+* Alpha feature gates `ReadWriteOncePod` and `SELinuxMountReadWriteOncePod` must
+  be enabled.
+-->
+* 必须启用 Alpha 特性门控 `ReadWriteOncePod` 和 `SELinuxMountReadWriteOncePod`。
+
+<!--
+* Pod must use PersistentVolumeClaim with `accessModes: ["ReadWriteOncePod"]`.
+-->
+* Pod 必须以 `accessModes: ["ReadWriteOncePod"]` 模式使用 PersistentVolumeClaim。
+
+<!--
+* Pod (or all its Containers that use the PersistentVolumeClaim) must
+  have `seLinuxOptions` set.
+-->
+* Pod（或其中使用 PersistentVolumeClaim 的所有容器）必须设置 `seLinuxOptions`。
+
+<!--
+* The corresponding PersistentVolume must be either a volume that uses a
+  {{< glossary_tooltip text="CSI" term_id="csi" >}} driver, or a volume that uses the
+  legacy `iscsi` volume type.
+  * If you use a volume backed by a CSI driver, that CSI driver must announce that it
+    supports mounting with `-o context` by setting `spec.seLinuxMount: true` in
+    its CSIDriver instance.
+-->
+* 对应的 PersistentVolume 必须是使用 {< glossary_tooltip text="CSI" term_id="csi" >}}
+  驱动程序的卷，或者是传统的 `iscsi` 卷类型的卷。
+  * 如果使用基于 CSI 驱动程序的卷，CSI 驱动程序必须能够通过在 CSIDriver
+    实例中设置 `spec.seLinuxMount: true` 以支持 `-o context` 挂载。
+
+<!--
+For any other volume types, SELinux relabelling happens another way: the container
+runtime  recursively changes the SELinux label for all inodes (files and directories)
+in the volume.
+The more files and directories in the volume, the longer that relabelling takes.
+-->
+对于所有其他卷类型，重打 SELinux 标签的方式有所不同：
+容器运行时为卷中的所有节点（文件和目录）递归地修改 SELinux 标签。
+卷中的文件和目录越多，重打标签需要耗费的时间就越长。
+
+{{< note >}}
+<!--
+In Kubernetes 1.25, the kubelet loses track of volume labels after restart. In
+other words, then kubelet may refuse to start Pods with errors similar to  "conflicting
+SELinux labels of volume", while there are no conflicting labels in Pods. Make sure
+nodes are
+[fully drained](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)
+before restarting kubelet.
+-->
+在 Kubernetes 1.25 中，kubelet 在重启后会丢失对卷标签的追踪记录。
+换言之，kubelet 可能会拒绝启动 Pod，原因类似于 “conflicting
+SELinux labels of volume”，
+但实际上 Pod 中并没有冲突的标签。在重启 kubelet
+之前确保节点已被[完全腾空](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)。
+{{< /note >}}
+
 <!--
 ## Discussion
 
@@ -773,19 +850,19 @@ kubectl delete pod security-context-demo-4
 * [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 * [Security Contexts design document](https://git.k8s.io/design-proposals-archive/auth/security_context.md)
 * [Ownership Management design document](https://git.k8s.io/design-proposals-archive/storage/volume-ownership-management.md)
-* [Pod Security Policies](/docs/concepts/security/pod-security-policy/)
+* [PodSecurity Admission](/docs/concepts/security/pod-security-admission/)
 * [AllowPrivilegeEscalation design
   document](https://git.k8s.io/design-proposals-archive/auth/no-new-privs.md)
 * For more information about security mechanisms in Linux, see
-  [Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
+  [Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) (Note: Some information is out of date)
 -->
 * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) API 定义
 * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) API 定义
 * [使用最新的安全性增强来调优 Docker（英文）](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 * [安全上下文的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/security_context.md)
 * [属主管理的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-ownership-management.md)
-* [Pod 安全策略](/zh-cn/docs/concepts/security/pod-security-policy/)
+* [Pod 安全性准入](zh-cn/docs/concepts/security/pod-security-admission/)
 * [AllowPrivilegeEscalation 的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/no-new-privs.md)
 * 关于在 Linux 系统中的安全机制的更多信息，可参阅
-  [Linux 内核安全性能力概述](https://www.linux.com/learn/overview-linux-kernel-security-features)。
+  [Linux 内核安全性能力概述](https://www.linux.com/learn/overview-linux-kernel-security-features)（注意：部分信息已过时）。