From 9c0431c7dd5255865c138ef72205a9e828efe99a Mon Sep 17 00:00:00 2001
From: michelle951 <1436918299@qq.com>
Date: Wed, 31 Aug 2022 23:08:10 +0800
Subject: [PATCH] [zh] sync security-context.md
---
.../security-context.md | 101 +++++++++++++++---
1 file changed, 89 insertions(+), 12 deletions(-)
diff --git a/content/zh-cn/docs/tasks/configure-pod-container/security-context.md b/content/zh-cn/docs/tasks/configure-pod-container/security-context.md
index 19a51afb15..bbf7e9b40a 100644
--- a/content/zh-cn/docs/tasks/configure-pod-container/security-context.md
+++ b/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)（注意：部分信息已过时）。