diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md
index 1e4f131f29..fd03e3b8ad 100644
--- a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md
+++ b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md
@@ -37,9 +37,15 @@ Kubernetes 组件基于 gRPC 导出器的
## 追踪信息的收集 {#trace-collection}
+Kubernetes 组件具有内置的 gRPC 导出器,供 OTLP 导出追踪信息,可以使用 OpenTelemetry Collector,
+也可以不使用 OpenTelemetry Collector。
+
+要在不使用收集器的情况下直接将追踪信息发送到后端,请在 Kubernetes
+追踪配置文件中指定端点字段以及所需的追踪后端地址。
+该方法不需要收集器并简化了整体结构。
+
+
+对于追踪后端标头配置,包括身份验证详细信息,环境变量可以与 `OTEL_EXPORTER_OTLP_HEADERS`
+一起使用,请参阅 [OTLP 导出器配置](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)。
+
+
+另外,对于 Kubernetes 集群名称、命名空间、Pod 名称等追踪资源属性配置,
+环境变量也可以与 `OTEL_RESOURCE_ATTRIBUTES` 配合使用,请参见
+[OTLP Kubernetes 资源](https://opentelemetry.io/docs/specs/semconv/resource/k8s/)。
+
* 阅读 [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
+* 了解 [OTLP 导出器配置](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)
diff --git a/content/zh-cn/docs/concepts/security/pod-security-standards.md b/content/zh-cn/docs/concepts/security/pod-security-standards.md
index 2b46cd07c7..dcf28ae0d5 100644
--- a/content/zh-cn/docs/concepts/security/pod-security-standards.md
+++ b/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
---
@@ -214,8 +214,27 @@ fail validation.
AppArmor |
- 在受支持的主机上,默认使用 runtime/default AppArmor 配置。Baseline 策略应避免覆盖或者禁用默认策略,以及限制覆盖一些配置集合的权限。
- 限制的字段
+
+
+ 在受支持的主机上,默认使用 RuntimeDefault AppArmor 配置。Baseline
+ 策略应避免覆盖或者禁用默认策略,以及限制覆盖一些配置集合的权限。
+
+ 限制的字段
+
+ spec.securityContext.appArmorProfile.type
+ spec.containers[*].securityContext.appArmorProfile.type
+ spec.initContainers[*].securityContext.appArmorProfile.type
+ spec.ephemeralContainers[*].securityContext.appArmorProfile.type
+
+ 准许的取值<
+
+ - Undefined/nil
+ RuntimeDefault
+ Localhost
+
+
metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]
@@ -230,7 +249,12 @@ fail validation.
|
SELinux |
- 设置 SELinux 类型的操作是被限制的,设置自定义的 SELinux 用户或角色选项是被禁止的。
+
+
+ 设置 SELinux 类型的操作是被限制的,设置自定义的 SELinux 用户或角色选项是被禁止的。
+
限制的字段
spec.securityContext.seLinuxOptions.type
@@ -302,7 +326,13 @@ fail validation.
Sysctls |
- Sysctls 可以禁用安全机制或影响宿主上所有容器,因此除了若干“安全”的子集之外,应该被禁止。如果某 sysctl 是受容器或 Pod 的名字空间限制,且与节点上其他 Pod 或进程相隔离,可认为是安全的。
+
+
+ sysctl 可以禁用安全机制或影响宿主上所有容器,因此除了若干“安全”的允许子集之外,其他都应该被禁止。
+ 如果某 sysctl 是受容器或 Pod 的名字空间限制,且与节点上其他 Pod 或进程相隔离,可认为是安全的。
+
限制的字段
spec.securityContext.sysctls[*].name
@@ -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.
卷类型 |
- 除了限制 HostPath 卷之外,此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。
+
+
+ 除了限制 HostPath 卷之外,此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。
+
限制的字段
spec.volumes[*]
@@ -689,4 +724,3 @@ sandboxing. As such, no single recommended profile is recommended for all sandbo
此外,沙箱化负载的保护高度依赖于沙箱化的实现方法。
因此,现在还没有针对所有沙箱化负载的建议配置。
-
diff --git a/content/zh-cn/docs/concepts/security/security-checklist.md b/content/zh-cn/docs/concepts/security/security-checklist.md
index 3881b06253..07b2c30428 100644
--- a/content/zh-cn/docs/concepts/security/security-checklist.md
+++ b/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/) 是一个 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-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)为强化
diff --git a/content/zh-cn/docs/concepts/security/service-accounts.md b/content/zh-cn/docs/concepts/security/service-accounts.md
index d25f461492..830eaeb991 100644
--- a/content/zh-cn/docs/concepts/security/service-accounts.md
+++ b/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
---
| | |