如何在Kubernetes中创建排除特定命名空间访问权限的用户

Great questions! Let's break down each scenario step by step using Kubernetes RBAC—the standard way to manage user permissions in your cluster.

1. Create a user with access to all namespaces except one #

To pull this off, we'll use a ClusterRole that targets all namespaces except the excluded one, paired with a ClusterRoleBinding to attach those permissions to our user. Here's the play-by-play:

Step 1: Create a ServiceAccount (Kubernetes' version of a "user") #

First, let's make a ServiceAccount (we'll name it all-ns-except-restricted for clarity):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: all-ns-except-restricted
  namespace: default # You can use any namespace you prefer here

Apply it with:

kubectl apply -f sa-all-ns.yaml

Step 2: Label the namespace you want to exclude #

Let's say we're blocking access to restricted-ns. Add a unique label to it so our ClusterRole can target it for exclusion:

kubectl label namespace restricted-ns access=denied

Step 3: Create a ClusterRole with namespace filtering #

This ClusterRole will grant access to your desired resources in all namespaces that don't have the access=denied label:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: all-namespaces-except-restricted
rules:
- apiGroups: [""] # Core API group; add others like `apps` or `batch` if needed
  resources: ["pods", "services", "configmaps"] # List exactly the resources you want to allow
  verbs: ["get", "list", "watch"] # Adjust verbs based on needs (e.g., `create`, `update`)
  namespaceSelector:
    matchExpressions:
    - key: access
      operator: NotIn
      values: ["denied"]

Apply it:

kubectl apply -f clusterrole-all-ns.yaml

Step 4: Bind the ClusterRole to the ServiceAccount #

Create a ClusterRoleBinding to link our ServiceAccount to the ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-all-ns-except-restricted
subjects:
- kind: ServiceAccount
  name: all-ns-except-restricted
  namespace: default
roleRef:
  kind: ClusterRole
  name: all-namespaces-except-restricted
  apiGroup: rbac.authorization.k8s.io

Apply it:

kubectl apply -f clusterrolebinding-all-ns.yaml

Verify the setup #

Test access by impersonating the ServiceAccount:

# Should work: list pods in an allowed namespace
kubectl --as=system:serviceaccount:default:all-ns-except-restricted get pods -n default

# Should fail: list pods in the restricted namespace
kubectl --as=system:serviceaccount:default:all-ns-except-restricted get pods -n restricted-ns

2. Create kubernetes-dashboard user with access to ns1, ns2, ns3, ns5 (deny ns4) #

We have two solid approaches here. Let's start with the most maintainable one, then cover the explicit per-namespace method.

Approach 1: Use namespace labels & a single ClusterRole #

Step 1: Create the kubernetes-dashboard ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubernetes-dashboard
  namespace: default # Use the namespace where your dashboard is deployed if different

Apply it:

kubectl apply -f sa-dashboard.yaml

Step 2: Label allowed namespaces

Add a label to ns1, ns2, ns3, ns5 to mark them as accessible:

kubectl label namespace ns1 ns2 ns3 ns5 access=allowed

Leave ns4 unlabeled (or tag it with access=denied if you want to be explicit).

Step 3: Create a ClusterRole for allowed namespaces

This ClusterRole will grant permissions only to namespaces with the access=allowed label:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dashboard-allowed-namespaces
rules:
- apiGroups: ["", "apps", "batch"] # Include all API groups your dashboard needs
  resources: ["*"] # Or list specific resources like `deployments`, `jobs`
  verbs: ["get", "list", "watch", "create", "update", "delete"] # Adjust based on required access level
  namespaceSelector:
    matchLabels:
      access: allowed

Apply it:

kubectl apply -f clusterrole-dashboard.yaml

Step 4: Bind the ClusterRole to the ServiceAccount

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-dashboard-allowed-namespaces
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: default
roleRef:
  kind: ClusterRole
  name: dashboard-allowed-namespaces
  apiGroup: rbac.authorization.k8s.io

Apply it:

kubectl apply -f clusterrolebinding-dashboard.yaml

Approach 2: Explicit RoleBindings per allowed namespace #

If you prefer not to use labels, create a single Role and bind it to the ServiceAccount in each allowed namespace:

1. Create a Role with your desired permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dashboard-namespace-access
  namespace: ns1 # We'll reuse this Role across other allowed namespaces
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["*"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]

Apply it to each allowed namespace:

kubectl apply -f role-dashboard.yaml
kubectl apply -f role-dashboard.yaml -n ns2
kubectl apply -f role-dashboard.yaml -n ns3
kubectl apply -f role-dashboard.yaml -n ns5

2. Create a RoleBinding for each allowed namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dashboard-access
  namespace: ns1
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: default
roleRef:
  kind: Role
  name: dashboard-namespace-access
  apiGroup: rbac.authorization.k8s.io

Apply it to each allowed namespace:

kubectl apply -f rolebinding-dashboard.yaml
kubectl apply -f rolebinding-dashboard.yaml -n ns2
kubectl apply -f rolebinding-dashboard.yaml -n ns3
kubectl apply -f rolebinding-dashboard.yaml -n ns5

Verify the setup #

Test access to confirm permissions work as expected:

# Should work: get deployments in ns1
kubectl --as=system:serviceaccount:default:kubernetes-dashboard get deployments -n ns1

# Should fail: get pods in ns4
kubectl --as=system:serviceaccount:default:kubernetes-dashboard get pods -n ns4

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