@@ -710,7 +710,27 @@ To assign SELinux labels, the SELinux security module must be loaded on the host
710
710
-->
711
711
# ## 高效重打 SELinux 卷标签
712
712
713
- {{< feature-state for_k8s_version="v1.27" state="beta" >}}
713
+ {{< feature-state feature_gate_name="SELinuxMountReadWriteOncePod" >}}
714
+
715
+ {{< note >}}
716
+ <!--
717
+ Kubernetes v1.27 introduced an early limited form of this behavior that was only applicable
718
+ to volumes (and PersistentVolumeClaims) using the `ReadWriteOncePod` access mode.
719
+ -->
720
+ Kubernetes v1.27 引入了此行为的早期受限形式,仅适用于使用 `ReadWriteOncePod`
721
+ 访问模式的卷(和 PersistentVolumeClaim)。
722
+
723
+ <!--
724
+ As an alpha feature, you can enable the `SELinuxMount`
725
+ [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to widen that
726
+ performance improvement to other kinds of PersistentVolumeClaims, as explained in detail
727
+ below.
728
+ -->
729
+ 作为一项 Alpha 特性,你可以启用 `SELinuxMount`
730
+ [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/),
731
+ 将性能改进扩展到其他类型的 PersistentVolumeClaim,如下文详细解释。
732
+ {{< /note >}}
733
+
714
734
715
735
<!--
716
736
By default, the container runtime recursively assigns SELinux label to all
@@ -734,9 +754,14 @@ To benefit from this speedup, all these conditions must be met:
734
754
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
735
755
736
756
<!--
737
- * Pod must use PersistentVolumeClaim with `accessModes: ["ReadWriteOncePod"]`.
757
+ * Pod must use PersistentVolumeClaim with applicable `accessModes` and [feature gates](/docs/reference/command-line-tools-reference/feature-gates/):
758
+ * Either the volume has `accessModes: ["ReadWriteOncePod"]`, and feature gate `SELinuxMountReadWriteOncePod` is enabled.
759
+ * Or the volume can use any other access modes and both feature gates `SELinuxMountReadWriteOncePod` and `SELinuxMount` must be enabled.
738
760
-->
739
- * Pod 必须以 `accessModes: ["ReadWriteOncePod"]` 模式使用 PersistentVolumeClaim。
761
+ * Pod 必须使用带有对应的 `accessModes` 和[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
762
+ 的 PersistentVolumeClaim。
763
+ * 卷具有 `accessModes: ["ReadWriteOncePod"]`,并且 `SELinuxMountReadWriteOncePod` 特性门控已启用。
764
+ * 或者卷可以使用任何其他访问模式,并且必须启用 `SELinuxMountReadWriteOncePod` 和 `SELinuxMount` 特性门控。
740
765
741
766
<!--
742
767
* Pod (or all its Containers that use the PersistentVolumeClaim) must
@@ -774,19 +799,86 @@ The more files and directories in the volume, the longer that relabelling takes.
774
799
容器运行时为卷中的所有节点(文件和目录)递归地修改 SELinux 标签。
775
800
卷中的文件和目录越多,重打标签需要耗费的时间就越长。
776
801
802
+ <!--
803
+ # # Managing access to the `/proc` filesystem {#proc-access}
804
+ -->
805
+ # # 管理对 `/proc` 文件系统的访问 {#proc-access}
806
+
807
+ {{< feature-state feature_gate_name="ProcMountType" >}}
808
+
809
+ <!--
810
+ For runtimes that follow the OCI runtime specification, containers default to running in a mode where
811
+ there are multiple paths that are both masked and read-only.
812
+ The result of this is the container has these paths present inside the container's mount namespace, and they can function similarly to if
813
+ the container was an isolated host, but the container process cannot write to
814
+ them. The list of masked and read-only paths are as follows :
815
+ -->
816
+ 对于遵循 OCI 运行时规范的运行时,容器默认运行模式下,存在多个被屏蔽且只读的路径。
817
+ 这样做的结果是在容器的 mount 命名空间内会存在这些路径,并且这些路径的工作方式与容器是隔离主机时类似,
818
+ 但容器进程无法写入它们。
819
+ 被屏蔽的和只读的路径列表如下:
820
+
821
+ <!--
822
+ - Masked Paths :
823
+ -->
824
+ - 被屏蔽的路径:
825
+
826
+ - ` /proc/asound`
827
+ - ` /proc/acpi`
828
+ - ` /proc/kcore`
829
+ - ` /proc/keys`
830
+ - ` /proc/latency_stats`
831
+ - ` /proc/timer_list`
832
+ - ` /proc/timer_stats`
833
+ - ` /proc/sched_debug`
834
+ - ` /proc/scsi`
835
+ - ` /sys/firmware`
836
+
837
+ <!--
838
+ - Read-Only Paths :
839
+ -->
840
+ - 只读的路径:
841
+
842
+ - ` /proc/bus`
843
+ - ` /proc/fs`
844
+ - ` /proc/irq`
845
+ - ` /proc/sys`
846
+ - ` /proc/sysrq-trigger`
847
+
848
+ <!--
849
+ For some Pods, you might want to bypass that default masking of paths.
850
+ The most common context for wanting this is if you are trying to run containers within
851
+ a Kubernetes container (within a pod).
852
+ -->
853
+ 对于某些 Pod,你可能希望绕过默认的路径屏蔽。
854
+ 最常见的情况是你尝试在 Kubernetes 容器内(在 Pod 内)运行容器。
855
+
856
+ <!--
857
+ The `securityContext` field `procMount` allows a user to request a container's `/proc`
858
+ be `Unmasked`, or be mounted as read-write by the container process. This also
859
+ applies to `/sys/firmware` which is not in `/proc`.
860
+ -->
861
+ ` securityContext` 字段 `procMount` 允许用户请求容器的 `/proc` 为 `Unmasked`,
862
+ 或者由容器进程以读写方式挂载。这一设置也适用于不在 `/proc` 内的 `/sys/firmware` 路径。
863
+
864
+ ` ` ` yaml
865
+ ...
866
+ securityContext:
867
+ procMount: Unmasked
868
+ ` ` `
869
+
777
870
{{< note >}}
778
- <!-- remove after Kubernetes v1.30 is released -->
779
- <!--
780
- If you are running Kubernetes v1.25, refer to the v1.25 version of this task page :
781
- [Configure a Security Context for a Pod or Container](https://v1-25.docs.kubernetes.io/docs/tasks/configure-pod-container/security-context/) (v1.25).
782
- There is an important note in that documentation about a situation where the kubelet
783
- can lose track of volume labels after restart. This deficiency has been fixed
784
- in Kubernetes 1.26.
785
- -->
786
- 如果你的 Kubernetes 版本是 v1.25,请参阅此任务页面的 v1.25 版本:
787
- [为 Pod 或 Container 配置安全上下文](https://v1-25.docs.kubernetes.io/docs/tasks/configure-pod-container/security-context/)(v1.25)。
788
- 该文档中有一个重要的说明:kubelet 在重启后会丢失对卷标签的追踪记录。
789
- 这个缺陷已经在 Kubernetes 1.26 中修复。
871
+ <!--
872
+ Setting `procMount` to Unmasked requires the `spec.hostUsers` value in the pod
873
+ spec to be `false`. In other words : a container that wishes to have an Unmasked
874
+ ` /proc` or unmasked `/sys` must also be in a
875
+ [user namespace](/docs/concepts/workloads/pods/user-namespaces/).
876
+ Kubernetes v1.12 to v1.29 did not enforce that requirement.
877
+ -->
878
+ 将 `procMount` 设置为 Unmasked 需要将 Pod 规约中的 `spec.hostUsers`
879
+ 的值设置为 `false`。换句话说:希望使用未被屏蔽的 `/proc` 或 `/sys`
880
+ 路径的容器也必须位于 [user 命名空间](/zh-cn/docs/concepts/workloads/pods/user-namespaces/)中。
881
+ Kubernetes v1.12 到 v1.29 没有强制执行该要求。
790
882
{{< /note >}}
791
883
792
884
<!--
@@ -862,6 +954,10 @@ kubectl delete pod security-context-demo-4
862
954
* For more information about security mechanisms in Linux, see
863
955
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
864
956
(Note : Some information is out of date)
957
+ * Read about [User Namespaces](/docs/concepts/workloads/pods/user-namespaces/)
958
+ for Linux pods.
959
+ * [Masked Paths in the OCI Runtime
960
+ Specification](https://github.com/opencontainers/runtime-spec/blob/f66aad47309/config-linux.md#masked-paths)
865
961
-->
866
962
* [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) API 定义
867
963
* [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) API 定义
@@ -872,3 +968,5 @@ kubectl delete pod security-context-demo-4
872
968
* [AllowPrivilegeEscalation 的设计文档(英文)](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/no-new-privs.md)
873
969
* 关于在 Linux 系统中的安全机制的更多信息,可参阅
874
970
[Linux 内核安全性能力概述](https://www.linux.com/learn/overview-linux-kernel-security-features)(注意:部分信息已过时)。
971
+ * 了解 Linux Pod 的 [user 命名空间](/zh-cn/docs/concepts/workloads/pods/user-namespaces/)。
972
+ * [OCI 运行时规范中的被屏蔽的路径](https://github.com/opencontainers/runtime-spec/blob/f66aad47309/config-linux.md#masked-paths)
0 commit comments