RBAC and Service Accounts

What you will be able to do

• Distinguish request subject from role rules in a realistic rbac and service accounts case.
• Interpret the operational evidence and boundary associated with rolebinding.
• Choose an appropriate action involving namespace reach without exceeding the named workload scope.
• Verify denied operation through an observable runtime result and reproducible handoff.

01

Frame RBAC and Service Accounts

Grant Kubernetes API access through subjects, Roles, bindings, namespaces, and service accounts using least privilege and denied-request evidence.

A report Pod needs to list ConfigMaps in one namespace but must not read Secrets or modify workloads anywhere.

Keep declared state, runtime state, observable evidence, access boundaries, and recovery outcomes separate. Begin with the smallest read-only inspection that identifies the exact image, container, Pod, controller, network, storage object, or policy in scope.

02

Request subject

A ServiceAccount provides a namespaced identity that a Pod can use when calling the Kubernetes API. Within rbac and service accounts, this role answers one specific container or orchestration question and keeps its own evidence.

Assign a dedicated report ServiceAccount to the Pod. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not reuse the namespace default account for unrelated elevated work. The observable result is specific: api audit context identifies the dedicated workload account.

03

Role rules

An RBAC Role contains additive permission rules for resources within a namespace. Within rbac and service accounts, this role answers one specific container or orchestration question and keeps its own evidence.

Grant only get and list on ConfigMaps in the report namespace. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not add wildcard resources or verbs for convenience. The observable result is specific: the role contains no secret or workload-write permission.

04

RoleBinding

A RoleBinding associates a Role or ClusterRole with subjects in a namespace. Within rbac and service accounts, this role answers one specific container or orchestration question and keeps its own evidence.

Bind the report Role to the dedicated ServiceAccount. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not bind a broad cluster-admin role to solve one denied request. The observable result is specific: the intended subject receives only the named role permissions.

05

Namespace reach

A RoleBinding grants permissions in the namespace where the binding exists. Within rbac and service accounts, this role answers one specific container or orchestration question and keeps its own evidence.

Test the same request in the intended and another namespace. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not assume a namespaced role grants cluster-wide access. The observable result is specific: configmap listing succeeds only in the report namespace.

06

Denied operation

RBAC authorization should deny requests not covered by an applicable grant. Within rbac and service accounts, this role answers one specific container or orchestration question and keeps its own evidence.

Verify Secret reads and Deployment changes are forbidden. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not weaken the policy without inspecting the exact denied verb and resource. The observable result is specific: required access succeeds and prohibited requests remain denied.

07

Apply RBAC and Service Accounts to One Workload

Use one bounded workload decision: A report Pod needs to list ConfigMaps in one namespace but must not read Secrets or modify workloads anywhere.

First, assign a dedicated report serviceaccount to the pod. Then, grant only get and list on configmaps in the report namespace. Preserve both observations with the exact resource identity before changing runtime state.

Next, bind the report role to the dedicated serviceaccount. After that, test the same request in the intended and another namespace. Close the task only after you verify secret reads and deployment changes are forbidden.

08

Recap Before Practice and Prove

Request subject: A ServiceAccount provides a namespaced identity that a Pod can use when calling the Kubernetes API. In this workload, assign a dedicated report serviceaccount to the pod. Preserve the boundary: do not reuse the namespace default account for unrelated elevated work.

Role rules: An RBAC Role contains additive permission rules for resources within a namespace. In this workload, grant only get and list on configmaps in the report namespace. Preserve the boundary: do not add wildcard resources or verbs for convenience.

RoleBinding: A RoleBinding associates a Role or ClusterRole with subjects in a namespace. In this workload, bind the report role to the dedicated serviceaccount. Preserve the boundary: do not bind a broad cluster-admin role to solve one denied request.

Namespace reach: A RoleBinding grants permissions in the namespace where the binding exists. In this workload, test the same request in the intended and another namespace. Preserve the boundary: do not assume a namespaced role grants cluster-wide access.

Denied operation: RBAC authorization should deny requests not covered by an applicable grant. In this workload, verify secret reads and deployment changes are forbidden. Preserve the boundary: do not weaken the policy without inspecting the exact denied verb and resource.