You need to enable JavaScript to run this app.
导航
CIS Kubernetes 基准支持状态
最近更新时间:2024.04.30 17:07:16首次发布时间:2024.04.30 17:07:16

控制面组件

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 是否通过未通过原因
确保为 Kuvernetes 创建了最低限度的审计策略不通过产品功能,默认不开启审计。
确保 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 和容器取决于环境
不应使用默认命名空间取决于环境