最常用方式是用kubectl create clusterrole创建集群角色并用kubectl create clusterrolebinding绑定到ServiceAccount；ClusterRoleBinding不支持--namespace参数，ServiceAccount格式必须为ns:sa-name，且需预先存在。
直接用 kubectl 命令创建 ClusterRole 并绑定到 ServiceAccount 是最常用、最稳妥的方式；Go 程序本身不“创建” RBAC 资源，而是调用 Kubernetes API 提交 YAML 或构建资源对象 —— 但前提是你的 Go 进程已有足够权限（比如 Pod 内使用 ServiceAccount 绑定了 cluster-admin 或对应 ClusterRole）。
用 kubectl create clusterrole 创建集群角色
这是最轻量、最不易出错的起点。命令行直接生成标准结构，避免 YAML 缩进/字段遗漏问题：
kubectl create clusterrole deployment-manager --verb=create,update,delete --resource=deployments,replicasets --api-group=apps- 注意
--api-group必须显式指定：核心资源（如pods、services）用空字符串""，deployments属于apps组，customresourcedefinitions属于apiextensions.k8s.io组 - 如果漏写
--api-group，kubectl默认用""，导致规则对apps/v1 Deployment不生效
用 kubectl create clusterrolebinding 绑定到 ServiceAccount
ClusterRoleBinding 是集群作用域的，它不接受 --namespace 参数；绑定目标必须是集群级主体（用户、组、或 ns:sa-name 格式的 ServiceAccount）：
kubectl create clusterrolebinding cicd-deployer-binding --clusterrole=deployment-manager --serviceaccount=default:cicd-sa- 错误写法：
--serviceaccount=cicd-sa（缺命名空间）或--serviceaccount=my-ns/cicd-sa（用了斜杠而非冒号） - 若目标 ServiceAccount 尚未存在，命令仍会成功创建 binding，但授权不生效 —— 需先确保
kubectl create serviceaccount cicd-sa -n default
Go 程序里调用 client-go 创建 ClusterRole
本质是构造 rbacv1.ClusterRole 对象并提交给 API Server。关键点不是“怎么写 struct”，而是“谁有权限提交”：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Pod 内运行时，必须确保其
ServiceAccount已通过ClusterRoleBinding获得clusterroles的create权限（例如绑定cluster-admin或自定义高权限 ClusterRole） - 代码中不要硬编码 kubeconfig 路径；优先用
rest.InClusterConfig()，它自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的token和ca.crt - 示例片段（省略 error 处理）：
cfg, _ := rest.InClusterConfig()
clientset, _ := kubernetes.NewForConfig(cfg)
cr := &rbacv1.ClusterRole{
ObjectMeta: metav1.ObjectMeta{Name: "my-clusterrole"},
Rules: []rbacv1.PolicyRule{{
APIGroups: []string{"apps"},
Resources: []string{"deployments"},
Verbs: []string{"get", "list"},
}},
}
clientset.RbacV1().ClusterRoles().Create(context.TODO(), cr, metav1.CreateOptions{})
若报错 error: clustersroles.rbac.authorization.k8s.io is forbidden，说明当前 ServiceAccount 没有创建 ClusterRole 的权限 —— 这不是代码问题，是 RBAC 配置缺失。
为什么不用 RoleBinding 绑定 ClusterRole？
这是常见误解。虽然 RoleBinding 支持 --clusterrole 参数，但它只能将 ClusterRole 的权限**限制在某个命名空间内**生效；而 ClusterRoleBinding 才让权限真正跨 namespace 甚至作用于集群资源（如 nodes、persistentvolumes）：
- 错误场景：想让
cicd-sa在prod命名空间部署Deployment，却用kubectl create rolebinding ... --clusterrole=deployment-manager -n prod—— 行得通，但权限被锁死在prod；如果后续要在staging也部署，就得再建一个RoleBinding - 正确选择：用
ClusterRoleBinding，一次绑定，所有命名空间通用（只要资源操作不越界） - 例外：只有当你明确需要“把集群角色降权为单 namespace 使用”时，才用
RoleBinding + --clusterrole
真正容易被忽略的是：ClusterRoleBinding 的主体（Subject）一旦写成 user 或 group，就和证书 CN/O 字段强绑定；而 ServiceAccount 的格式 default:cicd-sa 是唯一可预测、可复现的标识方式 —— 别在生产环境混用用户证书和 SA。
