Kubernetes Prow Robot
GitHub
commit
4327f2d642
|
|
@ -14,12 +14,20 @@ weight: 30
|
|||
|
||||
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. For more information on the deprecation,
|
||||
PodSecurityPolicy is deprecated as of Kubernetes v1.21, and **will be removed in v1.25**. We recommend migrating to
|
||||
[Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin.
|
||||
For a migration guide, see [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
|
||||
For more information on the deprecation,
|
||||
see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
|
||||
-->
|
||||
PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，将在 v1.25 中删除。
|
||||
PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。
|
||||
我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)，
|
||||
或者第三方的准入插件。
|
||||
若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。
|
||||
关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
Pod Security Policies enable fine-grained authorization of pod creation and
|
||||
|
|
|
|||
|
|
@ -0,0 +1,327 @@
|
|||
---
|
||||
title: Pod 安全性准入
|
||||
description: >
|
||||
对 Pod 安全性准入控制器的概述，Pod 安全性准入控制器可以实施 Pod 安全性标准。
|
||||
|
||||
content_type: concept
|
||||
weight: 20
|
||||
min-kubernetes-server-version: v1.22
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- tallclair
|
||||
- liggitt
|
||||
title: Pod Security Admission
|
||||
description: >
|
||||
An overview of the Pod Security Admission Controller, which can enforce the Pod Security
|
||||
Standards.
|
||||
content_type: concept
|
||||
weight: 20
|
||||
min-kubernetes-server-version: v1.22
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
<!--
|
||||
The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) define
|
||||
different isolation levels for Pods. These standards let you define how you want to restrict the
|
||||
behavior of pods in a clear, consistent fashion.
|
||||
-->
|
||||
Kubernetes [Pod 安全性标准（Security Standards）](/zh/docs/concepts/security/pod-security-standards/)
|
||||
为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。
|
||||
|
||||
<!--
|
||||
As an Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
|
||||
text="admission controller" term_id="admission-controller" >}}, the successor
|
||||
to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions
|
||||
are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
|
||||
are created.
|
||||
-->
|
||||
作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_
|
||||
{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}，
|
||||
作为 [PodSecurityPolicies](/zh/docs/concepts/policy/pod-security-policy/)
|
||||
特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在
|
||||
{{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The PodSecurityPolicy API is deprecated and will be
|
||||
[removed](/docs/reference/using-api/deprecation-guide/#v1-25) from Kubernetes in v1.25.
|
||||
-->
|
||||
PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中
|
||||
[移除](/zh/docs/reference/using-api/deprecation-guide/#v1-25)。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Enabling the `PodSecurity` admission plugin
|
||||
|
||||
In v1.23, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is a Beta feature and is enabled by default.
|
||||
|
||||
In v1.22, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is an Alpha feature and must be enabled in `kube-apiserver` in order to use the built-in admission plugin.
|
||||
-->
|
||||
## 启用 `PodSecurity` 准入插件 {#enabling-the-podsecurity-admission-plugin}
|
||||
|
||||
在 v1.23 中，`PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
是一项 Beta 功能特性，默认被启用。
|
||||
|
||||
在 v1.22 中，`PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
是一项 Alpha 功能特性，必须在 `kube-apiserver` 上启用才能使用内置的准入插件。
|
||||
|
||||
```shell
|
||||
--feature-gates="...,PodSecurity=true"
|
||||
```
|
||||
|
||||
<!--
|
||||
## Alternative: installing the `PodSecurity` admission webhook {#webhook}
|
||||
|
||||
For environments where the built-in `PodSecurity` admission plugin cannot be used,
|
||||
either because the cluster is older than v1.22, or the `PodSecurity` feature cannot be enabled,
|
||||
the `PodSecurity` admission logic is also available as a Beta [validating admission webhook](https://git.k8s.io/pod-security-admission/webhook).
|
||||
-->
|
||||
## 替代方案：安装 `PodSecurity` 准入 Webhook {#webhook}
|
||||
|
||||
对于无法应用内置 `PodSecurity` 准入插件的环境，无论是因为集群版本低于 v1.22，
|
||||
或者 `PodSecurity` 特性无法被启用，都可以使用 Beta 版本的
|
||||
[验证性准入 Webhook](https://git.k8s.io/pod-security-admission/webhook)。
|
||||
来使用 `PodSecurity` 准入逻辑。
|
||||
|
||||
<!--
|
||||
A pre-built container image, certificate generation scripts, and example manifests
|
||||
are available at [https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook).
|
||||
|
||||
To install:
|
||||
-->
|
||||
在 [https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook)
|
||||
上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。
|
||||
|
||||
```shell
|
||||
git clone git@github.com:kubernetes/pod-security-admission.git
|
||||
cd pod-security-admission/webhook
|
||||
make certs
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The generated certificate is valid for 2 years. Before it expires,
|
||||
regenerate the certificate or remove the webhook in favor of the built-in admission plugin.
|
||||
-->
|
||||
所生成的证书合法期限为 2 年。在证书过期之前，
|
||||
需要重新生成证书或者去掉 Webhook 以使用内置的准入查件。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Pod Security levels
|
||||
-->
|
||||
## Pod 安全性级别 {#pod-security-levels}
|
||||
|
||||
<!--
|
||||
Pod Security admission places requirements on a Pod's [Security
|
||||
Context](/docs/tasks/configure-pod-container/security-context/) and other related fields according
|
||||
to the three levels defined by the [Pod Security
|
||||
Standards](/docs/concepts/security/pod-security-standards): `privileged`, `baseline`, and
|
||||
`restricted`. Refer to the [Pod Security Standards](/docs/concepts/security/pod-security-standards)
|
||||
page for an in-depth look at those requirements.
|
||||
-->
|
||||
Pod 安全性准入插件对 Pod 的[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)
|
||||
有一定的要求，并且依据 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)
|
||||
所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。
|
||||
关于这些需求的更进一步讨论，请参阅
|
||||
[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)页面。
|
||||
|
||||
<!--
|
||||
## Pod Security Admission labels for namespaces
|
||||
|
||||
Once the feature is enabled or the webhook is installed, you can configure namespaces to define the admission
|
||||
control mode you want to use for pod security in each namespace. Kubernetes defines a set of
|
||||
{{< glossary_tooltip term_id="label" text="labels" >}} that you can set to define which of the
|
||||
predefined Pod Security Standard levels you want to use for a namespace. The label you select
|
||||
defines what action the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
|
||||
takes if a potential violation is detected:
|
||||
-->
|
||||
## 为名字空间设置 Pod 安全性准入控制标签
|
||||
|
||||
一旦特性被启用或者安装了 Webhook，你可以配置名字空间以定义每个名字空间中
|
||||
Pod 安全性准入控制模式。
|
||||
Kubernetes 定义了一组{{< glossary_tooltip term_id="label" text="标签" >}}，
|
||||
你可以设置这些标签来定义某个名字空间上要使用的预定义的 Pod 安全性标准级别。
|
||||
你所选择的标签定义了检测到潜在违例时，{{< glossary_tooltip text="控制面" term_id="control-plane" >}}
|
||||
要采取什么样的动作。
|
||||
|
||||
<!--
|
||||
{{< table caption="Pod Security Admission modes" >}}
|
||||
Mode | Description
|
||||
:---------|:------------
|
||||
**enforce** | Policy violations will cause the pod to be rejected.
|
||||
**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug-application-cluster/audit/), but are otherwise allowed.
|
||||
**warn** | Policy violations will trigger a user-facing warning, but are otherwise allowed.
|
||||
{{< /table >}}
|
||||
-->
|
||||
{{< table caption="Pod 安全准入模式" >}}
|
||||
模式 | 描述
|
||||
:---------|:------------
|
||||
**enforce** | 策略违例会导致 Pod 被拒绝
|
||||
**audit** | 策略违例会触发[审计日志](/zh/docs/tasks/debug-application-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。
|
||||
**warn** | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。
|
||||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
A namespace can configure any or all modes, or even set a different level for different modes.
|
||||
|
||||
For each mode, there are two labels that determine the policy used:
|
||||
-->
|
||||
名字空间可以配置任何一种或者所有模式，或者甚至为不同的模式设置不同的级别。
|
||||
|
||||
对于每种模式，决定所使用策略的标签有两个：
|
||||
|
||||
<!--
|
||||
# The per-mode level label indicates which policy level to apply for the mode.
|
||||
#
|
||||
# MODE must be one of `enforce`, `audit`, or `warn`.
|
||||
# LEVEL must be one of `privileged`, `baseline`, or `restricted`.
|
||||
pod-security.kubernetes.io/<MODE>: <LEVEL>
|
||||
|
||||
# Optional: per-mode version label that can be used to pin the policy to the
|
||||
# version that shipped with a given Kubernetes minor version (for example v{{< skew latestVersion >}}).
|
||||
#
|
||||
# MODE must be one of `enforce`, `audit`, or `warn`.
|
||||
# VERSION must be a valid Kubernetes minor version, or `latest`.
|
||||
pod-security.kubernetes.io/<MODE>-version: <VERSION>
|
||||
-->
|
||||
```
|
||||
# 针对模式的级别标签用来标示针对该模式所应用的策略级别
|
||||
#
|
||||
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
|
||||
# LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一
|
||||
pod-security.kubernetes.io/<MODE>: <LEVEL>
|
||||
|
||||
# 可选：针对每个模式版本的版本标签可以将策略锁定到
|
||||
# 给定 Kubernetes 小版本号所附带的版本（例如 v{{< skew latestVersion >}}）
|
||||
#
|
||||
# MODE 必须是 `enforce`、`audit` 或 `warn` 之一
|
||||
# VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest`
|
||||
pod-security.kubernetes.io/<MODE>-version: <VERSION>
|
||||
```
|
||||
|
||||
<!--
|
||||
Check out [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) to see example usage.
|
||||
-->
|
||||
关于用法示例，可参阅
|
||||
[使用名字空间标签来强制实施 Pod 安全标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。
|
||||
|
||||
<!--
|
||||
## Workload resources and Pod templates
|
||||
|
||||
Pods are often created indirectly, by creating a [workload
|
||||
object](/docs/concepts/workloads/controllers/) such as a {{< glossary_tooltip
|
||||
term_id="deployment" >}} or {{< glossary_tooltip term_id="job">}}. The workload object defines a
|
||||
_Pod template_ and a {{< glossary_tooltip term_id="controller" text="controller" >}} for the
|
||||
workload resource creates Pods based on that template. To help catch violations early, both the
|
||||
audit and warning modes are applied to the workload resources. However, enforce mode is **not**
|
||||
applied to workload resources, only to the resulting pod objects.
|
||||
-->
|
||||
## 负载资源和 Pod 模板 {#workload-resources-and-pod-templates}
|
||||
|
||||
Pod 通常是通过创建 {{< glossary_tooltip term_id="deployment" >}} 或
|
||||
{{< glossary_tooltip term_id="job">}} 这类[工作负载对象](/zh/docs/concepts/workloads/controllers/)
|
||||
来间接创建的。工作负载对象为工作负载资源定义一个 _Pod 模板_ 和一个对应的
|
||||
负责基于该模板来创建 Pod 的{{< glossary_tooltip term_id="controller" text="控制器" >}}。
|
||||
为了尽早地捕获违例状况，`audit` 和 `warn` 模式都应用到负载资源。
|
||||
不过，`enforce` 模式并 **不** 应用到工作负载资源，仅应用到所生成的 Pod 对象上。
|
||||
|
||||
<!--
|
||||
## Exemptions
|
||||
|
||||
You can define _exemptions_ from pod security enforcement in order allow the creation of pods that
|
||||
would have otherwise been prohibited due to the policy associated with a given namespace.
|
||||
Exemptions can be statically configured in the
|
||||
[Admission Controller configuration](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller).
|
||||
-->
|
||||
## 豁免 {#exemptions}
|
||||
|
||||
你可以为 Pod 安全性的实施设置 _豁免（Exemptions）_ 规则，
|
||||
从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。
|
||||
豁免规则可以在[准入控制器配置](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
|
||||
中静态配置。
|
||||
|
||||
<!--
|
||||
Exemptions must be explicitly enumerated. Requests meeting exemption criteria are _ignored_ by the
|
||||
Admission Controller (all `enforce`, `audit` and `warn` behaviors are skipped). Exemption dimensions include:
|
||||
-->
|
||||
豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 _忽略_
|
||||
（所有 `enforce`、`audit` 和 `warn` 行为都会被略过）。
|
||||
豁免的维度包括：
|
||||
|
||||
<!--
|
||||
- **Usernames:** requests from users with an exempt authenticated (or impersonated) username are
|
||||
ignored.
|
||||
- **RuntimeClassNames:** pods and [workload resources](#workload-resources-and-pod-templates) specifying an exempt runtime class name are
|
||||
ignored.
|
||||
- **Namespaces:** pods and [workload resources](#workload-resources-and-pod-templates) in an exempt namespace are ignored.
|
||||
-->
|
||||
- **Username：** 来自用户名已被豁免的、已认证的（或伪装的）的用户的请求会被忽略。
|
||||
- **RuntimeClassName：** 指定了已豁免的运行时类名称的 Pod
|
||||
和[负载资源](#workload-resources-and-pod-templates)会被忽略。
|
||||
- **Namespace：** 位于被豁免的名字空间中的 Pod 和[负载资源](#workload-resources-and-pod-templates)
|
||||
会被忽略。
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
Most pods are created by a controller in response to a [workload
|
||||
resource](#workload-resources-and-pod-templates), meaning that exempting an end user will only
|
||||
exempt them from enforcement when creating pods directly, but not when creating a workload resource.
|
||||
Controller service accounts (such as `system:serviceaccount:kube-system:replicaset-controller`)
|
||||
should generally not be exempted, as doing so would implicitly exempt any user that can create the
|
||||
corresponding workload resource.
|
||||
-->
|
||||
大多数 Pod 是作为对[工作负载资源](#workload-resources-and-pod-templates)的响应，
|
||||
由控制器所创建的，这意味着为某最终用户提供豁免时，只会当该用户直接创建 Pod
|
||||
时对其实施安全策略的豁免。用户创建工作负载资源时不会被豁免。
|
||||
控制器服务账号（例如：`system:serviceaccount:kube-system:replicaset-controller`）
|
||||
通常不应该被豁免，因为豁免这类服务账号隐含着对所有能够创建对应工作负载资源的用户豁免。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
Updates to the following pod fields are exempt from policy checks, meaning that if a pod update
|
||||
request only changes these fields, it will not be denied even if the pod is in violation of the
|
||||
current policy level:
|
||||
-->
|
||||
策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod
|
||||
更新请求仅改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。
|
||||
|
||||
<!--
|
||||
- Any metadata updates **except** changes to the seccomp or AppArmor annotations:
|
||||
- `seccomp.security.alpha.kubernetes.io/pod` (deprecated)
|
||||
- `container.seccomp.security.alpha.kubernetes.io/*` (deprecated)
|
||||
- `container.apparmor.security.beta.kubernetes.io/*`
|
||||
- Valid updates to `.spec.activeDeadlineSeconds`
|
||||
- Valid updates to `.spec.tolerations`
|
||||
-->
|
||||
- 除了对 seccomp 或 AppArmor 注解之外的所有 meatadata 更新操作：
|
||||
- `seccomp.security.alpha.kubernetes.io/pod` （已弃用）
|
||||
- `container.seccomp.security.alpha.kubernetes.io/*` （已弃用）
|
||||
- `container.apparmor.security.beta.kubernetes.io/*`
|
||||
- 对 `.spec.activeDeadlineSeconds` 的合法更新
|
||||
- 对 `.spec.tolerations` 的合法更新
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- [Pod Security Standards](/docs/concepts/security/pod-security-standards)
|
||||
- [Enforcing Pod Security Standards](/docs/setup/best-practices/enforcing-pod-security-standards)
|
||||
- [Enforce Pod Security Standards by Configuring the Built-in Admission Controller](/docs/tasks/configure-pod-container/enforce-standards-admission-controller)
|
||||
- [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)
|
||||
- [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp)
|
||||
-->
|
||||
- [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)
|
||||
- [强制实施 Pod 安全性标准](/zh/docs/setup/best-practices/enforcing-pod-security-standards/)
|
||||
- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)
|
||||
- [使用名字空间标签来实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)
|
||||
- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)
|
||||
|
||||
|
|
@ -46,8 +46,8 @@ Pod 安全性标准定义了三种不同的 _策略（Policy）_，以广泛覆
|
|||
### Privileged
|
||||
|
||||
<!--
|
||||
**The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is typically
|
||||
aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
|
||||
**The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is
|
||||
typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
|
||||
|
||||
The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
|
||||
mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
|
||||
|
|
@ -69,17 +69,18 @@ Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
|
|||
preventing known privilege escalations.** This policy is targeted at application operators and
|
||||
developers of non-critical applications. The following listed controls should be
|
||||
enforced/disallowed:
|
||||
|
||||
In this table, wildcards (`*`) indicate all elements in a list. For example,
|
||||
`spec.containers[*].securityContext` refers to the Security Context object for _all defined
|
||||
containers_. If any of the listed containers fails to meet the requirements, the entire pod will
|
||||
fail validation.
|
||||
-->
|
||||
**_Baseline_ 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。**
|
||||
此策略针对的是应用运维人员和非关键性应用的开发人员。
|
||||
下面列举的控制应该被实施（禁止）：
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
In this table, wildcards (`*`) indicate all elements in a list. For example,
|
||||
`spec.containers[*].securityContext` refers to the Security Context object for _all defined
|
||||
containers_. If any of the listed containers fails to meet the requirements, the entire pod will
|
||||
fail validation.
|
||||
-->
|
||||
在下述表格中，通配符（`*`）意味着一个列表中的所有元素。
|
||||
例如 `spec.containers[*].securityContext` 表示 _所定义的所有容器_ 的安全性上下文对象。
|
||||
如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。
|
||||
|
|
@ -90,8 +91,8 @@ fail validation.
|
|||
<caption style="display:none">Baseline 策略规范</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td width="30%"><strong>控制（Control）</strong></td>
|
||||
<td><strong>策略（Policy）</strong></td>
|
||||
<td>控制（Control）</td>
|
||||
<td>策略（Policy）</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- <td style="white-space: nowrap">HostProcess</td> -->
|
||||
|
|
@ -564,31 +565,19 @@ fail validation.
|
|||
<p>In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.</p>
|
||||
<p><strong>Restricted Fields</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.volumes[*].hostPath</code></li>
|
||||
<li><code>spec.volumes[*].gcePersistentDisk</code></li>
|
||||
<li><code>spec.volumes[*].awsElasticBlockStore</code></li>
|
||||
<li><code>spec.volumes[*].gitRepo</code></li>
|
||||
<li><code>spec.volumes[*].nfs</code></li>
|
||||
<li><code>spec.volumes[*].iscsi</code></li>
|
||||
<li><code>spec.volumes[*].glusterfs</code></li>
|
||||
<li><code>spec.volumes[*].rbd</code></li>
|
||||
<li><code>spec.volumes[*].flexVolume</code></li>
|
||||
<li><code>spec.volumes[*].cinder</code></li>
|
||||
<li><code>spec.volumes[*].cephfs</code></li>
|
||||
<li><code>spec.volumes[*].flocker</code></li>
|
||||
<li><code>spec.volumes[*].fc</code></li>
|
||||
<li><code>spec.volumes[*].azureFile</code></li>
|
||||
<li><code>spec.volumes[*].vsphereVolume</code></li>
|
||||
<li><code>spec.volumes[*].quobyte</code></li>
|
||||
<li><code>spec.volumes[*].azureDisk</code></li>
|
||||
<li><code>spec.volumes[*].portworxVolume</code></li>
|
||||
<li><code>spec.volumes[*].scaleIO</code></li>
|
||||
<li><code>spec.volumes[*].storageos</code></li>
|
||||
<li><code>spec.volumes[*].photonPersistentDisk</code></li>
|
||||
<li><code>spec.volumes[*]</code></li>
|
||||
</ul>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
Every item in the <code>spec.volumes[*]</code> list must set one of the following fields to a non-null value:
|
||||
<ul>
|
||||
<li>Undefined/nil</li>
|
||||
<li><code>spec.volumes[*].configMap</code></li>
|
||||
<li><code>spec.volumes[*].csi</code></li>
|
||||
<li><code>spec.volumes[*].downwardAPI</code></li>
|
||||
<li><code>spec.volumes[*].emptyDir</code></li>
|
||||
<li><code>spec.volumes[*].ephemeral</code></li>
|
||||
<li><code>spec.volumes[*].persistentVolumeClaim</code></li>
|
||||
<li><code>spec.volumes[*].projected</code></li>
|
||||
<li><code>spec.volumes[*].secret</code></li>
|
||||
</ul>
|
||||
</td> -->
|
||||
<td>卷类型</td>
|
||||
|
|
@ -596,31 +585,19 @@ fail validation.
|
|||
<p>除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。</p>
|
||||
<p><strong>限制的字段</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.volumes[*].hostPath</code></li>
|
||||
<li><code>spec.volumes[*].gcePersistentDisk</code></li>
|
||||
<li><code>spec.volumes[*].awsElasticBlockStore</code></li>
|
||||
<li><code>spec.volumes[*].gitRepo</code></li>
|
||||
<li><code>spec.volumes[*].nfs</code></li>
|
||||
<li><code>spec.volumes[*].iscsi</code></li>
|
||||
<li><code>spec.volumes[*].glusterfs</code></li>
|
||||
<li><code>spec.volumes[*].rbd</code></li>
|
||||
<li><code>spec.volumes[*].flexVolume</code></li>
|
||||
<li><code>spec.volumes[*].cinder</code></li>
|
||||
<li><code>spec.volumes[*].cephfs</code></li>
|
||||
<li><code>spec.volumes[*].flocker</code></li>
|
||||
<li><code>spec.volumes[*].fc</code></li>
|
||||
<li><code>spec.volumes[*].azureFile</code></li>
|
||||
<li><code>spec.volumes[*].vsphereVolume</code></li>
|
||||
<li><code>spec.volumes[*].quobyte</code></li>
|
||||
<li><code>spec.volumes[*].azureDisk</code></li>
|
||||
<li><code>spec.volumes[*].portworxVolume</code></li>
|
||||
<li><code>spec.volumes[*].scaleIO</code></li>
|
||||
<li><code>spec.volumes[*].storageos</code></li>
|
||||
<li><code>spec.volumes[*].photonPersistentDisk</code></li>
|
||||
<li><code>spec.volumes[*]</code></li>
|
||||
</ul>
|
||||
<p><strong>允许的值</strong></p>
|
||||
<code>spec.volumes[*]</code> 列表中的每个条目必须将下面字段之一设置为非空值：
|
||||
<ul>
|
||||
<li>未定义/nil</li>
|
||||
<li><code>spec.volumes[*].configMap</code></li>
|
||||
<li><code>spec.volumes[*].csi</code></li>
|
||||
<li><code>spec.volumes[*].downwardAPI</code></li>
|
||||
<li><code>spec.volumes[*].emptyDir</code></li>
|
||||
<li><code>spec.volumes[*].ephemeral</code></li>
|
||||
<li><code>spec.volumes[*].persistentVolumeClaim</code></li>
|
||||
<li><code>spec.volumes[*].projected</code></li>
|
||||
<li><code>spec.volumes[*].secret</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -696,40 +673,36 @@ fail validation.
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- <td style="white-space: nowrap">Non-root groups <em>(optional)</em></td> -->
|
||||
<td style="white-space: nowrap">非 root 组<em>（可选）</em></td>
|
||||
<!-- <td style="white-space: nowrap">Running as Non-root user (v1.23+)</td> -->
|
||||
<td style="white-space: nowrap">非 root 用户（v1.23+）</td>
|
||||
<td>
|
||||
<!-- <td>
|
||||
<p>Containers should be forbidden from running with a root primary or supplementary GID.</p>
|
||||
<!--
|
||||
<p>Containers must not set <tt>runAsUser</tt> to 0</p>
|
||||
<p><strong>Restricted Fields</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.securityContext.supplementalGroups[*]</code></li>
|
||||
<li><code>spec.securityContext.fsGroup</code></li>
|
||||
<li><code>spec.containers[*].securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.securityContext.runAsUser</code></li>
|
||||
<li><code>spec.containers[*].securityContext.runAsUser</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.runAsUser</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.runAsUser</code></li>
|
||||
</ul>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li>Undefined/nil (except for <code>*.runAsGroup</code>)</li>
|
||||
<li>Non-zero</li>
|
||||
<li>any non-zero value</li>
|
||||
<li><code>undefined/null</code></li>
|
||||
</ul>
|
||||
</td> -->
|
||||
<p>禁止容器使用 root 作为主要或辅助 GID 来运行。</p>
|
||||
<p>Containers 不可以将 <tt>runAsUser</tt> 设置为 0</p>
|
||||
<p><strong>限制的字段</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.securityContext.supplementalGroups[*]</code></li>
|
||||
<li><code>spec.securityContext.fsGroup</code></li>
|
||||
<li><code>spec.containers[*].securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.runAsGroup</code></li>
|
||||
<li><code>spec.securityContext.runAsUser</code></li>
|
||||
<li><code>spec.containers[*].securityContext.runAsUser</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.runAsUser</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.runAsUser</code></li>
|
||||
</ul>
|
||||
<p><strong>允许的值</strong></p>
|
||||
<p><strong>允许的字段</strong></p>
|
||||
<ul>
|
||||
<li>未定义/nil（<code>*.runAsGroup</code> 除外）</li>
|
||||
<li>非零值</li>
|
||||
<li>any non-zero value</li>
|
||||
<li><code>未定义/空值</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -859,11 +832,11 @@ of individual policies are not defined here.
|
|||
|
||||
[**Pod 安全性准入控制器**](/zh/docs/concepts/security/pod-security-admission/)
|
||||
|
||||
- {{< example file="security/podsecurity-privileged.yaml" >}}Privileged namespace{{< /example >}}
|
||||
- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline namespace{{< /example >}}
|
||||
- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted namespace{{< /example >}}
|
||||
- {{< example file="security/podsecurity-privileged.yaml" >}}Privileged 名字空间{{< /example >}}
|
||||
- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline 名字空间{{< /example >}}
|
||||
- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted 名字空间{{< /example >}}
|
||||
|
||||
[**PodSecurityPolicy**](/zh/docs/concepts/policy/pod-security-policy/)
|
||||
[**PodSecurityPolicy**](/zh/docs/concepts/policy/pod-security-policy/) （已弃用）
|
||||
|
||||
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
|
||||
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
title: 强制实施 Pod 安全性标准
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- tallclair
|
||||
- liggitt
|
||||
title: Enforcing Pod Security Standards
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page provides an overview of best practices when it comes to enforcing
|
||||
[Pod Security Standards](/docs/concepts/security/pod-security-standards).
|
||||
-->
|
||||
本页提供实施 [Pod 安全标准（Pod Security Standards）](/zh/docs/concepts/security/pod-security-standards)
|
||||
时的一些最佳实践。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Using the built-in Pod Security Admission Controller
|
||||
-->
|
||||
## 使用内置的 Pod 安全性准入控制器
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
<!--
|
||||
The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
|
||||
intends to replace the deprecated PodSecurityPolicies.
|
||||
-->
|
||||
[Pod 安全性准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
|
||||
尝试替换已被废弃的 PodSecurityPolicies。
|
||||
|
||||
<!--
|
||||
### Configure all cluster namespaces
|
||||
-->
|
||||
### 配置所有集群名字空间 {#configure-all-cluster-namespaces}
|
||||
|
||||
<!--
|
||||
Namespaces that lack any configuration at all should be considered significant gaps in your cluster
|
||||
security model. We recommend taking the time to analyze the types of workloads occurring in each
|
||||
namespace, and by referencing the Pod Security Standards, decide on an appropriate level for
|
||||
each of them. Unlabeled namespaces should only indicate that they've yet to be evaluated.
|
||||
-->
|
||||
完全未经配置的名字空间应该被视为集群安全模型中的重大缺陷。
|
||||
我们建议花一些时间来分析在每个名字空间中执行的负载的类型，
|
||||
并通过引用 Pod 安全性标准来确定每个负载的合适级别。
|
||||
未设置标签的名字空间应该视为尚未被评估。
|
||||
|
||||
<!--
|
||||
In the scenario that all workloads in all namespaces have the same security requirements,
|
||||
we provide an [example](/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)
|
||||
that illustrates how the PodSecurity labels can be applied in bulk.
|
||||
-->
|
||||
针对所有名字空间中的所有负载都具有相同的安全性需求的场景，
|
||||
我们提供了一个[示例](/zh/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)
|
||||
用来展示如何批量应用 Pod 安全性标签。
|
||||
|
||||
<!--
|
||||
### Embrace the principle of least privilege
|
||||
|
||||
In an ideal world, every pod in every namespace would meet the requirements of the `restricted`
|
||||
policy. However, this is not possible nor practical, as some workloads will require elevated
|
||||
privileges for legitimate reasons.
|
||||
-->
|
||||
### 拥抱最小特权原则
|
||||
|
||||
在一个理想环境中，每个名字空间中的每个 Pod 都会满足 `restricted` 策略的需求。
|
||||
不过，这既不可能也不现实，某些负载会因为合理的原因而需要特权上的提升。
|
||||
|
||||
<!--
|
||||
- Namespaces allowing `privileged` workloads should establish and enforce appropriate access controls.
|
||||
- For workloads running in those permissive namespaces, maintain documentation about their unique
|
||||
security requirements. If at all possible, consider how those requirements could be further
|
||||
constrained.
|
||||
-->
|
||||
- 允许 `privileged` 负载的名字空间需要建立并实施适当的访问控制机制。
|
||||
- 对于运行在特权宽松的名字空间中的负载，需要维护其独特安全性需求的文档。
|
||||
如果可能的话，要考虑如何进一步约束这些需求。
|
||||
|
||||
<!--
|
||||
### Adopt a multi-mode strategy
|
||||
|
||||
The `audit` and `warn` modes of the Pod Security Standards admission controller make it easy to
|
||||
collect important security insights about your pods without breaking existing workloads.
|
||||
-->
|
||||
### 采用多种模式的策略
|
||||
|
||||
Pod 安全性标准准入控制器的 `audit` 和 `warn` 模式（mode）
|
||||
能够在不影响现有负载的前提下，让该控制器更方便地收集关于 Pod 的重要的安全信息。
|
||||
|
||||
<!--
|
||||
It is good practice to enable these modes for all namespaces, setting them to the _desired_ level
|
||||
and version you would eventually like to `enforce`. The warnings and audit annotations generated in
|
||||
this phase can guide you toward that state. If you expect workload authors to make changes to fit
|
||||
within the desired level, enable the `warn` mode. If you expect to use audit logs to monitor/drive
|
||||
changes to fit within the desired level, enable the `audit` mode.
|
||||
-->
|
||||
针对所有名字空间启用这些模式是一种好的实践，将它们设置为你最终打算 `enforce` 的
|
||||
_期望的_ 级别和版本。这一阶段中所生成的警告和审计注解信息可以帮助你到达这一状态。
|
||||
如果你期望负载的作者能够作出变更以便适应期望的级别，可以启用 `warn` 模式。
|
||||
如果你希望使用审计日志了监控和驱动变更，以便负载能够适应期望的级别，可以启用 `audit` 模式。
|
||||
|
||||
<!--
|
||||
When you have the `enforce` mode set to your desired value, these modes can still be useful in a
|
||||
few different ways:
|
||||
|
||||
- By setting `warn` to the same level as `enforce`, clients will receive warnings when attempting
|
||||
to create Pods (or resources that have Pod templates) that do not pass validation. This will help
|
||||
them update those resources to become compliant.
|
||||
- In Namespaces that pin `enforce` to a specific non-latest version, setting the `audit` and `warn`
|
||||
modes to the same level as `enforce`, but to the `latest` version, gives visibility into settings
|
||||
that were allowed by previous versions but are not allowed per current best practices.
|
||||
-->
|
||||
当你将 `enforce` 模式设置为期望的取值时，这些模式在不同的场合下仍然是有用的：
|
||||
|
||||
- 通过将 `warn` 设置为 `enforce` 相同的级别，客户可以在尝试创建无法通过合法检查的 Pod
|
||||
（或者包含 Pod 模板的资源）时收到警告信息。这些信息会帮助于更新资源使其合规。
|
||||
- 在将 `enforce` 锁定到特定的非最新版本的名字空间中，将 `audit` 和 `warn`
|
||||
模式设置为 `enforce` 一样的级别而非 `latest` 版本，
|
||||
这样可以方便看到之前版本所允许但当前最佳实践中被禁止的设置。
|
||||
|
||||
<!--
|
||||
## Third-party alternatives
|
||||
-->
|
||||
## 第三方替代方案 {#third-party-alternatives}
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
Other alternatives for enforcing security profiles are being developed in the Kubernetes
|
||||
ecosystem:
|
||||
-->
|
||||
Kubernetes 生态系统中也有一些其他强制实施安全设置的替代方案处于开发状态中：
|
||||
|
||||
- [Kubewarden](https://github.com/kubewarden).
|
||||
- [Kyverno](https://kyverno.io/policies/).
|
||||
- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
|
||||
|
||||
<!--
|
||||
The decision to go with a _built-in_ solution (e.g. PodSecurity admission controller) versus a
|
||||
third-party tool is entirely dependent on your own situation. When evaluating any solution,
|
||||
trust of your supply chain is crucial. Ultimately, using _any_ of the aforementioned approaches
|
||||
will be better than doing nothing.
|
||||
-->
|
||||
采用 _内置的_ 方案（例如 PodSecurity 准入控制器）还是第三方工具，
|
||||
这一决策完全取决于你自己的情况。在评估任何解决方案时，对供应链的信任都是至关重要的。
|
||||
最终，使用前述方案中的 _任何_ 一种都好过放任自流。
|
||||
|
||||
Loading…
Reference in New Issue