[zh] Translate concepts/security/pod-security-standards.md
Qiming Teng
parent
bdd04151a8
commit
cd47cf8820
|
|
@ -0,0 +1,519 @@
|
|||
---
|
||||
title: Pod 安全性标准
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- tallclair
|
||||
title: Pod Security Standards
|
||||
content_type: concept
|
||||
weight: 10
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Security settings for Pods are typically applied by using [security
|
||||
contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the
|
||||
definition of privilege and access controls on a per-Pod basis.
|
||||
|
||||
The enforcement and policy-based definition of cluster requirements of security contexts has
|
||||
previously been achieved using [Pod Security Policy](/docs/concepts/policy/pod-security-policy/). A
|
||||
_Pod Security Policy_ is a cluster-level resource that controls security sensitive aspects of the
|
||||
Pod specification.
|
||||
|
||||
However, numerous means of policy enforcement have arisen that augment or replace the use of
|
||||
PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled
|
||||
from any specific instantiation.
|
||||
-->
|
||||
Pod 的安全性配置一般通过使用
|
||||
[安全性上下文（Security Context）](/zh/docs/tasks/configure-pod-container/security-context/)
|
||||
来保证。安全性上下文允许用户逐个 Pod 地定义特权级及访问控制。
|
||||
|
||||
以前，对集群的安全性上下文的需求的实施及其基于策略的定义都通过使用
|
||||
[Pod 安全性策略](/zh/docs/concepts/policy/pod-security-policy/)来实现。
|
||||
_Pod 安全性策略（Pod Security Policy）_ 是一种集群层面的资源，控制 Pod 规约中
|
||||
安全性敏感的部分。
|
||||
|
||||
不过，新的策略实施方式不断涌现，或增强或替换 PodSecurityPolicy 的使用。
|
||||
本页的目的是详细介绍建议实施的 Pod 安全框架；这些内容与具体的实现无关。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Policy Types
|
||||
|
||||
There is an immediate need for base policy definitions to broadly cover the security spectrum. These
|
||||
should range from highly restricted to highly flexible:
|
||||
|
||||
- **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This
|
||||
policy allows for known privilege escalations.
|
||||
- **_Baseline/Default_** - Minimally restrictive policy while preventing known privilege
|
||||
escalations. Allows the default (minimally specified) Pod configuration.
|
||||
- **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices.
|
||||
-->
|
||||
## 策略类型 {#policy-types}
|
||||
|
||||
在进一步讨论整个策略谱系之前，有必要对基本的策略下个定义。
|
||||
策略可以是很严格的也可以是很宽松的：
|
||||
|
||||
- **_Privileged_** - 不受限制的策略，提供最大可能范围的权限许可。这些策略
|
||||
允许已知的特权提升。
|
||||
- **_Baseline/Default_** - 限制性最弱的策略，禁止已知的策略提升。
|
||||
允许使用默认的（规定最少）Pod 配置。
|
||||
- **_Restricted_** - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。
|
||||
|
||||
<!--
|
||||
## Policies
|
||||
|
||||
### Privileged
|
||||
-->
|
||||
## 策略 {#policies}
|
||||
|
||||
### 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 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
|
||||
rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
|
||||
Security Policy) the privileged policy should enable all controls (disable all restrictions).
|
||||
-->
|
||||
Privileged 策略是有目的地开放且完全无限制的策略。此类策略通常针对由
|
||||
特权较高、受信任的用户所管理的系统级或基础设施级负载。
|
||||
|
||||
Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper），
|
||||
Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。
|
||||
与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言，
|
||||
Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
|
||||
|
||||
### Baseline/Default
|
||||
|
||||
<!--
|
||||
The Baseline/Default policy is aimed at ease of adoption for common containerized workloads while
|
||||
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:
|
||||
-->
|
||||
Baseline/Default 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。
|
||||
此策略针对的是应用运维人员和非关键性应用的开发人员。
|
||||
下面列举的控制应该被实施（禁止）：
|
||||
|
||||
<table>
|
||||
<!-- caption style="display:none">Baseline policy specification</caption -->
|
||||
<caption style="display:none">Baseline 策略规范</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td width="30%"><strong>控制（Control）</strong></td>
|
||||
<td><strong>策略（Policy）</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Host Namespaces</td -->
|
||||
<td>宿主名字空间</td>
|
||||
<!-- td>
|
||||
Sharing the host namespaces must be disallowed.<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.hostNetwork<br>
|
||||
spec.hostPID<br>
|
||||
spec.hostIPC<br>
|
||||
<br><b>Allowed Values:</b> false<br>
|
||||
</td -->
|
||||
<td>
|
||||
必须禁止共享宿主名字空间。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.hostNetwork<br>
|
||||
spec.hostPID<br>
|
||||
spec.hostIPC<br>
|
||||
<br><b>允许的值：</b> false<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Privileged Containers</td -->
|
||||
<td>特权容器</td>
|
||||
<!-- td>
|
||||
Privileged Pods disable most security mechanisms and must be disallowed.<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].securityContext.privileged<br>
|
||||
spec.initContainers[*].securityContext.privileged<br>
|
||||
<br><b>Allowed Values:</b> false, undefined/nil<br>
|
||||
</td -->
|
||||
<td>
|
||||
特权 Pod 禁用大多数安全性机制，必须被禁止。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].securityContext.privileged<br>
|
||||
spec.initContainers[*].securityContext.privileged<br>
|
||||
<br><b>允许的值：</b> false、未定义/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Capabilities</td -->
|
||||
<td>权能</td>
|
||||
<!-- td>
|
||||
Adding additional capabilities beyond the <a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">default set</a> must be disallowed.<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].securityContext.capabilities.add<br>
|
||||
spec.initContainers[*].securityContext.capabilities.add<br>
|
||||
<br><b>Allowed Values:</b> empty (or restricted to a known list)<br>
|
||||
</td -->
|
||||
<td>
|
||||
必须禁止添加<a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">默认集合</a>之外的权能。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].securityContext.capabilities.add<br>
|
||||
spec.initContainers[*].securityContext.capabilities.add<br>
|
||||
<br><b>允许的值：</b> 空（或限定为一个已知列表）<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>HostPath Volumes</td -->
|
||||
<td>HostPath 卷</td>
|
||||
<!-- td>
|
||||
HostPath volumes must be forbidden.<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.volumes[*].hostPath<br>
|
||||
<br><b>Allowed Values:</b> undefined/nil<br>
|
||||
</td -->
|
||||
<td>
|
||||
必须禁止 HostPath 卷。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.volumes[*].hostPath<br>
|
||||
<br><b>允许的值：</b> 未定义/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Host Ports</td -->
|
||||
<td>宿主端口</td>
|
||||
<!-- td>
|
||||
HostPorts should be disallowed, or at minimum restricted to a known list.<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].ports[*].hostPort<br>
|
||||
spec.initContainers[*].ports[*].hostPort<br>
|
||||
<br><b>Allowed Values:</b> 0, undefined (or restricted to a known list)<br>
|
||||
</td -->
|
||||
<td>
|
||||
应禁止使用宿主端口，或者至少限定为已知列表。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].ports[*].hostPort<br>
|
||||
spec.initContainers[*].ports[*].hostPort<br>
|
||||
<br><b>允许的值：</b> 0、未定义（或限定为已知列表）<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>AppArmor <em>(optional)</em></td -->
|
||||
<td>AppArmor <em>（可选）</em></td>
|
||||
<!-- td>
|
||||
On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
|
||||
<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
|
||||
</td -->
|
||||
<td>
|
||||
在受支持的宿主上，默认应用 'runtime/default' AppArmor Profile。默认策略应禁止重载或者禁用该策略，或将重载限定未所允许的 profile 集合。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
|
||||
<br><b>允许的值：</b> 'runtime/default'、未定义<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>SELinux <em>(optional)</em></td -->
|
||||
<td>SELinux <em>（可选）</em></td>
|
||||
<!-- td>
|
||||
Setting custom SELinux options should be disallowed.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.securityContext.seLinuxOptions<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions<br>
|
||||
<br><b>Allowed Values:</b> undefined/nil<br>
|
||||
</td -->
|
||||
<td>
|
||||
应禁止设置定制的 SELinux 选项。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.securityContext.seLinuxOptions<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions<br>
|
||||
<br><b>允许的值：</b> undefined/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>/proc Mount Type</td -->
|
||||
<td>/proc 挂载类型</td>
|
||||
<!-- td>
|
||||
The default /proc masks are set up to reduce attack surface, and should be required.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.containers[*].securityContext.procMount<br>
|
||||
spec.initContainers[*].securityContext.procMount<br>
|
||||
<br><b>Allowed Values:</b> undefined/nil, 'Default'<br>
|
||||
</td -->
|
||||
<td>
|
||||
要求使用默认的 <code>/proc</code> 掩码以减小攻击面。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].securityContext.procMount<br>
|
||||
spec.initContainers[*].securityContext.procMount<br>
|
||||
<br><b>允许的值：</b> 未定义/nil、'Default'<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Sysctls</td>
|
||||
<!-- td>
|
||||
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.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.securityContext.sysctls<br>
|
||||
<br><b>Allowed Values:</b><br>
|
||||
kernel.shm_rmid_forced<br>
|
||||
net.ipv4.ip_local_port_range<br>
|
||||
net.ipv4.tcp_syncookies<br>
|
||||
net.ipv4.ping_group_range<br>
|
||||
undefined/empty<br>
|
||||
</td -->
|
||||
<td>
|
||||
Sysctls 可以禁用安全机制或影响宿主上所有容器，因此除了若干『安全』的子集之外，应该被禁止。
|
||||
如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.securityContext.sysctls<br>
|
||||
<br><b>允许的值：</b><br>
|
||||
kernel.shm_rmid_forced<br>
|
||||
net.ipv4.ip_local_port_range<br>
|
||||
net.ipv4.tcp_syncookies<br>
|
||||
net.ipv4.ping_group_range<br>
|
||||
undefined/empty<br>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Restricted
|
||||
|
||||
<!--
|
||||
The Restricted policy is aimed at enforcing current Pod hardening best practices, at the expense of
|
||||
some compatibility. It is targeted at operators and developers of security-critical applications, as
|
||||
well as lower-trust users.The following listed controls should be enforced/disallowed:
|
||||
-->
|
||||
Restricted 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作可能会牺牲一些兼容性。
|
||||
该类策略主要针对运维人员和安全性很重要的应用的开发人员，以及不太被信任的用户。
|
||||
下面列举的控制需要被实施（禁止）：
|
||||
|
||||
<table>
|
||||
<!-- caption style="display:none">Restricted policy specification</caption -->
|
||||
<caption style="display:none">Restricted 策略规范</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<!-- td><strong>Control</strong></td -->
|
||||
<td width="30%"><strong>控制（Control）</strong></td>
|
||||
<!-- td><strong>Policy</strong></td -->
|
||||
<td><strong>策略（Policy）</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td colspan="2"><em>Everything from the default profile.</em></td -->
|
||||
<td colspan="2"><em>Default 策略的所有要求。</em></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Volume Types</td -->
|
||||
<td>卷类型</td>
|
||||
<td>
|
||||
<!-- In addition to restricting HostPath volumes, the restricted profile limits usage of non-core volume types to those defined through PersistentVolumes. -->
|
||||
除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.volumes[*].hostPath<br>
|
||||
spec.volumes[*].gcePersistentDisk<br>
|
||||
spec.volumes[*].awsElasticBlockStore<br>
|
||||
spec.volumes[*].gitRepo<br>
|
||||
spec.volumes[*].nfs<br>
|
||||
spec.volumes[*].iscsi<br>
|
||||
spec.volumes[*].glusterfs<br>
|
||||
spec.volumes[*].rbd<br>
|
||||
spec.volumes[*].flexVolume<br>
|
||||
spec.volumes[*].cinder<br>
|
||||
spec.volumes[*].cephFS<br>
|
||||
spec.volumes[*].flocker<br>
|
||||
spec.volumes[*].fc<br>
|
||||
spec.volumes[*].azureFile<br>
|
||||
spec.volumes[*].vsphereVolume<br>
|
||||
spec.volumes[*].quobyte<br>
|
||||
spec.volumes[*].azureDisk<br>
|
||||
spec.volumes[*].portworxVolume<br>
|
||||
spec.volumes[*].scaleIO<br>
|
||||
spec.volumes[*].storageos<br>
|
||||
spec.volumes[*].csi<br>
|
||||
<br><b>允许的值：</b> 未定义/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Privilege Escalation</td -->
|
||||
<td>特权提升</td>
|
||||
<td>
|
||||
<!-- Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. -->
|
||||
禁止（通过 SetUID 或 SetGID 文件模式）获得特权提升。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.containers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
spec.initContainers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
<br><b>允许的值：</b> false<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Running as Non-root</td -->
|
||||
<td>以非 root 账号运行 </td>
|
||||
<td>
|
||||
<!-- Containers must be required to run as non-root users. -->
|
||||
必须要求容器以非 root 用户运行。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.securityContext.runAsNonRoot<br>
|
||||
spec.containers[*].securityContext.runAsNonRoot<br>
|
||||
spec.initContainers[*].securityContext.runAsNonRoot<br>
|
||||
<br><b>允许的值：</b> true<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<!-- td>Non-root groups <em>(optional)</em></td -->
|
||||
<td>非 root 组 <em>（可选）</em></td>
|
||||
<td>
|
||||
<!-- Containers should be forbidden from running with a root primary or supplementary GID. -->
|
||||
禁止容器使用 root 作为主要或辅助 GID 来运行。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
spec.securityContext.runAsGroup<br>
|
||||
spec.securityContext.supplementalGroups[*]<br>
|
||||
spec.securityContext.fsGroup<br>
|
||||
spec.containers[*].securityContext.runAsGroup<br>
|
||||
spec.initContainers[*].securityContext.runAsGroup<br>
|
||||
<br><b>允许的值：</b><br>
|
||||
非零值<br>
|
||||
未定义/nil （<code>*.runAsGroup</code> 除外）<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Seccomp</td>
|
||||
<td>
|
||||
<!-- The 'runtime/default' seccomp profile must be required, or allow specific additional profiles. -->
|
||||
必须要求使用 'runtime/default' seccomp profile 或者允许使用特定的 profiles。<br>
|
||||
<br><b>限制的字段：</b><br>
|
||||
metadata.annotations['seccomp.security.alpha.kubernetes.io/pod']<br>
|
||||
metadata.annotations['container.seccomp.security.alpha.kubernetes.io/*']<br>
|
||||
<br><b>允许的值：</b><br>
|
||||
'runtime/default'<br>
|
||||
未定义（容器注解）<br>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
## Policy Instantiation
|
||||
|
||||
Decoupling policy definition from policy instantiation allows for a common understanding and
|
||||
consistent language of policies across clusters, independent of the underlying enforcement
|
||||
mechanism.
|
||||
|
||||
As mechanisms mature, they will be defined below on a per-policy basis. The methods of enforcement
|
||||
of individual policies are not defined here.
|
||||
-->
|
||||
## 策略实例化 {#policy-instantiation}
|
||||
|
||||
将策略定义从策略实例中解耦出来有助于形成跨集群的策略理解和语言陈述，
|
||||
以免绑定到特定的下层实施机制。
|
||||
|
||||
随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。
|
||||
|
||||
[**PodSecurityPolicy**](/zh/docs/concepts/policy/pod-security-policy/)
|
||||
|
||||
- [Privileged](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml)
|
||||
- [Baseline](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml)
|
||||
- [Restricted](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml)
|
||||
|
||||
<!--
|
||||
## FAQ
|
||||
|
||||
### Why isn't there a profile between privileged and default?
|
||||
-->
|
||||
## 常见问题 {#faq}
|
||||
|
||||
### 为什么策略类型定义在 Privileged 和 Default 之间
|
||||
|
||||
<!--
|
||||
The three profiles defined here have a clear linear progression from most secure (restricted) to least
|
||||
secure (privileged), and cover a broad set of workloads. Privileges required above the baseline
|
||||
policy are typically very application specific, so we do not offer a standard profile in this
|
||||
niche. This is not to say that the privileged profile should always be used in this case, but that
|
||||
policies in this space need to be defined on a case-by-case basis.
|
||||
|
||||
SIG Auth may reconsider this position in the future, should a clear need for other profiles arise.
|
||||
-->
|
||||
这里定义的三种策略框架有一个明晰的线性递进关系，从最安全（Restricted）到最不安全，
|
||||
并且覆盖了很大范围的工作负载。特权要求超出 Baseline 策略者通常是特定于应用的需求，
|
||||
所以我们没有在这个范围内提供标准框架。
|
||||
这并不意味着在这样的情形下仍然只能使用 Privileged 框架，只是说处于这个范围的
|
||||
策略需要因地制宜地定义。
|
||||
|
||||
SIG Auth 可能会在将来考虑这个范围的框架，前提是有对其他框架的需求。
|
||||
|
||||
<!--
|
||||
### What's the difference between a security policy and a security context?
|
||||
|
||||
[Security Contexts](/docs/tasks/configure-pod-container/security-context/) configure Pods and
|
||||
Containers at runtime. Security contexts are defined as part of the Pod and container specifications
|
||||
in the Pod manifest, and represent parameters to the container runtime.
|
||||
-->
|
||||
### 安全策略与安全上下文的区别是什么？
|
||||
|
||||
[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod
|
||||
和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的，所代表的是
|
||||
传递给容器运行时的参数。
|
||||
|
||||
<!--
|
||||
Security policies are control plane mechanisms to enforce specific settings in the Security Context,
|
||||
as well as other parameters outside the Security Contex. As of February 2020, the current native
|
||||
solution for enforcing these security policies is [Pod Security
|
||||
Policy](/docs/concepts/policy/pod-security-policy/) - a mechanism for centrally enforcing security
|
||||
policy on Pods across a cluster. Other alternatives for enforcing security policy are being
|
||||
developed in the Kubernetes ecosystem, such as [OPA
|
||||
Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
|
||||
-->
|
||||
安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。
|
||||
在 2020 年 2 月，目前实施这些安全性策略的原生解决方案是
|
||||
[Pod 安全性策略](/zh/docs/concepts/policy/pod-security-policy/) - 一种对集群中
|
||||
Pod 的安全性策略进行集中控制的机制。
|
||||
Kubernetes 生态系统中还在开发一些其他的替代方案，例如
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)。
|
||||
|
||||
<!--
|
||||
### What profiles should I apply to my Windows Pods?
|
||||
|
||||
Windows in Kubernetes has some limitations and differentiators from standard Linux-based
|
||||
workloads. Specifically, the Pod SecurityContext fields [have no effect on
|
||||
Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As
|
||||
such, no standardized Pod Security profiles currently exists.
|
||||
-->
|
||||
### 我应该为我的 Windows Pod 实施哪种框架？
|
||||
|
||||
Kubernetes 中的 Windows 负载与标准的基于 Linux 的负载相比有一些局限性和区别。
|
||||
尤其是 Pod SecurityContext 字段
|
||||
[对 Windows 不起作用](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
|
||||
因此，目前没有对应的标准 Pod 安全性框架。
|
||||
|
||||
<!--
|
||||
### What about sandboxed Pods?
|
||||
|
||||
There is not currently an API standard that controls whether a Pod is considered sandboxed or
|
||||
not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata
|
||||
Containers), but there is no standard definition of what a sandboxed runtime is.
|
||||
|
||||
The protections necessary for sandboxed workloads can differ from others. For example, the need to
|
||||
restrict privileged permissions is lessened when the workload is isolated from the underlying
|
||||
kernel. This allows for workloads requiring heightened permissions to still be isolated.
|
||||
|
||||
Additionally, the protection of sandboxed workloads is highly dependent on the method of
|
||||
sandboxing. As such, no single ‘recommended’ policy is recommended for all sandboxed workloads.
|
||||
-->
|
||||
### 沙箱（Sandboxed） Pod 怎么处理？
|
||||
|
||||
现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。
|
||||
沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，不过
|
||||
目前还没有关于什么是沙箱化运行时的标准定义。
|
||||
|
||||
沙箱化负载所需要的保护可能彼此各不相同。例如，当负载与下层内核直接隔离开来时，
|
||||
限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。
|
||||
|
||||
此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。
|
||||
因此，现在还没有针对所有沙箱化负载的“建议”策略。
|
||||
|
||||
Loading…
Reference in New Issue