| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保将 API Server 的 pod 配置文件权限设置为 600 或更严格的限制 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保 API Server 的 pod 配置文件所有权设置为 root: root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保将 Controller Manager 的 pod 配置文件权限设置为 600 或更严格的限制 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保 Controller Manager 的 pod 配置文件所有权设置为root：root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保将 Scheduler 的 pod 配置文件权限设置为 600 或更高限制性的权限 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保将 Scheduler 的 pod 配置文件所有权设置为 root: root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保将 etcd 的 pod 配置文件权限设置为 600 或更高限制性的权限 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保将 etcd 的 pod 配置文件所有权设置为 root: root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 |
| 确保将 CNI 配置文件的权限设置为 644 或更严格的限制性 | 通过 | 无 |
| 确保 CNI 配置文件的所有权设置为 root: root | 通过 | 无 |
| 确保将 etcd 数据目录权限设置为 700 或更严格的限制性 | 通过 | 无 |
| 确保将 etcd 数据目录所有权设置为 etcd: etcd 或 root: root | 通过 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。对应的数据目录通过 PVC 挂载进容器。由于 etcd 以 root 用户运行，因此其数据目录的 owner 也设置为归属于 root:root。我们认为 root 用户可等效为 etcd 用户。 |
| 确保将 admin.conf 文件权限设置为 600 或更严格的限制 | 不涉及 | 不存在 admin.conf 文件。 |
| 确保将 admin.conf 文件的所有权设置为 root:root | 不涉及 | 不存在 admin.conf 文件。 |
| 确保将 scheduler.conf 文件权限设置为 600 或更严格的限制 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 确保将 scheduler.conf 文件所有权设置为root: root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 确保将 controller-manager.conf 文件权限设置为 600 或更严格的限制 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 确保将 controller-manager.conf 文件所有权设置为 root: root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 确保将 Kubernetes PKI 目录和文件所有权设置为 root: root | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 确保将 Kubernetes PKI 证书文件权限设置为 644 或更严格的限制性 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 确保将 Kubernetes PKI 密钥文件权限设置为 600 | 不涉及 | VKE 使用 K8s on K8s 机制，控制面以 Deployment 方式启用，不涉及主机上该文件权限问题。 对于组件启动需要的文件 ConfigMap，以 Volume 方式挂载到容器的方式使用，挂载权限是 644。 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保 API Server 的 --anonymous-auth 参数设置为 false | 不通过 | VKE 因健康检查和资源发现目的而允许匿名访问 API Server。与此同时，VKE 默认强制启用 RBAC Authorization Mode，默认情况下不会授予 Anonymous 访问其他敏感 API 的权限。 |
| 确保 API Server 未设置 --token-auth-file 参数 | 通过 | 无 |
| 确保 API Server 未设置 --DenyServiceExternalIPs 参数 | 通过 | 无 |
| 确保 API Server 的 --kubelet-client-certificate 和 --kubelet-client-key 参数设置正确 | 通过 | 无 |
| 确保 API Server 的 --kubelet-certificate-authority 参数设置了正确的 kubelet CA 证书 | 通过 | 无 |
| 确保 API Server 的 --authorization-mode 参数未设置为 AlwaysAllow | 通过 | 无 |
| 确保 API Server 的 --authorization-mode 参数包含 Node | 通过 | 无 |
| 确保 API Server 的 --authorization-mode 参数包含 RBAC | 通过 | 无 |
| 确保已设置准入控制插件 EventRateLimit | 通过 | 无 |
| 确保未设置准入控制插件 AlwaysAdmit | 通过 | 无 |
| 确保已设置准入控制插件 AlwaysPullImages | 通过 | 无 |
| 如果未使用 PodSecurityPolicy，请确保设置了准入控制插件 SecurityContextDeny | 不通过 | 默认情况下，VKE 不会启用安全上下文准许控制器。使用 Pod 安全政策可以实现更多的控制，建议使用此政策。 |
| 确保已设置准入控制插件 ServiceAccount | 通过 | 无 |
| 确保已设置准入控制插件 NamespaceLifecycle | 通过 | 无 |
| 确保已设置准入控制插件 NodeRestriction | 通过 | 无 |
| 确保 API Server 的 --secure-port 参数未设置为 0 | 通过 | 无 |
| 确保 API Server 的 --profiling 参数设置为 false | 不通过 | VKE 使用性能剖析进行调试。 |
| 确保 API Server 的 --audit-log-path 参数 | 不通过 | 产品能力，需要用户自行开启审计能力，默认不开启审计功能。如果开启审计功能，该规则通过。 |
| 确保将 API Server 的 --audit-log-maxage 参数设置为 30 或适当的设置 | 不通过 | 产品能力，需要用户自行开启审计能力，默认不开启审计功能。如果开启审计功能，该规则通过。 |
| 确保将 API Server 的 --audit-log-maxbackup 参数设置为 10 或适当的设置 | 不通过 | 产品能力，需要用户自行开启审计能力，默认不开启审计功能。如果开启审计功能，该规则通过。 |
| 确保将 API Server 的 --audit-log-maxsize参数设置为 100 或适当的设置 | 不通过 | 产品能力，需要用户自行开启审计能力，默认不开启审计功能。如果开启审计功能，该规则通过。 |
| 确保 API Server 的 --request-timeout 参数设置为适当的值 | 不通过 | VKE 使用社区默认值 1m0s。 |
| 确保 API Server 的 --service-account-lookup 参数设置为 true | 通过 | 无 |
| 确保 API Server 的 --service-account-key-file 参数设置为适当的值 | 通过 | 无 |
| 确保将 API Server 的 --etcd-certfile 和 --etcd-keyfile 参数设置为适当的值 | 通过 | 无 |
| 确保将 API Server 的 --tls-cert-file 和 --tls-private-key-file 参数设置为适当的值 | 通过 | 无 |
| 确保将 API Server 的 --client-ca-file 参数设置为适当的值 | 通过 | 无 |
| 确保将 API Server 的 --etcd-cafile 参数设置为适当的值 | 通过 | 无 |
| 确保将 API Server 的 --encryption-provider-config 参数设置为适当的值 | 不通过 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保 Controller Manager 的 --terminated-pod-gc-threshold 参数设置为适当的值 | 不通过 | VKE 使用社区默认值 12500。 |
| 确保 Controller Manager 的 --profiling 参数设置为 false | 不通过 | VKE 使用性能剖析进行调试。 |
| 确保 Controller Manager 的 --use-service-account-credentials 参数设置为 true | 通过 | 无 |
| 确保将 Controller Manager 的 --service-account-private-key-file 参数设置为适当的值 | 通过 | 无 |
| 确保 Controller Manager 的 --root-ca-file 参数设置适当 | 通过 | 无 |
| 确保 Controller Manager 的 RotateKubeletServerCertificate 参数设置为 true | 通过 | 无 |
| 确保 Controller Manager 的 --bind-address 参数设置为 127.0.0.1 | 不通过 | 由于 VKE 平台组件需要监控 Controller Manager 状态和指标，因此绑定地址是 0.0.0.0。另外，自 Kubernetes v1.17 版本起， Controller Manager API 服务的监听端口强制使用 TLS 认证和加密，因此非认证用户无法通过其获取运行状态和监控指标。 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保 Scheduler 的 --profiling 参数设置为 false | 不通过 | VKE 使用性能剖析进行调试。 |
| 确保 Scheduler 的 --bind-address 参数设置为 127.0.0.1 | 不通过 | 由于 VKE 平台组件需要监控 Scheduler 状态和指标，因此绑定地址是 0.0.0.0。另外，自 Kubernetes v1.17 版本起，Scheduler API 服务的监听端口强制使用 TLS 认证和加密，因此非认证用户无法通过其获取运行状态和监控指标。 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保 etcd 正确设置了 --cert-file 和 --key-file 参数 | 通过 | 无 |
| 确保 etcd 的 --client-cert-auth 参数设置为 true | 通过 | 无 |
| 确保 etcd 的 --auto-tls 参数未设置为 true | 通过 | 无 |
| 确保 etcd 正确设置了--peer-cert-file 和 --peer-key-file 参数 | 通过 | 无 |
| 确保 etcd 的 --peer-client-cert-auth 参数设置为 true | 通过 | 无 |
| 确保 etcd 的 --peer-auto-tls 参数未设置为 true | 通过 | 无 |
| 确保 etcd 使用了唯一的证书颁发机构（CA） | 通过 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 不应将客户端证书用于用户身份验证 | 不通过 | VKE 当前不支持，通过其他机制验证客户端身份认证。 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保为 Kuvernetes 创建了最低限度的审计策略 | 不通过 | 产品功能，默认不开启审计。 |
| 确保 Kubernetes 的审计策略涵盖关键的安全问题 | 不通过 | 产品功能，默认不开启审计。 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保将 kubelet 服务文件的权限设置为 644 或更严格 | 通过 | 无 |
| 确保将 kubelet 服务文件的所有权设置为 root：root | 通过 | 无 |
| 如果 kube-proxy 存在 kubeconfig 文件，请确保将权限设置为 644 或更严格的限制性 | 通过 | 无 |
| 如果 kube-proxy 存在 kubeconfig 文件，请确保所有权设置为 root: root | 通过 | 无 |
| 确保 kubelet 的 --kubeconfig kubelet.conf 文件权限设置为 644 或更严格 | 通过 | 无 |
| 确保 kubelet 的 --kubeconfig kubelet.conf 文件所有权设置为 root: root | 通过 | 无 |
| 确保 kubelet 的证书颁发机构文件（CA 文件）的权限设置为 644 或更严格的限制性 | 通过 | 无 |
| 确保 kubelet 的证书颁发机构文件（CA 文件）的所有权设置为 root: root | 通过 | 无 |
| 确保 kubelet 的 --config 配置文件的权限设置为 644 或更高限制 | 通过 | 无 |
| 确保将 kubelet 的 --config 配置文件所有权设置为 root: root | 通过 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保 kubelet 的 --anonymous-auth 参数设置为 false | 通过 | 无 |
| 确保 kubelet 的 --authorization-mode 参数未设置为 AlwaysAllow | 通过 | 无 |
| 确保 kubelet 的 --client-ca-file 参数设置为适当的值 | 通过 | 无 |
| 验证 kubelet 的 --read-only-port 参数是否设置为 0 | 通过 | 无 |
| 确保 kubelet 的 --streaming-connection-idle-timeout 参数未设置为 0 | 通过 | 无 |
| 确保 kubelet 的 --protect-kernel-defaults 参数设置为 true | 不通过 | VKE 不会保护 Kubernetes 中的内核默认设置，因为客户工作负载可能需要修改这些默认设置。 |
| 确保 kubelet 的 --make-iptables-util-chains 参数设置为 true | 通过 | 无 |
| 确保 kubelet 未设置 --hostname-override 参数 | 不通过 | VKE 不使用宿主机的 hostname 作为 kubelet 的身份标识。相反，VKE 通过 --hostname-override 将 kubelet 身份设置成合适值，从而使得其与 Node Name 一一对应，不会影响安全分析与 FQDNs 解析。 |
| 确保 kubelet 的 eventRecordQPS 参数被设置为合适的值 | 不通过 | 事件是存储在 etcd 中的 Kubernetes 对象。为避免 etcd 过载，事件仅保留一个小时，它们不是合适的安全审核机制。允许此控制措施中建议的无限制的事件将使集群面临不必要的 DoS 风险，并且会与使用准许 EventRateLimits 的建议发生冲突。需要永久性存储的安全相关事件应发送到日志。 |
| 确保 kubelet 的 --tls-cert-file 和 --tls-private-key-file 参数设置为适当的值 | 通过 | 无 |
| 确保 kubelet 的 --rotate-certificates 参数未设置为 false | 通过 | 无 |
| 验证 kubelet 的 RotateKubeletServerCertificate 参数是否设置为 true | 通过 | 无 |
| 确保 kubelet 仅使用强加密密码套件 | 不通过 | VKE 使用 Go 语言默认的允许加密集。Go 语言加密专家认为可安全使用的加密集，也是 Kubernetes 的默认加密集。 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保仅在必要时使用 cluster-admin 角色 | 取决于环境 | 无 |
| 尽可能缩减对密钥的访问权限 | 取决于环境 | 无 |
| 尽可能减少通配符在 Roles 和 ClusterRoles 中的使用 | 取决于环境 | 无 |
| 尽可能缩减用于创建 pod 的访问权限 | 取决于环境 | 无 |
| 确保未频繁使用默认服务账号 | 取决于环境 | 无 |
| 确保仅在必要时装载服务账号令牌 | 取决于环境 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 尽可能减少特权容器的准许 | 取决于环境 | 无 |
| 尽可能减少希望共享主机进程 ID 命名空间的容器的准许 | 取决于环境 | 无 |
| 尽可能减少希望共享主机 IPC 命名空间的容器的准许 | 取决于环境 | 无 |
| 尽可能减少希望共享主机网络命名空间的容器的准许 | 取决于环境 | 无 |
| 尽可能减少具有 allowPrivilegeEscalation 的容器的准许 | 取决于环境 | 无 |
| 尽可能减少根容器的准许 | 取决于环境 | 无 |
| 尽可能减少具有 NET_RAW 功能的容器的准许 | 取决于环境 | 无 |
| 尽可能减少具有附加功能的容器的准许 | 取决于环境 | 无 |
| 尽可能减少具有分配的功能的容器的准许 | 取决于环境 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 确保所使用的 CNI 支持网络策略 | 通过 | 无 |
| 确保所有命名空间都定义了网络策略 | 取决于环境 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 优先将密文用作文件而不是用作环境变量 | 取决于环境 | 无 |
| 考虑外部密文存储 | 取决于环境 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 使用 ImagePolicyWebhook 准许控制器配置映像来源 | 取决于环境 | 无 |
| 条目说明 | VKE 是否通过 | 未通过原因 |
|---|---|---|
| 使用命名空间在各资源之间创建管理边界 | 取决于环境 | 无 |
| 确保在 pod 定义中将 seccomp 配置文件设置为 docker/default | 取决于环境 | 无 |
| 将安全上下文应用到您的 Pod 和容器 | 取决于环境 | 无 |
| 不应使用默认命名空间 | 取决于环境 | 无 |