控制面组件

Master 节点配置文件

条目说明	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。

API Server

条目说明	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 认证和加密，因此非认证用户无法通过其获取运行状态和监控指标。

Etcd 节点配置

条目说明	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 是否通过	未通过原因
确保为 Kubernetes 创建了最低限度的审计策略	不通过	产品功能，默认不开启审计。
确保 Kubernetes 的审计策略涵盖关键的安全问题	不通过	产品功能，默认不开启审计。

Worker 节点

Worker 节点配置文件

条目说明	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	通过	无

Kubelet

条目说明	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 的默认加密集。

Policy

RBAC 和服务账号

条目说明	VKE 是否通过	未通过原因
确保仅在必要时使用 cluster-admin 角色	取决于环境	无
尽可能缩减对密钥的访问权限	取决于环境	无
尽可能减少通配符在 Roles 和 ClusterRoles 中的使用	取决于环境	无
尽可能缩减用于创建 pod 的访问权限	取决于环境	无
确保未频繁使用默认服务账号	取决于环境	无
确保仅在必要时装载服务账号令牌	取决于环境	无

Pod 安全策略

条目说明	VKE 是否通过	未通过原因
尽可能减少特权容器的准许	取决于环境	无
尽可能减少希望共享主机进程 ID 命名空间的容器的准许	取决于环境	无
尽可能减少希望共享主机 IPC 命名空间的容器的准许	取决于环境	无
尽可能减少希望共享主机网络命名空间的容器的准许	取决于环境	无
尽可能减少具有 allowPrivilegeEscalation 的容器的准许	取决于环境	无
尽可能减少根容器的准许	取决于环境	无
尽可能减少具有 NET_RAW 功能的容器的准许	取决于环境	无
尽可能减少具有附加功能的容器的准许	取决于环境	无
尽可能减少具有分配的功能的容器的准许	取决于环境	无

网络策略和 CNI

条目说明	VKE 是否通过	未通过原因
确保所使用的 CNI 支持网络策略	通过	无
确保所有命名空间都定义了网络策略	取决于环境	无

密文管理

条目说明	VKE 是否通过	未通过原因
优先将密文用作文件而不是用作环境变量	取决于环境	无
考虑外部密文存储	取决于环境	无

可拓展的准许控制

条目说明	VKE 是否通过	未通过原因
使用 ImagePolicyWebhook 准许控制器配置映像来源	取决于环境	无

常规策略

条目说明	VKE 是否通过	未通过原因
使用命名空间在各资源之间创建管理边界	取决于环境	无
确保在 pod 定义中将 seccomp 配置文件设置为 docker/default	取决于环境	无
将安全上下文应用到您的 Pod 和容器	取决于环境	无
不应使用默认命名空间	取决于环境	无

容器服务