[zh] sync security-checklist.md

pull/38373/head
windsonsea 2022-12-10 13:18:59 +08:00
parent 45fc4852fe
commit 19a8c3e2d9
1 changed files with 14 additions and 13 deletions

View File

@ -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 InterfaceCNI插件](/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/)提供有关多租户的配置选项建议和最佳实践。