A ClusterRole Does Not Grant Every Namespace by Its Name

Separate the reusable definition from its assignment

An offer saying the operator receives a ClusterRole leaves two questions open: which rules does that definition contain, and which binding assigns them to the operator? The word ClusterRole answers neither by itself.

The Kubernetes v1.34 RBAC reference distinguishes a namespaced Role from a nonnamespaced ClusterRole. A RoleBinding can reference a Role in its own namespace or a ClusterRole. A ClusterRoleBinding references a ClusterRole. This lets one common definition serve different namespace assignments without changing its rules.

The explanation here uses the official archived v1.34 documentation and version-pinned implementation references. It is a comparison of proposed access, with a fictional example below; it supplies no policy manifest, configuration procedure or performed access test.

References: [K1][K3]

Match a specific request to an applicable rule

For a resource request, identify the authenticated user and relevant groups, the target namespace where applicable, the API group, resource, any subresource, and the requested verb. A user name in a proposal must correspond to the subject actually covered by the binding. Bindings can name users, groups or ServiceAccounts; those subject kinds are not interchangeable.

Next, resolve the binding's roleRef to the rules it references. For an applicable binding, a matching rule must cover the request's API group, resource or subresource, verb and any resource-name restriction. Kubernetes v1.34's rule matcher checks these conditions together for a resource request. Seeing the desired verb somewhere in a role and the desired resource in an unrelated rule does not establish that combination.

For Pods, the resource name is pods in the core API group, represented by an empty API-group string. Getting one Pod and listing a Pod collection use different Kubernetes verbs: get and list. A broad label such as read access conceals that distinction.

References: [K2][K3][K4]

RB-57: the same Pod-read rules, two namespace reaches

Assume an authenticated fictional user U and a ClusterRole G containing one rule: get and list on core-API pods, with no resource-name restriction, wildcards or other rules. The namespaces train and eval contain the Pod objects considered here. Compare two alternative assignments to U, each considered separately.

Alternative A is a RoleBinding in train referencing G. A supplies the subject assignment and the train namespace scope. U's get request for a Pod in train matches that scope and G's rule. The otherwise equivalent get request in eval falls outside A's namespace.

Alternative B is a ClusterRoleBinding referencing the same G for the same U. Its assignment reaches matching Pod requests across namespaces, so both train and eval get requests match. G has not changed; the difference comes from its binding.

The list permission follows the same distinction: A grants listing Pods within train, while B grants listing Pods across namespaces. A broader namespace reach changes which Pod collections the grant covers, while preserving the verbs and resources in G.

References: [K1][K3][K4]

A wider binding cannot supply a missing verb or resource

The delete comparison fails at the verb: G contains get and list, so neither assignment derives a delete permission from it. Changing the binding's namespace reach leaves that missing verb unchanged.

The log comparison fails at the resource match. Kubernetes represents a Pod's log subresource as pods/log in RBAC rules. Even though the log belongs to a Pod and the request uses get, the example's pods-only rule does not cover it. Moving from A to B expands namespace reach without adding that subresource.

Resource scope matters too. Nodes are cluster-scoped resources, and a namespace RoleBinding cannot grant access to them. A ClusterRoleBinding could grant matching Node permissions from a suitable ClusterRole, but G has no Node rule. The same reasoning prevents treating a cluster-wide Pod-read assignment as authority over every kind of object.

References: [K1][K3][K4]

A missing grant leaves the complete decision to establish

The matrix describes what each named binding contributes. Not granted by A is not a universal denial for U. RBAC permissions are additive and have no deny rules: another applicable binding could grant the otherwise missing access, including through a group to which U belongs. An omitted verb in one role does not cancel a grant supplied elsewhere.

Other configured authorizers can also affect the API server's decision. In the v1.34 authorization model, authorizers are considered in order; an allow or deny ends that sequence, while no opinion permits evaluation to continue. If all return no opinion, the request is denied. These rules explain why an isolated RBAC excerpt cannot establish the complete authorization result.

For a real offer, have the appointed platform owner substantiate effective access for the exact subject and request, considering all applicable assignments and the actual authorization arrangement. Keep the narrower conclusion when only one binding has been explained. Permission to make an API request also does not establish that an object exists or that an application operation has completed.

References: [K1][K2][K4]

Decide whether the offered access covers the work

Suppose a buyer needs the receiving operator to inspect Pod objects in both train and eval. Alternative A alone leaves the eval requirement unmet by its grant. Alternative B covers that namespace requirement for get and list under the example's assumptions. If the same offer also promises log access or deletion, neither alternative's G supports those additional claims.

A useful explanation of the offer connects the intended operator, the referenced rules and the binding's reach to each required request. If it supplies G's definition but omits the binding, namespace reach is unresolved. If it supplies a binding but omits G's rules, the allowed operations are unresolved. The buyer needs both parts to assess the offered result.

Retain any actual rule constraints in that comparison. A resourceNames restriction can limit the object names covered, and an aggregated ClusterRole needs its resulting rules understood. The example deliberately has neither complication. Evaluate the actual rule set being offered rather than assuming a familiar role name has a fixed meaning.

The related resource-authorization guide examines how decisions reach enforcement. The JWT guide concerns token recipient, time and permission; the Secret guide traces delivery into an application. Use those for their separate questions after establishing the concrete Kubernetes grant.

References: [K3][K4]

Name the operating team at the physical handoff

Where the platform purchase also requires GPU equipment installation, the related cluster-management handoff guide helps identify the operating team receiving the environment. That team's access requirements can be stated separately from the equipment and connection records it receives.

Leviathan's Complete Physical Infrastructure Deployment service offers agreed receiving, rack integration, onsite deployment, IT cabling and physical records. Use the service and project inquiry below to discuss a nonconfidential equipment outline, site, required physical stages and receiving team. Kubernetes authorization design, account configuration and software acceptance remain with the appointed platform and security owners.

References: [L1]