The direct answer
Check ordinary object-write authority and the separate delegation condition for the exact proposed Kubernetes role or binding. Editing role rules, granting an existing role and approving the business request are different decisions. Keep the subject, namespace and complete current rule set fixed through review; a familiar role name is insufficient.
Ask what the helper is actually allowed to grant
A staff member asks an AI operations assistant to prepare read-only access to ordinary worker configuration. The assistant’s trusted helper can edit some authorization objects. That does not by itself answer whether it may include the requested permissions or delegate the referenced role to another subject.
The permission map still defines the job’s need, and the approval guide still governs any later authorized effect. This worksheet adds a specific API delegation boundary. It proposes no grant, service-account creation, manifest or cluster command.
The official RBAC reference shows v1.37 navigation and a modification date of 26 August 2026. Neither identifies an installed cluster or the helper’s actual permissions.
Keep role-rule editing separate from binding delegation
Role creation or update needs ordinary write permission plus either all included permissions at the role’s scope or explicit escalate authority on roles/clusterroles. Binding creation or update separately needs ordinary write permission plus all referenced permissions at the binding’s scope or bind authority on the referenced role.
Do not interchange those checks. A helper’s ability to prepare a role definition says nothing about whether its identity may publish it. Likewise, an approved existing role does not mean every helper may bind it. Record which exact operation is proposed and which supported authority evidence applies.
Explicit exception authority deserves its own review. If H-A has broader delegation capability, do not claim that a default prevention check necessarily blocks every attempted expansion. Nor should the application acquire an exception to make a rejected proposal succeed. This selected positive uses ordinary binding-write authority and independently established possession of the complete admitted rule set; it adds no bind or escalate grant.
Fix the namespace effect and the rule set being referenced
A RoleBinding can reference a ClusterRole while granting its namespaced permissions only within the binding’s namespace. A ClusterRoleBinding instead grants access cluster-wide. The referenced object’s kind alone does not determine the grant’s effective namespace.
Invent namespace N-A, existing owned service account W-A and existing independently reviewed ClusterRole R-A. The proposal is one RoleBinding in N-A. R-A contains only the admitted read-only namespaced configuration rules. No secret access, workload creation, aggregation, default-role behavior, wildcard or impersonation path belongs to this plan.
Trusted setup identifies W-A and its namespace association; model text cannot choose the authenticated helper identity or substitute a subject. Retain the complete current API-group/resource/verb/scope restrictions under review, rather than trusting a role label such as “reader.” Actual rule contents and authority to change them require independent evidence.
A change to the binding kind, namespace, subject or referenced rule set changes the proposal. Hold it for a new scope review rather than treating it as a correction to spelling. The application must also establish who can change R-A; this worksheet promises neither immutable role rules nor immediate revocation behavior.
Use one original delegation review sheet
Propose record G-A for helper H-A, owned subject W-A, N-A, R-A and the intended read-only configuration purpose. These are inert labels, not observed identities, resources or grants. The owner’s policy independently admits the configuration data for that purpose.
| Decision | Evidence needed before eligibility |
|---|---|
| Actor | Authenticated H-A and complete effective authority for this exact operation. |
| Proposed effect | One fixed subject, namespaced binding and current referenced rule set. |
| API gate | Ordinary write authority and the applicable separate delegation condition. |
| Rule ownership | Independently reviewed R-A contents and controlled change path. |
| Business gate | Current owner approval, data classification and intended configuration purpose. |
The useful positive is conditional eligibility of this exact proposal for separately authorized execution review. Actual authentication, cluster behavior, effective helper permissions, exception inventory, role contents, subject association and current application authority are unimplemented or unknown. Their absence blocks a real positive.
Keep intended proposal, API authorization evidence, owner approval and execution outcome as distinct fields. A saved review sheet establishes no completed write. If a later authorized write has an unknown outcome, do not claim that the subject definitely has or lacks access merely because the review was accepted.
Review eight inert grant-proposal cards
All cards are PROPOSED_UNRUN. They involve no permission probe, resource serialization or cluster access.
| Card | Condition | Proposed disposition |
|---|---|---|
| 1. Ordinary proposal | G-A matches; complete API and business prerequisites independently hold. | Conditionally admit only this proposal’s review. |
| 2. Role-write shortcut | Helper can edit an object but the proposed rule authority is absent. | Do not treat the write grant as sufficient. |
| 3. Existing-role shortcut | Referenced role is reviewed but delegation evidence is absent. | Hold; existence and approval do not establish helper authority. |
| 4. Explicit exception | Broader bind/escalate authority is discovered. | Review that exposure; infer no business approval. |
| 5. Namespaced reference | The fixed namespaced binding references R-A. | Review the declared namespace effect, not the name alone. |
| 6. Wider binding | Kind, subject or namespace differs from G-A. | Reject under this fixed plan. |
| 7. Changed rules | R-A or its change ownership no longer matches review. | Hold the current association; no stale approval. |
| 8. Independent denial | API evidence matches but current owner approval or data policy fails. | Withhold execution independently. |
Keep API permission smaller than complete operational safety
This is not an authorization-order analysis, user-provisioning design, cluster bootstrap procedure or guarantee against every privilege-escalation route. It supplies no rule-management adapter, effective-permission collector, approval engine or recovery controller. Current request and output rights remain separate from a proposed grant.
No role, binding, service account, manifest, API request, CLI command, permission test, cluster or runtime fixture was created, inspected or exercised. No model experiment occurred. Documentation and editorial work are separate. Boundary remains prelaunch with planned request-path checks, not a shipped RBAC manager; its mock policy evidence validates different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.