[zh-cn] sync pod-security-standards security-checklist service-accounts system-traces

Signed-off-by: xin.li <[email protected]>

Author: my-git9

content/zh-cn/docs/concepts/cluster-administration/system-traces.md

@@ -37,9 +37,15 @@ Kubernetes 组件基于 gRPC 导出器的
 
 <!-- 
 ## Trace Collection
+
+Kubernetes components have built-in gRPC exporters for OTLP to export traces, either with an OpenTelemetry Collector, 
+or without an OpenTelemetry Collector.
 -->
 ## 追踪信息的收集 {#trace-collection}
 
+Kubernetes 组件具有内置的 gRPC 导出器，供 OTLP 导出追踪信息，可以使用 OpenTelemetry Collector，
+也可以不使用 OpenTelemetry Collector。
+
 <!-- 
 For a complete guide to collecting traces and using the collector, see
 [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/).
@@ -93,6 +99,30 @@ service:
       exporters: [logging]
 ```
 
+<!--
+To directly emit traces to a backend without utilizing a collector, 
+specify the endpoint field in the Kubernetes tracing configuration file with the desired trace backend address. 
+This method negates the need for a collector and simplifies the overall structure.
+-->
+要在不使用收集器的情况下直接将追踪信息发送到后端，请在 Kubernetes
+追踪配置文件中指定端点字段以及所需的追踪后端地址。
+该方法不需要收集器并简化了整体结构。
+
+<!--
+For trace backend header configuration, including authentication details, environment variables can be used with `OTEL_EXPORTER_OTLP_HEADERS`, 
+see [OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/).
+-->
+对于追踪后端标头配置，包括身份验证详细信息，环境变量可以与 `OTEL_EXPORTER_OTLP_HEADERS`
+一起使用，请参阅 [OTLP 导出器配置](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)。
+
+<!--
+Additionally, for trace resource attribute configuration such as Kubernetes cluster name, namespace, Pod name, etc., 
+environment variables can also be used with `OTEL_RESOURCE_ATTRIBUTES`, see [OTLP Kubernetes Resource](https://opentelemetry.io/docs/specs/semconv/resource/k8s/).
+-->
+另外，对于 Kubernetes 集群名称、命名空间、Pod 名称等追踪资源属性配置，
+环境变量也可以与 `OTEL_RESOURCE_ATTRIBUTES` 配合使用，请参见
+[OTLP Kubernetes 资源](https://opentelemetry.io/docs/specs/semconv/resource/k8s/)。
+
 <!-- 
 ## Component traces
 
@@ -260,5 +290,7 @@ there are no guarantees of backwards compatibility for tracing instrumentation.
 
 <!-- 
 * Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
+* Read about [OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)
 -->
 * 阅读 [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
+* 了解 [OTLP 导出器配置](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)

content/zh-cn/docs/concepts/security/pod-security-standards.md

@@ -3,7 +3,7 @@ title: Pod 安全性标准
 description: >
   详细了解 Pod 安全性标准（Pod Security Standards）中所定义的不同策略级别。
 content_type: concept
-weight: 10
+weight: 15
 ---
 <!--
 reviewers:
@@ -12,7 +12,7 @@ title: Pod Security Standards
 description: >
   A detailed look at the different policy levels defined in the Pod Security Standards.
 content_type: concept
-weight: 10
+weight: 15
 -->
 
 <!-- overview -->
@@ -214,8 +214,27 @@ fail validation.
 		<tr>
 			<td style="white-space: nowrap">AppArmor</td>
 			<td>
-				<p><!--On supported hosts, the <code>runtime/default</code> AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles.-->在受支持的主机上，默认使用 <code>runtime/default</code> AppArmor 配置。Baseline 策略应避免覆盖或者禁用默认策略，以及限制覆盖一些配置集合的权限。</p>
-				<p><strong><!--Restricted Fields-->限制的字段</strong></p>
+				<p>
+           <!--
+           On supported hosts, the <code>RuntimeDefault</code> AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles.
+           -->
+           在受支持的主机上，默认使用 <code>RuntimeDefault</code> AppArmor 配置。Baseline
+           策略应避免覆盖或者禁用默认策略，以及限制覆盖一些配置集合的权限。
+        </p>
+        <p><strong><!--Restricted Fields-->限制的字段</strong></p>
+         <ul>
+              <li><code>spec.securityContext.appArmorProfile.type</code></li>
+              <li><code>spec.containers[*].securityContext.appArmorProfile.type</code></li>
+              <li><code>spec.initContainers[*].securityContext.appArmorProfile.type</code></li>
+              <li><code>spec.ephemeralContainers[*].securityContext.appArmorProfile.type</code></li>
+        </ul>
+        <p><strong><!--Allowed Values-->准许的取值<</strong></p>
+        <ul>
+              <li>Undefined/nil</li>
+              <li><code>RuntimeDefault</code></li>
+              <li><code>Localhost</code></li>
+        </ul>
+        <hr />
 				<ul>
 					<li><code>metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]</code></li>
 				</ul>
@@ -230,7 +249,12 @@ fail validation.
 		<tr>
 			<td style="white-space: nowrap">SELinux</td>
 			<td>
-				<p><!--Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.-->设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。</p>
+				<p>
+           <!--
+           Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.
+           -->
+          设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。
+        </p>
 				<p><strong><!--Restricted Fields-->限制的字段</strong></p>
 				<ul>
 					<li><code>spec.securityContext.seLinuxOptions.type</code></li>
@@ -302,7 +326,13 @@ fail validation.
 		<tr>
 			<td style="white-space: nowrap">Sysctls</td>
 			<td>
-				<p><!--Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.-->Sysctls 可以禁用安全机制或影响宿主上所有容器，因此除了若干“安全”的子集之外，应该被禁止。如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。</p>
+				<p>
+           <!--
+				   Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.
+           -->
+           sysctl 可以禁用安全机制或影响宿主上所有容器，因此除了若干“安全”的允许子集之外，其他都应该被禁止。
+           如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。
+        </p>
 				<p><strong><!--Restricted Fields-->限制的字段</strong></p>
 				<ul>
 					<li><code>spec.securityContext.sysctls[*].name</code></li>
@@ -346,7 +376,7 @@ containers_. If any of the listed containers fails to meet the requirements, the
 fail validation.
 -->
 在下述表格中，通配符（`*`）意味着一个列表中的所有元素。
-例如 `spec.containers[*].securityContext` 表示 **所定义的所有容器** 的安全性上下文对象。
+例如 `spec.containers[*].securityContext` 表示**所定义的所有容器**的安全性上下文对象。
 如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。
 {{< /note >}}
 
@@ -363,7 +393,12 @@ fail validation.
 		<tr>
 			<td style="white-space: nowrap"><!--Volume Types-->卷类型</td>
 			<td>
-				<p><!--In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.-->除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。</p>
+				<p>
+				  <!--
+				  In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.
+				  -->
+				  除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。
+				</p>
 				<p><strong><!--Restricted Fields-->限制的字段</strong></p>
 				<ul>
 					<li><code>spec.volumes[*]</code></li>
@@ -689,4 +724,3 @@ sandboxing. As such, no single recommended profile is recommended for all sandbo
 
 此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
 因此，现在还没有针对所有沙箱化负载的建议配置。
-

content/zh-cn/docs/concepts/security/security-checklist.md

@@ -63,7 +63,7 @@ evaluated on its merits.
 - [ ] A process exists for periodic access review, and reviews occur no more
   than 24 months apart.
 - [ ] The [Role Based Access Control Good Practices](/docs/concepts/security/rbac-good-practices/)
-  is followed for guidance related to authentication and authorization.
+  are followed for guidance related to authentication and authorization.
 -->
 ## 认证和鉴权 {#authentication-authorization}
 
@@ -326,18 +326,18 @@ Seccomp 仅适用于 Linux 节点。
 #### AppArmor
 
 <!--
-[AppArmor](https://apparmor.net/) is a Linux kernel security module that can
+[AppArmor](/docs/tutorials/security/apparmor/) is a Linux kernel security module that can
 provide an easy way to implement Mandatory Access Control (MAC) and better
-auditing through system logs. To [enable AppArmor in Kubernetes](/docs/tutorials/security/apparmor/),
-at least version 1.4 is required. Like seccomp, AppArmor is also configured
+auditing through system logs. A default AppArmor profile is enforced on nodes that support it, or a custom profile can be configured.
+Like seccomp, AppArmor is also configured
 through profiles, where each profile is either running in enforcing mode, which
 blocks access to disallowed resources or complain mode, which only reports
 violations. AppArmor profiles are enforced on a per-container basis, with an
 annotation, allowing for processes to gain just the right privileges.
 -->
-[AppArmor](https://apparmor.net/) 是一个 Linux 内核安全模块，
+[AppArmor](/zh-cn/docs/tutorials/security/apparmor/) 是一个 Linux 内核安全模块，
 可以提供一种简单的方法来实现强制访问控制（Mandatory Access Control, MAC）并通过系统日志进行更好地审计。
-要在 Kubernetes 中[启用 AppArmor](/zh-cn/docs/tutorials/security/apparmor/)，至少需要 1.4 版本。
+默认 AppArmor 配置文件在支持它的节点上强制执行，或者可以配置自定义配置文件。
 与 Seccomp 一样，AppArmor 也通过配置文件进行配置，
 其中每个配置文件要么在强制（Enforcing）模式下运行，即阻止访问不允许的资源，要么在投诉（Complaining）模式下运行，只报告违规行为。
 AppArmor 配置文件是通过注解的方式，以容器为粒度强制执行的，允许进程获得刚好合适的权限。
@@ -730,8 +730,12 @@ has permissions to use the image.
 <!--
 ## What's next
 
-- [RBAC Good Practices](/docs/concepts/security/rbac-good-practices/) for
-  further information on authorization.
+- [Privilege escalation via Pod creation](/docs/reference/access-authn-authz/authorization/#privilege-escalation-via-pod-creation)
+  warns you about a specific access control risk; check how you're managing that
+  threat.
+  - If you use Kubernetes RBAC, read
+    [RBAC Good Practices](/docs/concepts/security/rbac-good-practices/) for
+    further information on authorization.
 - [Securing a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/) for
   information on protecting a cluster from accidental or malicious access.
 - [Cluster Multi-tenancy guide](/docs/concepts/security/multi-tenancy/) for
@@ -741,7 +745,10 @@ has permissions to use the image.
 -->
 ## 接下来  {#what-is-next}
 
-- [RBAC 良好实践](/zh-cn/docs/concepts/security/rbac-good-practices/)提供有关授权的更多信息。
+- [通过 Pod 创建进行权限升级](/zh-cn/docs/reference/access-authn-authz/authorization/#privilege-escalation-via-pod-creation)会警告你特定的访问控制风险；
+  请检查你如何管理该风险。
+  - 如果你使用 Kubernetes RBAC，请阅读
+    [RBAC 良好实践](/zh-cn/docs/concepts/security/rbac-good-practices/)获取有关鉴权的更多信息。
 - [保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)提供如何保护集群免受意外或恶意访问的信息。
 - [集群多租户指南](/zh-cn/docs/concepts/security/multi-tenancy/)提供有关多租户的配置选项建议和最佳实践。
 - [博文“深入了解 NSA/CISA Kubernetes 强化指南”](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#building-secure-container-images)为强化

content/zh-cn/docs/concepts/security/service-accounts.md

@@ -2,15 +2,21 @@
 title: 服务账号
 description: >
   了解 Kubernetes 中的 ServiceAccount 对象。
+api_metadata:
+- apiVersion: "v1"
+  kind: "ServiceAccount"
 content_type: concept
-weight: 10
+weight: 25
 ---
 <!--
 title: Service Accounts
 description: >
   Learn about ServiceAccount objects in Kubernetes.
+api_metadata:
+- apiVersion: "v1"
+  kind: "ServiceAccount"
 content_type: concept
-weight: 10
+weight: 25
 -->
 
 <!-- overview -->