K8s多命名空间控制器能否使用Role替代ClusterRole？

我有一个带有多命名空间控制器的Operator，原本使用如下ClusterRole和RoleBinding配置：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: app-role
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - secrets
  - pods/exec
  verbs:
  - create
  - delete
  - get
  - list
  - watch
- apiGroups:
  - app.group.com
  resources:
  - JavaApps
  verbs:
  - create
  - delete
  - get
  - list
- apiGroups:
  - app.group.com
  resources:
  - DBApps
  verbs:
  - create
  - delete
  - get
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: app-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: appns

我按照官方文档设置了包含多个命名空间的WATCH_NAMESPACE，但将ClusterRole改为Role并创建在appns命名空间后，控制器持续报错：

reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.1/tools/cache/reflector.go:229: Failed to watch *v1alpha1.DbApps: failed to list *v1alpha1.DbApps: DbApps.app.group.com is forbidden: User "system:serviceaccount:appns:default" cannot list resource "DbApps" in API group "app.group.com" in the namespace "appns1"

我尝试添加额外的RoleBinding配置但未生效：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-rolebinding1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: app-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: appns1

请问多命名空间控制器是否可以使用Role？

多命名空间控制器可以使用Role，但需要为每个需要监控的命名空间单独配置Role和对应的RoleBinding，你的问题出在权限配置的逻辑错误上：

错误原因分析 #

1. Role的命名空间限制：Role是命名空间级别的资源，你将ClusterRole改为Role并创建在appns后，该Role仅能授予appns内的资源权限，无法覆盖appns1的资源访问。
2. RoleBinding的引用规则错误：你在appns1创建的RoleBinding引用了app-role这个Role，但RoleBinding只能引用同一命名空间内的Role，或者ClusterRole。跨命名空间引用Role是无效的，所以这个配置不会生效。

正确配置方式 #

方式1：为每个监控命名空间配置独立Role和RoleBinding #

1. 在每个需要监控的命名空间（如appns、appns1）中，创建相同权限的Role：

# appns中的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-role
  namespace: appns
rules:
- apiGroups: [""]
  resources: ["pods", "secrets", "pods/exec"]
  verbs: ["create", "delete", "get", "list", "watch"]
- apiGroups: ["app.group.com"]
  resources: ["JavaApps", "DBApps"]
  verbs: ["create", "delete", "get", "list"]

复制上述配置，修改metadata.namespace为appns1，在appns1中创建相同的Role。

2. 在每个命名空间创建RoleBinding，将该命名空间的Role绑定到控制器所在的ServiceAccount（appns:default）：

# appns中的RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-rolebinding
  namespace: appns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: app-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: appns

# appns1中的RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-rolebinding1
  namespace: appns1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: app-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: appns

方式2：更高效的ClusterRole+ClusterRoleBinding（推荐） #

如果需要监控的命名空间较多，重复创建Role会非常繁琐，更推荐继续使用ClusterRole，配合ClusterRoleBinding绑定控制器的ServiceAccount，这样无需为每个命名空间单独配置权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: app-role
rules:
- apiGroups: [""]
  resources: ["pods", "secrets", "pods/exec"]
  verbs: ["create", "delete", "get", "list", "watch"]
- apiGroups: ["app.group.com"]
  resources: ["JavaApps", "DBApps"]
  verbs: ["create", "delete", "get", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: app-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: app-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: appns

内容的提问来源于stack exchange，提问作者drifter