去年我接手一个 K8s 集群的安全检查第一轮跑下来结果让我有点意外cluster-admin 全局权限居然挂在一个业务服务账号上好几个 Pod 直接以 privileged 模式跑还有几个 namespace 连 NetworkPolicy 的影子都没见到。当时我手里有 kube-bench、popeye 这些现成工具但总感觉它们和业务场景隔了一层——规则不好定制报告也不太好直接拿给团队解释。后来我干脆用 Python 写了一个轻量级的 K8s 配置错误扫描器专门盯集群里的高危配置项。这篇文章会把整个实现思路、核心检查项、完整流程和踩过的坑都拿出来聊一聊既给自己做个记录也希望能给准备做 K8s 安全自查的同行一点参考。1. 为什么我要自己写一个 K8s 扫描器1.1 现成工具很好但总有让人别扭的地方市面上并不是没有 K8s 安全扫描工具。kube-bench 主要按 CIS Benchmark 检查节点与组件配置比如 kube-apiserver 的启动参数、etcd 的权限、kubelet 的证书配置这些popeye 则偏“集群资源最佳实践”会检查资源配额、探针配置、镜像 tag 等问题。这两类工具在合规审计场景里都很有价值但实际用起来有几个问题。第一个问题是规则太“死”。kube-bench 更关注单机组件层面对业务资源的检查很少popeye 虽然扫的是集群对象但它的规则是内置的我想加一条“禁止把 cluster-admin 绑给 serviceAccount”或者“生产 namespace 必须存在 NetworkPolicy”要么改源码要么就得另写脚本调用 kubectl 去补数据。第二个问题是报告呈现方式不适合团队内部评审。工具输出的是一个长报告每条告警缺少“为什么有问题”的解释开发同事看到只会觉得我们安全组在挑刺。所以我最终决定用 Python 写一个聚合型扫描器。思路很简单把“拉取资源”和“规则判断”分开先通过 Kubernetes Python Client 把相关资源全量拉下来然后再用一组独立的 check 函数去做判断最后统一汇总成带风险等级和修复建议的报告。这个思路最大的好处是规则可以随时加不需要动底层逻辑团队内部要解释哪条告警我直接把规则里的 reason 字段甩出去就行。1.2 这个扫描器解决什么问题适合谁用这个扫描器定位很明确不追求像专业安全平台那样覆盖几百条漏洞规则而是把 K8s 管理中最容易反复出现的配置错误自动化、持续化地盯住。具体来说它至少能解决四类问题第一RBAC 权限过宽比如普通 ServiceAccount 绑定了 cluster-admin或者 Role 里出现了“资源和操作全部通配”的写法第二Pod 安全上下文失控包括 privileged 容器、allowPrivilegeEscalation 未关闭、hostPath 挂载宿主机敏感目录第三网络策略缺失尤其是生产 namespace 之间完全不做流量隔离第四Secret 被当成普通配置项使用甚至以明文 base64 形式出现在不合适的对象里。适合用它的人我觉得有三类。第一类是刚上手 K8s 维护的运维或 SRE可以用它做集群安全自查的入门基线第二类是安全团队里负责容器安全的人可以在已有安全体系之外补充一个可定制的检查维度第三类是想在 CI/CD 里加一道“配置合规门禁”的研发平台团队。当然了如果你只是随便搭个测试集群玩这套东西可能有点大材小用但学习代价并不高扫一遍也能让你知道哪些配置是会在真实生产环境里出事的。1.3 整体架构三个模块一条链路整个扫描器的架构我不建议上来就搞复杂先分成三个模块就够了。采集模块负责连接集群并拉取资源这一层我用官方kubernetesPython Client因为它返回的是 dict 或对象形式程序里直接遍历字段非常方便比调 kubectl 去解析 JSON 输出要干净得多。规则模块是核心由一堆 check 函数组成每个函数只做一件事接收采集到的资源列表返回匹配问题的告警记录。输出模块负责把告警转成 Markdown 表格或 JSON 格式方便在 CI 日志里看也方便后续接告警系统。检查项的分类我整理成了一张表这样写代码的时候心里也有数分类检查项示例风险等级RBAC 权限cluster-admin 绑定给非系统主体Role 规则通配资源/操作高Pod 安全上下文privileged 容器allowPrivilegeEscalation 未关闭hostPID/hostNetwork高网络策略namespace 下完全没有 NetworkPolicy 覆盖中工作负载配置Pod 未设置资源限制镜像 tag 为 latest低Secret 使用Secret 值可被 Base64 直接还原默认/弱口令中表里的每一项对应一个或者多个 check 函数。规则和采集层之间靠一个简单的调用约定连接规则函数统一接收 client 对象自己决定用哪个 API 拉数据再返回 findings 列表。这样做的好处是写新规则时不需要理解整个框架只要知道怎么用 client 就行。2. 核心检查项的实现思路与代码拆解2.1 检查项一RBAC 过度授权K8s 的 RBAC 设计思想是“默认拒绝显式授权”但实际集群里很容易出现两种失控情况。一是把 cluster-admin 这种超级权限绑给了某个业务 ServiceAccount哪怕只是图省事二是 Role 或 ClusterRole 里写了resources: [*]、verbs: [*]这种规则的杀伤面非常大等于对该 Role 绑定范围内的所有资源拥有全部操作权限。我在代码里先写一个专门检查 cluster-admin 绑定的函数。实现方式很直接调用list_cluster_role_binding拿到所有 ClusterRoleBinding判断每个 binding 的 roleRef 是不是指向 ClusterRole/cluster-admin如果是再看 subjects 里包含哪些 User、Group 或 ServiceAccount然后把这些信息记进告警from kubernetes import client, config def check_cluster_admin_bindings(v1_rbac): 扫描所有 ClusterRoleBinding找出绑定 cluster-admin 的普通主体。 findings [] crbs v1_rbac.list_cluster_role_binding().items for crb in crbs: role_ref crb.role_ref if role_ref and role_ref.kind ClusterRole and role_ref.name cluster-admin: for sub in crb.subjects or []: findings.append({ rule: rbac-no-cluster-admin-for-app, namespace: crb.metadata.namespace or -, resource: fClusterRoleBinding/{crb.metadata.name}, detail: fSubject {sub.kind}/{sub.name} 绑定了 cluster-admin, severity: high, suggestion: 移除该绑定改用最小权限 Role RoleBinding }) return findings这段代码逻辑很简单但实际跑起来命中率极高。很多集群长期运行后总会有人为了排查问题临时绑一个 cluster-admin然后忘了回收。除了 cluster-admin 这个明显的高危点还可以继续扩展对每个 Role/ClusterRole 的 rules 做遍历如果发现apiGroups、resources、verbs全为*同样标记为高危规则因为这意味着这个角色拥有 API 全量权限一旦绑定对象被攻破或者 token 泄露影响面就是整个集群。写这类检查时有一个小坑需要注意subjects字段可能为 None遍历前一定要加or []兜底否则遇到没有 subjects 的 ClusterRoleBinding 直接抛 TypeError。此外官方 client 返回的对象字段和 kubectl yaml 里的字段名略有差异比如 subjects 是复数形式写代码前最好先print(crb.to_dict())看一下实际返回结构再开始写字段判断逻辑能省很多调试时间。2.2 检查项二Pod 安全上下文失控Pod 安全上下文的问题比 RBAC 更隐蔽因为它通常在 Deployment 或 StatefulSet 的 template 里配置平时看 yaml 不仔细根本注意不到。最危险的是privileged: true这等于告诉容器运行时“不要做任何隔离”容器里的 root 直接对宿主机拥有大部分权限。其次还有allowPrivilegeEscalation: true允许提权、hostPID: true共享宿主机进程空间、hostNetwork: true直接使用宿主机网络栈这些配置。我在实现里遍历所有 Deployment、DaemonSet 和 StatefulSet 的 PodTemplateSpec提取 securityContext 里的关键字段做判断。这里以 Deployment 为例def check_privileged_containers(apps_v1): findings [] deps apps_v1.list_deployment_for_all_namespaces().items for dep in deps: containers dep.spec.template.spec.containers or [] for container in containers: sc container.security_context if sc and sc.privileged: findings.append({ rule: pod-no-privileged, namespace: dep.metadata.namespace, resource: fDeployment/{dep.metadata.name}/container/{container.name}, detail: 容器以 privileged 模式运行, severity: high, suggestion: 移除 privileged: true必要时用 capabilities 精确授权 }) return findings注意这里是检查容器级别的 securityContext而不是 Pod 级别的。两者都可能配置 privilegedPod 级别的 securityContext 如果设置了runAsNonRoot或者seccompProfile相当于给整个 Pod 里的所有容器定了基线而容器级别的 securityContext 是针对单个容器的。我的建议是两层都检查不要只扫一层。runAsNonRoot这个字段我认为更值得写进检查规则里。很多镜像内部还用 root 启动但实际业务又不需要特权一旦容器被攻破攻击者拿到的就是 root 权限。规则很简单如果 Pod 没有显式设置runAsNonRoot: true就提示“建议使用非 root 用户运行”。这条规则在测试集群里可能命中一堆但生产环境里它是一条很有价值的最低安全基线。2.3 检查项三命名空间裸奔没有 NetworkPolicyNetworkPolicy 是 K8s 里面向业务层的东西不确定自己写还是别人写经常被忽略。默认情况下K8s 集群里的 Pod 之间是可以互相通信的没有所谓的“默认隔离”。这意味着只要有一个 Pod 被攻破横向移动几乎没有障碍。NetworkPolicy 存在的意义就是把网络边界收回来至少做到“不同 namespace 之间默认隔离只放开明确允许的流量”。实现时我先调 Networking API 把全集群的 NetworkPolicy 拉下来再汇总所有 namespace然后找出那些没有任何 NetworkPolicy 覆盖的 namespacedef check_namespaces_without_network_policy(networking_v1, core_v1, ignore_namespacesNone): ignore_namespaces ignore_namespaces or {kube-system, kube-public, kube-node-lease} findings [] namespaces [ns.metadata.name for ns in core_v1.list_namespace().items] policies networking_v1.list_network_policy_for_all_namespaces().items ns_with_policy {pol.metadata.namespace for pol in policies} for ns in namespaces: if ns in ignore_namespaces: continue if ns not in ns_with_policy: findings.append({ rule: ns-has-network-policy, namespace: ns, resource: fNamespace/{ns}, detail: 该 namespace 下没有任何 NetworkPolicy, severity: medium, suggestion: 创建默认拒绝策略再按业务白名单放通 }) return findings这条规则的好处是代码很短但坑也不少。最大的坑是“覆盖率”的判断方式。K8s 官方文档明确说NetworkPolicy 是叠加生效的某个 namespace 里只要有一条策略那么没有被该策略选中的 Pod 实际行为会变得复杂。简单地判断“namespace 里有没有 NetworkPolicy”会漏掉一部分问题比如有策略但 selector 只匹配到少数 Pod其余 Pod 仍然裸奔。不过我的经验是作为第一版扫描器先按 namespace 维度检查已经能发现大量问题了后面再逐步升级成“Pod 维度匹配”的判断。2.4 检查项四Secret 只是 Base64不是加密很多刚接触 K8s 的同学会误以为 Secret 是加密的其实它默认只做 Base64 编码并没有加密保护。一旦有 RBAC 权限的人想读取Base64 解码后就是明文。这个话题经常被引入“K8s 和 docker 区别”这类讨论里因为在 docker 时代我们习惯用环境变量传敏感信息而 K8s 里如果只是把 secret 直接做成环境变量其实并不比 docker 时代安全多少只是多了一层编码。扫描器里我写得比较简单遍历所有 Secret对每个 data 的 value 尝试做 Base64 解码如果解码结果是可打印的字符串就记录一条告警提示用户这些敏感信息其实可以被直接还原。代码如下import base64 def check_secret_base64_only(core_v1): findings [] secrets core_v1.list_secret_for_all_namespaces().items for sec in secrets: data sec.data or {} for key, value in data.items(): try: decoded base64.b64decode(value).decode(utf-8) if decoded.strip(): findings.append({ rule: secret-plaintext-value, namespace: sec.metadata.namespace, resource: fSecret/{sec.metadata.name}/key/{key}, detail: Secret 的 value 可被直接 Base64 还原, severity: medium, suggestion: 使用外部密钥管理服务或在应用侧加密存储 }) except Exception: continue return findings这条规则我在实际项目里经常发现一堆误报因为很多团队确实只是把 Secret 用于存储一些非敏感的配置字符串比如 Redis 地址、队列名。所以我建议在规则前面加一个“敏感 key 名称匹配”的条件比如 key 名包含 password、token、secret、key 等关键字才触发告警否则跳过。让规则有“重点盯防”的意识比大范围轰炸有用得多。3. 完整实操从环境准备到拿到第一份报告3.1 环境准备与依赖安装扫描器本身对机器要求很低一个普通 Linux 虚拟机甚至开发机都能跑。Python 版本建议 3.9 以上依赖主要只有一个官方 Kubernetes Client安装命令很简单pip install kubernetes。如果你本地装了多个 Python 环境记得先确认当前用哪个解释器别装错环境这种问题排查起来真的会让人怀疑人生。如果是用 Kubernetes Python Client 访问集群它的核心机制是读取 kubeconfig 里的 apiserver 地址、token 或证书然后直接走 HTTPS 调用 API。所以本机不一定非要安装 kubectl只要 kubeconfig 正确Python 依赖装好扫描器就能独立运行。这一点对于只想在 CI 里跑个巡检的场景特别友好。顺便说一下 Python 环境本身的问题。我见过不少同事在 mac 或 Windows 上装 Python 时路径搞乱导致 pip 装了一切都是“No module named kubernetes”。如果你也遇到这种情况第一步先跑which python和which pip确认调用的是同一个版本的 Python再决定要不要用虚拟环境。我现在的习惯是所有新项目都建一个 venv从根上避免这类问题。3.2 连接集群的三种方式与选择扫描器要连接集群需要解决 kubeconfig 的来源问题我总结下来有三种。第一种是最常用的读取~/.kube/config默认文件第二种是读取环境变量KUBECONFIG指向的路径第三种是集群内运行时使用 InClusterConfigtoken 通过 ServiceAccount 挂载的/var/run/secrets/kubernetes.io/serviceaccount/token获取。import os from kubernetes import client, config def load_kube_config(): if os.getenv(KUBERNETES_SERVICE_HOST): config.load_incluster_config() else: kubeconfig os.getenv(KUBECONFIG, ~/.kube/config) config.load_kube_config(config_fileos.path.expanduser(kubeconfig))从实际使用出发我推荐在本地调试时优先用KUBECONFIG环境变量因为团队内部可能同时维护多个集群默认 kubeconfig 并不一定指向你想扫的那个集群。在 CI 或 CronJob 里跑的时候则优先用 InClusterConfig这样不需要把 kubeconfig 拿进容器安全很多。另外有个细节config.load_kube_config()不传参数时虽然会默认读~/.kube/config但如果你在同一进程里先加载过一个集群再想切换集群最好重新构造 client 对象避免上下文串了。3.3 把所有检查串起来跑一遍当每个 check 函数都写好之后主流程就非常清晰了先加载 kubeconfig再创建需要的 API client 实例然后依次调用各个 check 函数最后把所有 findings 汇总成一个总列表。这里我建议给每个 check 函数统一返回格式至少包含 rule、namespace、resource、detail、severity、suggestion 这几个字段。统一格式最大的价值在于后续报告、告警、处理都不需要针对特殊结构做兼容。def run_all_checks(): load_kube_config() core_v1 client.CoreV1Api() rbac_v1 client.RbacAuthorizationV1Api() apps_v1 client.AppsV1Api() networking_v1 client.NetworkingV1Api() policy_v1 client.PolicyV1Api() findings [] findings check_cluster_admin_bindings(rbac_v1) findings check_privileged_containers(apps_v1) findings check_namespaces_without_network_policy(networking_v1, core_v1) findings check_secret_base64_only(core_v1) return findings if __name__ __main__: result run_all_checks() print(f共发现 {len(result)} 条告警) for item in result: print(f[{item[severity].upper()}] {item[resource]}: {item[detail]})跑起来之后你会看到一个非常直白的输出比如[HIGH] Deployment/nginx/container/nginx: 容器以 privileged 模式运行。我的建议是先用这个命令行版把逻辑跑通再考虑报告展示的问题。先出结果再谈好看优先级不能反。3.4 报告输出与结果展示报告这部分我一开始只做命令行打印后来发现几百条告警打印出来根本没法看我就加了一个简单的 Markdown 报告生成函数把 findings 按严重级别排序再按 namespace 分组输出成一张表格。效果大概这样告警级别资源对象问题描述修复建议highDeployment/nginx/container/nginx容器以 privileged 模式运行移除 privileged 配置mediumNamespace/default没有任何 NetworkPolicy创建默认拒绝策略Markdown 表格可以直接贴在工单或 commit 评论里比纯文本可读性好很多。JSON 格式我也保留了方便后续接入告警平台或者让上游程序继续处理。输出方式我建议做成参数可选默认打印 Markdown加个--format json就输出 JSON这样测试时方便人看对接时方便机器读。4. 实战中躲不开的坑与排查技巧4.1 扫描器自身权限不足这里说的“权限不足”指的是扫描器用来访问集群的账号权限不够。如果你用的是 kubeconfig 里的管理员账号一般不会遇到这个问题但如果你把扫描器部署成 CronJob挂的 ServiceAccount 只绑定了某个 namespace 的只读权限一运行就会看到满屏的 403 Forbidden。解决方法不是直接给 ServiceAccount 绑一个 cluster-admin而是创建一个只读的 ClusterRole然后绑定给它。我常用的一组权限包括get/list/watch几乎所有的资源类型比如 pods、deployments、statefulsets、daemonsets、services、namespaces、secrets、networkpolicies、roles、rolebindings、clusterroles、clusterrolebindings。注意 secrets 在默认的viewClusterRole 里是不能读的所以如果你要扫 Secret 相关规则必须单独加资源权限。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: k8s-scanner-readonly rules: - apiGroups: [] resources: [namespaces, pods, services, secrets] verbs: [get, list, watch] - apiGroups: [apps] resources: [deployments, statefulsets, daemonsets] verbs: [get, list, watch] - apiGroups: [rbac.authorization.k8s.io] resources: [roles, rolebindings, clusterroles, clusterrolebindings] verbs: [get, list, watch] - apiGroups: [networking.k8s.io] resources: [networkpolicies] verbs: [get, list, watch]做这一步的时候我踩过坑以为list_cluster_role_binding只需要clusterroles的权限结果返回的其实是clusterrolebindings差一个单词就是 403。所以写完 YAML 之后最好用kubectl auth can-i --list --assystem:serviceaccount:ns:sa-name先验证一遍别等扫描器跑挂了才发现。4.2 API 版本差异K8s 的 API 升级节奏比较快同样的资源在不同版本里 group/version 可能不一样。比如 NetworkPolicy 最早在networking.k8s.io/v1beta1后来 GA 到networking.k8s.io/v1RBAC 也从rbac.authorization.k8s.io/v1beta1升到了v1。Python Client 的类名一般和 version 是对应的比如NetworkingV1Api、RbacAuthorizationV1Api。如果你在旧版本集群上强制用NetworkingV1Api就会遇到一个让人摸不着头脑的 404原因是集群不支持这个 API group/version。我的习惯是在扫描器启动时先调用CoreV1Api().get_api_resources()或者直接 try/except 捕获 ApiException发现版本不支持时降级到 beta API 或者直接提示跳过对应检查项。这个坑在实际中很容易被忽略因为本地测试集群可能是新版本一切正常一放到生产老集群就开始报 404。处理思路就是扫描器的目标不是“在所有版本集群里跑同一个二进制”而是“在支持的版本里给出最有价值的检查结果”不支持的检查项直接输出一条 skip 日志就好没必要硬刚。4.3 常见误报和忽略策略扫描器上线之后最怕的不是发现不了问题而是告警太多导致团队自动忽略。我在实践里发现几类典型的误报。第一类是开发或测试 namespace 没有 NetworkPolicy这其实可能是有意为之开发环境为了调试方便确实没必要开严格隔离第二类是某些历史遗留应用镜像必须以 root 运行短期内改不了第三类是 Secret 里存的根本不是敏感信息只是命名方式叫 token。应对误报的方法我建议在扫描器里加入“忽略名单”机制支持两种维度。一种是按 namespace 忽略比如在配置里声明ignoreNamespaces: [dev-*, test-*]另一种是按 rule ID 忽略比如disableRules: [secret-plaintext-value]。规则级别和 namespace 级别的忽略可以组合这样既能保证规则库完整又能让实际告警量收敛到可处理的范围。IGNORE_CONFIG { namespaces: [dev-*, test-*, kube-system], rules: [secret-plaintext-value], }代码里处理时要注意匹配规则不要用简单的in判断最好支持通配符或者前缀匹配。比如dev-*要能匹配dev-payment和dev-user。实现方式就是用fnmatch模块几行代码搞定但体验差异非常大。4.4 性能问题扫描大集群时的优化如果你只是扫一个几十个节点的小集群性能不需要太担心。但集群规模上来之后比如几百个 namespace、几千个 Deployment再叠加成百上千条规则扫描时间会明显增加还可能把 apiserver 打出一个不小的负载。这里有两个优化方向。第一个方向是“按需拉取”。很多资源字段其实在 check 里根本用不到但 Python Client 的list_*默认会把整个对象都拉下来。如果能确认某个检查项只需要 metadata 和 spec可以在规则里尽量复用同一个 API 请求的结果不要每条规则都单独调一次list_*接口。我后来做的一个版本就是让采集模块先统一拉取所有资源然后规则模块从这个缓存里去取避免重复请求。第二个方向是分页。K8s 的 list 接口默认支持 limit 和 continue 参数Python Client 底层封装了这一层但如果你调用的是_with_http_info这类方法可能要自己处理继续令牌。实际上官方 client 在list_*方法里已经自动处理了分页你只要不手动设置 limit 就行。如果还嫌慢可以用ThreadPoolExecutor对多个 API 请求做并发但要小心 client 对象在多个线程里共用时可能出现的连接池问题稳妥做法是每个线程单独创建 client。5. 后续扩展把扫描器变成安全基线的一部分5.1 规则配置化走到这一步扫描器已经能解决不少问题了但每次加规则都要改 Python 代码长期来看维护成本会越来越高。我后来的做法是把规则描述和匹配条件抽到 YAML 配置文件里代码只保留通用执行引擎这样安全团队的新同学也能快速添加规则不需要深入理解 Python 代码逻辑。比如一条规则可以写成这样- id: pod-no-privileged category: pod-security severity: high resource_type: deployment check: container.security_context.privileged true message: 容器以 privileged 模式运行 suggestion: 移除 privileged 配置当然单纯用 YAML 描述复杂逻辑是不够的遇到需要组合条件的规则还是会写 Python。但至少常见的高频规则可以配置化这样团队里哪怕只会看 yaml 的人也能参与规则维护。这个扩展我觉得很值得做尤其是当你的集群数量超过 5 个的时候统一管理规则会更省心。5.2 定时任务与告警扫描器只跑一次是不够的集群配置是动态变化的今天没问题不代表明天没问题。我建议把它做成一个 CronJob每天或每周定时跑一次然后把结果发到企业微信、钉钉、飞书这类群里。实现起来很简单扫描器输出 JSON外面套个 shell 脚本或者 Python 脚本去 post webhook 就行。另外一个思路是把结果推到 Prometheus用 counter 类型记录当前高危告警数量再配合 Alertmanager 做阈值告警。比如“高危告警数从 0 变成 1”就触发告警这种事件驱动的告警比每天定时发全量报告更容易让人关注。如果你对 Prometheus 客户端库不熟用 HTTP API 直接提交也行不一定要引入一堆依赖。5.3 和在 CI/CD 中集成把扫描器塞进 CI 流程是让配置错误在源头被拦住的有效办法。我见过一个很典型的场景开发同事在 merge request 里改了 Deployment 的 yaml顺手把privileged改成 true 来调试问题结果直接合到主分支。如果 CI 里有一道“扫描变更配置文件”的步骤在合入前就报错这个问题根本不会进入到集群。在 CI 里跑的思路和本地思路不一样重点是“增量扫描”而不是“全量扫描”。全量扫描在 CI 场景里太慢而且会扫到历史存量问题干扰对新变更的判断。更合理的做法是先通过 git diff 拿到本次变更涉及的 yaml 文件转换成 K8s 对象后只针对这些对象执行相关规则。这么做既快又聚焦开发同学也能在几分钟内得到反馈而不会被一堆历史告警淹没了。最后聊一点体会我从一开始用现成工具到后来自己写扫描器中间最大的体会是这类安全工具最核心的价值不是“发现多少漏洞”而是“能不能让人愿意持续看它”。所以我在设计输出格式和告警文案时花了大量心思每条规则都尽量写清楚“为什么有问题”“应该怎么改”而不是简单甩一个高风险的等级。另一个体会是不要一上来就追求规则大全从 RBAC 和 Pod 安全上下文这两个最容易命中真实问题的方向做起把链路跑通再逐步扩充这样项目才能健康地演进。如果你也在做类似的事情希望这篇记录能帮你少踩几个坑。