多命名空间RBAC角色配置咨询：Admin/User角色绑定ns2的最佳方案

Hey there! Great start with your RBAC setup so far—since you’ve already got the admin-master and user-master ClusterRoles defined and bound to ns1, let’s walk through the cleanest ways to extend those bindings to ns2 (and the default namespace if you need it too).

Core Background #

First, a quick reminder: ClusterRoles are cluster-wide permission templates, but to limit their scope to specific namespaces, you use RoleBindings (namespace-scoped objects). This is the best practice here because it keeps permissions contained to only the namespaces you specify, instead of granting unintended cluster-wide access.

1. Option 1: Create RoleBindings via YAML (Best for Version Control) #

This method is ideal if you want to keep your configs in Git or need to customize additional fields.

For Admin Role (admin-master) in ns2 #

Create a file named rbac-admin-ns2.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-master-binding-ns2
  namespace: ns2  # Target namespace for the binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin-master  # Your existing ClusterRole
subjects:
- kind: ServiceAccount
  name: your-sa-name  # Replace with your ServiceAccount name
  namespace: ns2  # If your SA lives in ns2; adjust if it's in another namespace

Apply it with:
kubectl apply -f rbac-admin-ns2.yaml

For User Role (user-master) in ns2 #

Create rbac-user-ns2.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: user-master-binding-ns2
  namespace: ns2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: user-master
subjects:
- kind: ServiceAccount
  name: your-sa-name
  namespace: ns2

Apply with:
kubectl apply -f rbac-user-ns2.yaml

2. Option 2: Quick Create with kubectl (No YAML Needed) #

If you want to skip writing YAML files, use kubectl create rolebinding directly:

Bind Admin Role to ns2 #

kubectl create rolebinding admin-master-binding-ns2 \
  --clusterrole=admin-master \
  --serviceaccount=ns2:your-sa-name \
  --namespace=ns2

Bind User Role to ns2 #

kubectl create rolebinding user-master-binding-ns2 \
  --clusterrole=user-master \
  --serviceaccount=ns2:your-sa-name \
  --namespace=ns2

3. Extend to the default Namespace #

If you need the same permissions in default, just repeat either method above and replace ns2 with default in all namespace fields.

Verify the Bindings Work #

To make sure permissions are correctly applied, use the kubectl auth can-i command:

# Check if Admin SA can write (e.g., create pods) in ns2
kubectl auth can-i create pods --namespace=ns2 --as=system:serviceaccount:ns2:your-sa-name

# Check if User SA can only read (e.g., list pods) in ns2
kubectl auth can-i list pods --namespace=ns2 --as=system:serviceaccount:ns2:your-sa-name
kubectl auth can-i create pods --namespace=ns2 --as=system:serviceaccount:ns2:your-sa-name  # Should return "no"

Important Note #

If your ServiceAccount is not in ns2 (e.g., you created it in a shared namespace like kube-system), update the --serviceaccount flag to [sa-namespace]:[sa-name] (and adjust the YAML's subjects[0].namespace field accordingly).

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