Merge pull request #46131 from my-git9/pt-10522
[zh-cn] sync pod-security-standards security-checklist service-accounts system-tracespull/46160/head
commit
3a4c488a22
|
@ -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/)
|
||||
|
|
|
@ -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
|
|||
|
||||
此外,沙箱化负载的保护高度依赖于沙箱化的实现方法。
|
||||
因此,现在还没有针对所有沙箱化负载的建议配置。
|
||||
|
||||
|
|
|
@ -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)为强化
|
||||
|
|
|
@ -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 -->
|
||||
|
|
Loading…
Reference in New Issue