[RBAC DOC] Note about resourceNames giving misleading informations

[NahisWayard]

This is a Feature Request

What would you like to be added

Update the RBAC documentation to clarify that while you cannot restrict create requests by resource name for main resources, it is possible when targeting subresources (e.g., pods/exec, pods/attach, pods/portforward).

Why is this needed

The current documentation states:

You cannot restrict create or deletecollection requests by their resource name. For create, this limitation is because the name of the new object may not be known at authorization time.

This is incorrect for subresources. You can use the create verb along with resourceNames when targeting subresources. Accurate documentation is crucial for correct RBAC policy configuration.

Comments

Proof of concept manifests:

apiVersion: v1
kind: Namespace
metadata:
  name: demo-rbac
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: debian-nonroot
  namespace: demo-rbac
spec:
  replicas: 2
  selector:
    matchLabels:
      app: debian-nonroot
  template:
    metadata:
      labels:
        app: debian-nonroot
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
      containers:
      - name: debian
        image: debian:latest
        command: ["sleep", "infinity"]
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-sa
  namespace: demo-rbac
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: demo-role
  namespace: demo-rbac
rules:
# OK
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
  resourceNames: ["debian-nonroot-0"]

# IGNORED
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create"]
  resourceNames: ["test-create"]

# OK
- apiGroups: [""]
  resources: ["pods/portforward"]
  verbs: ["create", "get"]
  resourceNames: ["debian-nonroot-0"]

# OK
- apiGroups: [""]
  resources: ["pods/attach"]
  verbs: ["create"]
  resourceNames: ["debian-nonroot-0"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: demo-rolebinding
  namespace: demo-rbac
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: demo-role
subjects:
- kind: ServiceAccount
  name: demo-sa
  namespace: demo-rbac
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: demo-view-rolebinding
  namespace: demo-rbac
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: ServiceAccount
  name: demo-sa
  namespace: demo-rbac

# Should work
kubectl exec -n demo-rbac debian-nonroot-0 --as system:serviceaccount:demo-rbac:demo-sa -- ls

# Should fail (not authorized on debian-nonroot-1)
kubectl exec -n demo-rbac debian-nonroot-1 --as system:serviceaccount:demo-rbac:demo-sa -- ls

# Should fail (resourceNames on pods is ignored)
kubectl run --as system:serviceaccount:demo-rbac:demo-sa --image test wrong-name -n demo-rbac

# Should also fail (resourceNames on pods is ignored)
kubectl run --as system:serviceaccount:demo-rbac:demo-sa --image test test-create -n demo-rbac

# Should work
kubectl port-forward -n demo-rbac pods/debian-nonroot-0 8080:8080 --as system:serviceaccount:demo-rbac:demo-sa

# Should fail (not authorized on debian-nonroot-1)
kubectl port-forward -n demo-rbac pods/debian-nonroot-1 8080:8080 --as system:serviceaccount:demo-rbac:demo-sa

[lmktfy]

/sig auth

[aramase]

/triage accepted