go语言通过client-go调用kubernetes api驱动安全策略落地，需确保cni插件就绪、rbac权限精准、apiversion动态获取；pod安全须用psa标签+admission webhook校验；secret访问须最小化授权并避免敏感数据泄露。
Go语言本身不直接做Kubernetes安全管理，而是通过client-go调用API、配合RBAC和资源对象（如NetworkPolicy、PodSecurityPolicy/PSA、Secret）来驱动安全策略落地。硬编码规则或绕过API操作底层iptables/ebpf，等于放弃Kubernetes的安全抽象层。
用client-go创建NetworkPolicy前必须确认的三件事
NetworkPolicy生效依赖CNI插件（如Calico、Cilium），client-go只是提交资源，不是执行策略。常见错误是代码跑通但网络没隔离——往往卡在这三步：
- 集群中已部署兼容的CNI插件，且
NetworkPolicyCRD已注册（可通过kubectl api-resources | grep networkpolicies验证） - Go程序使用的ServiceAccount绑定了足够RBAC权限：
networkpolicies/{create,update,patch}，作用域需覆盖目标命名空间 - 代码中未硬编码
apiVersion: networking.k8s.io/v1，而是从scheme.Scheme获取，否则在旧版集群（如v1.18之前）会因版本不匹配失败
Pod安全上下文（SecurityContext）不能只靠Deployment YAML配置
仅在Deployment模板里写securityContext.runAsNonRoot: true不够。Go程序若作为Operator或Admission Webhook运行，需主动校验Pod创建请求：
- Admission Webhook中解析
ar.Request.Object.Raw为corev1.Pod，检查pod.Spec.SecurityContext.RunAsUser是否为0或nil - 对特权容器（
privileged: true）、挂载/host路径、hostNetwork: true等高危字段做显式拒绝 - 注意：Kubernetes 1.25+已弃用
PodSecurityPolicy，必须迁移到PodSecurity Admission（PSA）标签控制，Go代码里应检查命名空间是否设置了pod-security.kubernetes.io/enforce: baseline等标签
Secret和ConfigMap的读取权限必须最小化
很多Go服务（如自定义Operator）需要读取Secret，但常误配成get全部Secret或跨命名空间访问：
- RBAC规则中
resources: ["secrets"]必须限定resourceNames（如["db-credentials"]），而非留空 - 避免使用
clusterrole，优先用role并绑定到具体命名空间；若必须跨命名空间，用rolebinding+serviceaccount明确指定目标 - Secret内容不应被日志打印或暴露在HTTP响应中——Go代码里对
secret.Data做任何操作前，先判断key名是否属于敏感字段（如"password","token"）
真正难的不是写几行client-go代码，而是把安全约束变成不可绕过的控制点：比如Admission Webhook拒绝root容器，比靠CI/CD扫描YAML更可靠；RBAC按命名空间+资源名精确授权，比给一个clusterrole省事但危险得多。这些逻辑一旦漏掉，Go写的工具反而会成为安全盲区。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
