Kubernetes跨命名空间资源访问权限管控方案咨询

Alright, let's break down how to implement your desired permission controls in Kubernetes—this is a super common setup for multi-team, multi-environment clusters, so we can use standard RBAC and NetworkPolicy tools to get it done.

1. Block Cross-Namespace ConfigMap Access (RBAC) #

By default, Kubernetes ServiceAccounts don't have cross-namespace access to resources unless explicitly granted. So we'll lock down each team's namespace to only let their apps access their own ConfigMaps.

• First, create a dedicated ServiceAccount for each team's namespace (e.g., team-a-sa in team-a namespace). Always avoid using the default default SA—it's easier to manage permissions with dedicated ones.
• Next, define a Role in the team's namespace that only allows ConfigMap operations within that namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: team-a-configmap-access
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"] # Adjust verbs if your apps need update/delete, but read-only is safer

• Bind this Role to the team's ServiceAccount with a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: team-a
  name: bind-team-a-configmap-access
subjects:
- kind: ServiceAccount
  name: team-a-sa
  namespace: team-a
roleRef:
  kind: Role
  name: team-a-configmap-access
  apiGroup: rbac.authorization.k8s.io

Now any app in team-a using team-a-sa will get denied if it tries to fetch a ConfigMap from another namespace—perfect for that isolation.

2. Allow Cross-Namespace REST Access via Ingress/Service (NetworkPolicy) #

To let apps call REST services in other namespaces, we need to open up network traffic (since RBAC doesn't control network flow). NetworkPolicies are the way to go here—just make sure your cluster uses a network plugin that supports them (like Calico or Cilium).

Example: Allow access to a specific service in another namespace #

If team-a apps need to hit a REST service in team-b on port 8080, create this NetworkPolicy in team-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: team-a
  name: allow-team-b-rest-access
spec:
  podSelector: {} # Matches all pods in team-a
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          team: team-b # Target namespace's label
      podSelector:
        matchLabels:
          app: team-b-rest-service # Target service's pod labels
    ports:
    - protocol: TCP
      port: 8080

For Ingress access, you can either allow egress to your Ingress Controller's pods, or if you're using a cluster-wide Ingress IP, allow traffic to that IP range. Cross-namespace Service access works out of the box as long as the NetworkPolicy doesn't block it—just make sure your apps use the full service DNS name (<service-name>.<namespace>.svc.cluster.local).

3. Extra Restrictions for DEV Environment Apps #

You mentioned DEV apps shouldn't have certain permissions—let's cover the most common restrictions here (feel free to adjust based on your exact needs):

Restrict DEV to read-only API access #

Prevent DEV apps from modifying resources in their namespace with a read-only Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a-dev
  name: dev-read-only
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
# No create/update/delete verbs here—so DEV apps can't make changes

Block DEV from accessing PROD namespaces #

Use a NetworkPolicy to cut off DEV traffic to any PROD environment:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: team-a-dev
  name: block-prod-traffic
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: environment
          operator: NotIn
          values: ["prod"]
  # This allows egress to all non-PROD namespaces—adjust if you need tighter rules

Quick Pro Tips #

• Label your namespaces with team: <team-name> and environment: <env>—this lets you write reusable RBAC and NetworkPolicy rules instead of duplicating for every namespace.
• Always test permissions with kubectl auth can-i commands (e.g., kubectl auth can-i get configmaps --namespace team-b --as system:serviceaccount:team-a:team-a-sa) to verify your setup works.
• If you have a lot of teams, consider using ClusterRoles with Namespace selectors to avoid repeating Role definitions.

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