A new hire’s kubeconfig user can get Nodes but cannot create NetworkPolicies. What is the most likely RBAC gap?
Select an answer to reveal the explanation.
Short Explanation
Having eyes on the map of Nodes does not unlock drafting street rules. Create on NetworkPolicies needs an explicit rule for that resource and the networking.k8s.io apiGroup. Missing verb or wrong apiGroup is the usual gap—not a CoreDNS context typo.
Full Explanation
When a new hire’s kubeconfig user can get Nodes but cannot create NetworkPolicies, the gap is almost always missing RBAC rules for the networkpolicies resource in the networking.k8s.io apiGroup with the create verb. Nodes and NetworkPolicies are independent resources; permission to view the city map of Nodes does not unlock drafting street-level NetworkPolicy objects. Fix the Role or ClusterRole (and its binding) to include that explicit rule. A missing current-context entry related to CoreDNS might break kubectl context selection, but it does not selectively allow get nodes while denying NetworkPolicy create. The idea that Nodes and NetworkPolicies share one resource name so get-on-nodes blocks create is false—they are different resources and apiGroups. NetworkPolicies are not restricted to ServiceAccounts only; Users and groups are valid RBAC subjects just as ServiceAccounts are. Exam caveat: RBAC matches apiGroups, resources, and verbs independently—always check the apiGroup for namespaced networking objects (networking.k8s.io). Operational check: run kubectl auth can-i create networkpolicies.networking.k8s.io (and in the target namespace if namespaced), inspect the subject’s Role/ClusterRole rules, add create on networkpolicies, re-bind if needed, and retest.