Skip to content

Commit dcb78b7

Browse files
windsonseawindsonsea
committed
[zh] Add application-security-checklist.md
1 parent d0f51c0 commit dcb78b7

File tree

1 file changed

+261
-0
lines changed

1 file changed

+261
-0
lines changed

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

Lines changed: 261 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,261 @@
1+
---
2+
title: 应用安全检查清单
3+
description: >
4+
一份面向应用开发者的基本指南，用于确保 Kubernetes 上应用安全
5+
content_type: concept
6+
weight: 110
7+
---
8+
<!--
9+
title: Application Security Checklist
10+
description: >
11+
Baseline guidelines around ensuring application security on Kubernetes, aimed at application developers
12+
content_type: concept
13+
weight: 110
14+
-->
15+
16+
<!-- overview -->
17+
18+
<!--
19+
This checklist aims to provide basic guidelines on securing applications
20+
running in Kubernetes from a developer's perspective.
21+
This list is not meant to be exhaustive and is intended to evolve over time.
22+
-->
23+
本检查清单旨在为开发者提供在 Kubernetes 上安全地运行应用的基本指南。
24+
此列表并不打算详尽无遗，会随着时间的推移而不断演变。
25+
26+
<!-- The following is taken from the existing checklist created for Kubernetes admins. https://kubernetes.io/docs/concepts/security/security-checklist/
27+
-->
28+
29+
<!--
30+
On how to read and use this document:
31+
32+
- The order of topics does not reflect an order of priority.
33+
- Some checklist items are detailed in the paragraph below the list of each section.
34+
- This checklist assumes that a `developer` is a Kubernetes cluster user who
35+
interacts with namespaced scope objects.
36+
-->
37+
关于如何阅读和使用本文档：
38+
39+
- 主题的顺序并不代表优先级的顺序。
40+
- 在每章节的列表下面的段落中，都详细列举了一些检查项。
41+
- 本检查清单假设“开发者”是与命名空间范围对象交互的 Kubernetes 集群用户。
42+
43+
{{< caution >}}
44+
<!--
45+
Checklists are **not** sufficient for attaining a good security posture on their own.
46+
A good security posture requires constant attention and improvement, but a checklist
47+
can be the first step on the never-ending journey towards security preparedness.
48+
Some recommendations in this checklist may be too restrictive or too lax for
49+
your specific security needs. Since Kubernetes security is not "one size fits all",
50+
each category of checklist items should be evaluated on its merits.
51+
-->
52+
单靠检查清单自身**不足以**获得良好的安全态势。
53+
实现良好的安全态势需要持续的关注和改进，实现安全上有备无患的目标道路漫长，清单可作为征程上的第一步。
54+
对于你的特定安全需求，此清单中的某些建议可能过于严格或过于宽松。
55+
由于 Kubernetes 的安全性并不是“一刀切”的，因此针对每一类检查清单项目都应该做价值评估。
56+
{{< /caution >}}
57+
58+
<!-- body -->
59+
60+
<!--
61+
## Base security hardening
62+
63+
The following checklist provides base security hardening recommendations that
64+
would apply to most applications deploying to Kubernetes.
65+
-->
66+
## 基础安全加固 {#base-security-hardening}
67+
68+
以下检查清单提供了一些适用于部署到 Kubernetes 的大多数应用的基础安全加固建议。
69+
70+
<!--
71+
### Application design
72+
73+
- [ ] Follow the right
74+
[security principles](https://www.cncf.io/wp-content/uploads/2022/06/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
75+
when designing applications.
76+
- [ ] Application configured with appropriate {{< glossary_tooltip text="QoS class" term_id="QoS-class" >}}
77+
through resource request and limits.
78+
- [ ] Memory limit is set for the workloads with a limit equal to or greater than the request.
79+
- [ ] CPU limit might be set on sensitive workloads.
80+
-->
81+
### 应用设计 {#application-design}
82+
83+
- [ ] 在设计应用时遵循正确的[安全原则](https://www.cncf.io/wp-content/uploads/2022/06/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)。
84+
- [ ] 应用通过资源请求和限制配置了适当的 {{< glossary_tooltip text="QoS 类" term_id="QoS-class" >}}。
85+
- [ ] 为工作负载设置一个内存限制，此限制等于或大于请求。
86+
- [ ] 敏感工作负载可以设置 CPU 限制。
87+
88+
<!--
89+
### Service account
90+
91+
- [ ] Avoid using the `default` ServiceAccount. Instead, create ServiceAccounts for
92+
each workload or microservice.
93+
- [ ] `automountServiceAccountToken` should be set to `false` unless the pod
94+
specifically requires access to the Kubernetes API to operate.
95+
-->
96+
### 服务账号 {#service-account}
97+
98+
- [ ] 避免使用 `default` ServiceAccount。为每个工作负载或微服务创建 ServiceAccount。
99+
- [ ] 除非 Pod 特别要求访问 Kubernetes API 进行操作，否则 `automountServiceAccountToken` 应被设置为 `false`。
100+
101+
<!--
102+
### Pod-level `securityContext` recommendations {#security-context-pod}
103+
104+
- [ ] Set `runAsNonRoot: true`.
105+
- [ ] Configure the container to execute as a less privileged user
106+
(for example, using `runAsUser` and `runAsGroup`), and configure appropriate
107+
permissions on files or directories inside the container image.
108+
- [ ] Optionally add a supplementary group with `fsGroup` to access persistent volumes.
109+
- [ ] The application deploys into a namespace that enforces an appropriate
110+
[Pod security standard](/docs/concepts/security/pod-security-standards/).
111+
If you cannot control this enforcement for the cluster(s) where the application is
112+
deployed, take this into account either through documentation or additional defense in depth.
113+
-->
114+
### Pod 级别的 `securityContext` 建议 {#security-context-pod}
115+
116+
- [ ] 设置 `runAsNonRoot: true`。
117+
- [ ] 将容器配置为以低特权用户来执行（例如，使用 `runAsUser` 和 `runAsGroup`），
118+
并在容器镜像内配置恰当的文件或目录权限。
119+
- [ ] 可以选择添加一个补充组，使用 `fsGroup` 访问持久卷。
120+
- [ ] 应用部署到强制执行适当
121+
[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)的命名空间。
122+
如果你不能控制部署应用的集群以执行此类强制操作，请通过文档说明或实施额外的深度防御来避免遗漏。
123+
124+
<!--
125+
### Container-level `securityContext` recommendations {#security-context-container}
126+
127+
- [ ] Disable privilege escalations using `allowPrivilegeEscalation: false`.
128+
- [ ] Configure the root filesystem to be read-only with `readOnlyRootFilesystem: true`.
129+
- [ ] Avoid running privileged containers (set `privileged: false`).
130+
- [ ] Drop all capabilities from the containers and add back only specific ones
131+
that are needed for operation of the container.
132+
-->
133+
### 容器级别的 `securityContext` 建议 {#security-context-container}
134+
135+
- [ ] 使用 `allowPrivilegeEscalation: false` 禁用特权提级。
136+
- [ ] 使用 `readOnlyRootFilesystem: true` 将根文件系统配置为只读。
137+
- [ ] 避免运行特权容器（设置 `privileged: false`）。
138+
- [ ] 从容器中删除所有权能，只添加容器运行所需的特定权限。
139+
140+
<!--
141+
### Role Based Access Control (RBAC) {#rbac}
142+
143+
- [ ] Permissions such as **create**, **patch**, **update** and **delete**
144+
should be only granted if necessary.
145+
- [ ] Avoid creating RBAC permissions to create or update roles which can lead to
146+
[privilege escalation](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping).
147+
- [ ] Review bindings for the `system:unauthenticated` group and remove them where
148+
possible, as this gives access to anyone who can contact the API server at a network level.
149+
-->
150+
### 基于角色的访问控制 (RBAC) {#rbac}
151+
152+
- [ ] 仅在必要时才授予 **create**、**patch**、**update** 和 **delete** 等权限。
153+
- [ ] 避免创建允许用户能够创建或更新角色的 RBAC 权限，
154+
创建了这类权限可能导致[特权提级](/zh-cn/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)。
155+
- [ ] 审查 `system:unauthenticated` 组的绑定，并在可能的情况下将其移除，
156+
因为这类绑定会为能够在网络层与 API 服务器通信的所有人提供访问权限。
157+
158+
<!--
159+
The **create**, **update** and **delete** verbs should be permitted judiciously.
160+
The **patch** verb if allowed on a Namespace can
161+
[allow users to update labels on the namespace or deployments](/docs/concepts/security/rbac-good-practices/#namespace-modification)
162+
which can increase the attack surface.
163+
164+
For sensitive workloads, consider providing a recommended ValidatingAdmissionPolicy
165+
that further restricts the permitted write actions.
166+
-->
167+
对 **create**、**update** 和 **delete** 动词的授权要非常谨慎。
168+
如果允许针对 Namespace 对象使用 **patch** 动词，
169+
可能会[允许用户更新命名空间或部署上的标签](/zh-cn/docs/concepts/security/rbac-good-practices/#namespace-modification)，
170+
这可能会增加攻击面。
171+
172+
对于敏感工作负载，考虑提供推荐的 ValidatingAdmissionPolicy 以进一步限制允许的写入操作。
173+
174+
<!--
175+
### Image security
176+
177+
- [ ] Using an image scanning tool to scan an image before deploying containers in the Kubernetes cluster.
178+
- [ ] Use container signing to validate the container image signature before deploying to the Kubernetes cluster.
179+
-->
180+
### 镜像安全 {#image-security}
181+
182+
- [ ] 使用镜像扫描工具在将容器部署到 Kubernetes 集群之前扫描镜像。
183+
- [ ] 使用容器签名在将容器部署到 Kubernetes 集群之前验证容器镜像签名。
184+
185+
<!--
186+
### Network policies
187+
188+
- [ ] Configure [NetworkPolicies](/docs/concepts/services-networking/network-policies/)
189+
to only allow expected ingress and egress traffic from the pods.
190+
191+
Make sure that your cluster provides and enforces NetworkPolicy.
192+
If you are writing an application that users will deploy to different clusters,
193+
consider whether you can assume that NetworkPolicy is available and enforced.
194+
-->
195+
### 网络策略 {#netowrk-policies}
196+
197+
- [ ] 配置 [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/)，
198+
仅允许来自 Pod 的预期入站和出站流量。
199+
200+
确保你的集群提供并强制执行 NetworkPolicy。
201+
如果你所编写的应用将被人们部署到不同集群中，请考虑你是否可以假设 NetworkPolicy 可用且被启用。
202+
203+
<!--
204+
## Advanced security hardening {#advanced}
205+
206+
This section of this guide covers some advanced security hardening points
207+
which might be valuable based on different Kubernetes environment setup.
208+
-->
209+
## 高级安全加固 {#advanced}
210+
211+
本指南的这一节涵盖了一些高级安全加固要点，这些要点可能在不同 Kubernetes 环境设置中有用。
212+
213+
<!--
214+
### Linux container security
215+
216+
Configure {{< glossary_tooltip text="Security Context" term_id="Security-Context" >}}
217+
for the pod-container.
218+
219+
- [ ] [Set the Seccomp Profile for a Container](/docs/tasks/configure-pod-container/security-context/#set-the-seccomp-profile-for-a-container).
220+
- [ ] [Restrict a Container's Access to Resources with AppArmor](/docs/tutorials/security/apparmor/).
221+
- [ ] [Assign SELinux Labels to a Container](/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container).
222+
-->
223+
### Linux 容器安全 {#linux-container-security}
224+
225+
为 Pod 容器配置 {{< glossary_tooltip text="安全上下文" term_id="Security-Context" >}}。
226+
227+
- [ ] [为容器设置 Seccomp 配置](/zh-cn/docs/tasks/configure-pod-container/security-context/#set-the-seccomp-profile-for-a-container)。
228+
- [ ] [使用 AppArmor 限制容器对资源的访问](/zh-cn/docs/tutorials/security/apparmor/)。
229+
- [ ] [为容器赋予 SELinux 标签](/zh-cn/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container)。
230+
231+
<!--
232+
### Runtime Classes
233+
234+
- [ ] Configure appropriate runtime classes for containers.
235+
-->
236+
### 运行时类 {#runtime-classes}
237+
238+
- [ ] 为容器配置适当的运行时类。
239+
240+
{{% thirdparty-content %}}
241+
242+
<!--
243+
Some containers may require a different isolation level from what is provided by
244+
the default runtime of the cluster. `runtimeClassName` can be used in a podspec
245+
to define a different runtime class.
246+
247+
For sensitive workloads consider using kernel emulation tools like
248+
[gVisor](https://gvisor.dev/docs/), or virtualized isolation using a mechanism
249+
such as [kata-containers](https://katacontainers.io/).
250+
251+
In high trust environments, consider using
252+
[confidential virtual machines](/blog/2023/07/06/confidential-kubernetes/)
253+
to improve cluster security even further.
254+
-->
255+
某些容器可能需要不同于集群默认运行时所提供的隔离级别。
256+
你可以在 Pod 规约中使用 `runtimeClassName` 定义不同的运行时类。
257+
258+
对于敏感的工作负载，考虑使用 [gVisor](https://gvisor.dev/docs/) 这类内核仿真工具，
259+
或使用 [kata-containers](https://katacontainers.io/) 等机制进行虚拟化隔离。
260+
261+
在高度信任的环境中，考虑使用[机密虚拟机](/zh-cn/blog/2023/07/06/confidential-kubernetes/)进一步提高集群安全性。

0 commit comments

Comments
 (0)