当然可行！Kubernetes的RBAC（基于角色的访问控制）就是专门用来做这种细粒度权限管控的，咱们先看看你现有配置的问题，再调整成能正常工作的版本。

首先说你的配置里的小问题：

• 你给pods/exec设置了空的verbs列表，这其实完全没必要——RBAC的核心逻辑是默认拒绝所有未明确授予的权限，所以不需要特意写这么一条来“禁止”，反而会让配置显得冗余。
• 你的ClusterRoleBinding和ClusterRole用了同一个名字developer-role，虽然Kubernetes允许这么做，但为了以后维护方便，最好给Binding起个辨识度更高的名字，比如developer-role-binding。

给你调整后的正确配置：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developer-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: developer-role
subjects:
- kind: Group
  name: developer_customized

这个配置的逻辑很清晰：

• 先创建一个developer-role的ClusterRole，只授予开发者对pods和pods/log这两个资源的get（查看单个Pod/日志）和list（列出所有Pod）权限。
• 然后通过ClusterRoleBinding把这个角色绑定到你的developer_customized用户组，这样组里的所有成员都会自动继承这些权限。

因为RBAC默认拒绝所有没明确授权的操作，所以这些开发者自然就没法用kubectl exec进入Pod（这个操作对应pods/exec资源，咱们没授权），也没法执行其他比如删除Pod、修改Deployment之类的操作。

你可以用下面的命令快速验证权限是否生效（如果不想切换用户，可以用--as-group模拟开发者组的身份）：

# 验证能否查看Pod列表
kubectl get pods --as-group=developer_customized
# 验证能否查看Pod日志
kubectl logs <你的Pod名称> --as-group=developer_customized
# 验证能否exec进入Pod，正常应该会返回权限拒绝的错误
kubectl exec -it <你的Pod名称> -- /bin/bash --as-group=developer_customized

最后提醒一句：如果这些开发者之前被绑定过其他权限更高的角色（比如edit或者admin），那这个配置可能不会生效——因为RBAC是权限累加的，你得确保他们没有被授予其他包含pods/exec权限的角色才行。

备注：内容来源于stack exchange，提问作者logax