[zh] sync security-checklist.md
parent
45fc4852fe
commit
19a8c3e2d9
|
@ -28,6 +28,7 @@ On how to read and use this document:
|
|||
此清单不求详尽无遗,是预计会不断演化的。
|
||||
|
||||
关于如何阅读和使用本文档:
|
||||
|
||||
- 主题的顺序并不代表优先级的顺序。
|
||||
- 在每章节的列表下面的段落中,都详细列举了一些检查清项目。
|
||||
|
||||
|
@ -101,7 +102,7 @@ an admin user.
|
|||
|
||||
- [ ] 使用的 CNI 插件可支持网络策略。
|
||||
- [ ] 对集群中的所有工作负载应用入站和出站的网络策略。
|
||||
- [ ] 落实每个名称空间内的默认网络策略,覆盖所有 Pod,拒绝一切访问。
|
||||
- [ ] 落实每个名字空间内的默认网络策略,覆盖所有 Pod,拒绝一切访问。
|
||||
- [ ] 如果合适,使用服务网格来加密集群内的所有通信。
|
||||
- [ ] 不在互联网上公开 Kubernetes API、kubelet API 和 etcd。
|
||||
- [ ] 过滤工作负载对云元数据 API 的访问。
|
||||
|
@ -120,8 +121,8 @@ is missed.
|
|||
许多[容器网络接口(Container Network Interface,CNI)插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)提供了限制
|
||||
Pod 可能与之通信的网络资源的功能。
|
||||
这种限制通常通过[网络策略](/zh-cn/docs/concepts/services-networking/network-policies/)来完成,
|
||||
网络策略提供了一种名称空间作用域的资源来定义规则。
|
||||
在每个名称空间中,默认的网络策略会阻塞所有的出入站流量,并选择所有 Pod,
|
||||
网络策略提供了一种名字空间作用域的资源来定义规则。
|
||||
在每个名字空间中,默认的网络策略会阻塞所有的出入站流量,并选择所有 Pod,
|
||||
采用允许列表的方法很有用,可以确保不遗漏任何工作负载。
|
||||
|
||||
<!--
|
||||
|
@ -226,8 +227,8 @@ admission can be easily combined with admission webhooks and external services.
|
|||
[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)定义了三种不同的策略:
|
||||
特权策略(Privileged)、基线策略(Baseline)和限制策略(Restricted),它们限制了 `PodSpec` 中关于安全的字段的设置。
|
||||
这些标准可以通过默认启用的新的
|
||||
[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入 Webhook 在名称空间级别强制执行。
|
||||
请注意,与它所取代的、已被删除的 PodSecurityPolicy 准入机制相反,
|
||||
[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入 Webhook 在名字空间级别强制执行。
|
||||
请注意,与它所取代的、已被移除的 PodSecurityPolicy 准入机制相反,
|
||||
[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)可以轻松地与准入 Webhook 和外部服务相结合使用。
|
||||
|
||||
<!--
|
||||
|
@ -307,7 +308,6 @@ profile can be found [in containerd](https://github.com/containerd/containerd/bl
|
|||
as well. Fortunately, [Seccomp Default](/blog/2021/08/25/seccomp-default/), a
|
||||
new alpha feature to use a default seccomp profile for all workloads can now be
|
||||
enabled and tested.
|
||||
|
||||
-->
|
||||
从历史背景看,请注意 Docker 自 2016 年以来一直使用[默认的 Seccomp 配置文件](https://docs.docker.com/engine/security/seccomp/),
|
||||
仅允许来自 [Docker Engine 1.10](https://www.docker.com/blog/docker-engine-1-10-security/) 的很小的一组系统调用,
|
||||
|
@ -342,7 +342,7 @@ 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 内核安全模块,
|
||||
可以提供一种简单的方法来实现强制访问控制(Mandatory Access Control, MAC)并通过系统日志进行更好地审计。
|
||||
可以提供一种简单的方法来实现强制访问控制(Mandatory Access Control, MAC)并通过系统日志进行更好地审计。
|
||||
要在 Kubernetes 中[启用 AppArmor](/zh-cn/docs/tutorials/security/apparmor/),至少需要 1.4 版本。
|
||||
与 Seccomp 一样,AppArmor 也通过配置文件进行配置,
|
||||
其中每个配置文件要么在强制(Enforcing)模式下运行,即阻止访问不允许的资源,要么在投诉(Complaining)模式下运行,只报告违规行为。
|
||||
|
@ -508,15 +508,16 @@ for time-bound service account credentials.
|
|||
- [ ] Container images are configured to be run as unprivileged user.
|
||||
- [ ] References to container images are made by sha256 digests (rather than
|
||||
tags) or the provenance of the image is validated by verifying the image's
|
||||
digital signature at deploy time [via admission control](/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller).
|
||||
digital signature at deploy time [via admission control](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller).
|
||||
- [ ] Container images are regularly scanned during creation and in deployment, and
|
||||
known vulnerable software is patched.
|
||||
-->
|
||||
## 镜像 {#images}
|
||||
|
||||
- [ ] 尽量减少容器镜像中不必要的内容。
|
||||
- [ ] 容器镜像配置为以非特权用户身份运行。
|
||||
- [ ] 对容器镜像的引用是通过 Sha256 摘要实现的,而不是标签(tags),
|
||||
或者[通过准入控制器](/zh-cn/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller)在部署时验证镜像的数字签名来验证镜像的来源。
|
||||
或者[通过准入控制器](/zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller)在部署时验证镜像的数字签名来验证镜像的来源。
|
||||
- [ ] 在创建和部署过程中定期扫描容器镜像,并对已知的漏洞软件进行修补。
|
||||
|
||||
<!--
|
||||
|
@ -553,14 +554,14 @@ Avoid using image tags to reference an image, especially the `latest` tag, the
|
|||
image behind a tag can be easily modified in a registry. Prefer using the
|
||||
complete `sha256` digest which is unique to the image manifest. This policy can be
|
||||
enforced via an [ImagePolicyWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook).
|
||||
Image signatures can also be automatically [verified with an admission controller](/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller)
|
||||
Image signatures can also be automatically [verified with an admission controller](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller)
|
||||
at deploy time to validate their authenticity and integrity.
|
||||
-->
|
||||
避免使用镜像标签来引用镜像,尤其是 `latest` 标签,因为标签对应的镜像可以在仓库中被轻松地修改。
|
||||
首选使用完整的 `Sha256` 摘要,该摘要对特定镜像清单文件而言是唯一的。
|
||||
可以通过 [ImagePolicyWebhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
|
||||
强制执行此策略。
|
||||
镜像签名还可以在部署时由[准入控制器自动验证](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook),
|
||||
镜像签名还可以在部署时由[准入控制器自动验证](/zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller),
|
||||
以验证其真实性和完整性。
|
||||
|
||||
<!--
|
||||
|
@ -642,7 +643,7 @@ permission to sign certificate requests.
|
|||
attribute') of `system:masters`.
|
||||
-->
|
||||
[`CertificateSubjectRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction)
|
||||
: 拒绝将 `group`(或 `organization attribute` )设置为 `system:masters` 的所有证书请求。
|
||||
: 拒绝将 `group`(或 `organization attribute`)设置为 `system:masters` 的所有证书请求。
|
||||
|
||||
<!--
|
||||
[`LimitRanger`](/docs/reference/access-authn-authz/admission-controllers/#limitranger)
|
||||
|
@ -741,7 +742,7 @@ has permissions to use the image.
|
|||
- [Blog post "A Closer Look at NSA/CISA Kubernetes Hardening Guidance"](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#building-secure-container-images)
|
||||
for complementary resource on hardening Kubernetes clusters.
|
||||
-->
|
||||
## 接下来
|
||||
## 接下来 {#what-is-next}
|
||||
|
||||
- [RBAC 良好实践](/zh-cn/docs/concepts/security/rbac-good-practices/)提供有关授权的更多信息。
|
||||
- [集群多租户指南](/zh-cn/docs/concepts/security/multi-tenancy/)提供有关多租户的配置选项建议和最佳实践。
|
||||
|
|
Loading…
Reference in New Issue