LEARN. PRACTICE. GROW.Test the identity that will operate
The disposable cluster administrator creates ServiceAccount support and requests a temporary token through TokenRequest. A private kubeconfig uses that token for support requests. The script does not use impersonation and does not include the token in reports. Before grants, getting Pod worker returns Forbidden, showing that the authenticated credential lacks the requested authorization. Administrative credentials are confined to setup and policy changes in the experiment. In a real environment, human access may depend on SSO and groups; this lab does not validate that integration or replace testing the identity the team will actually use.
Reading an object does not allow every operation
The first Role allows get, list and watch on pods and is attached to the ServiceAccount through a RoleBinding in the lab namespace. Getting the Pod and listing Pods now work. Reading logs remains denied because it uses the pods/log subresource. The lab adds a Role allowing get on that subresource, restricted to name worker. Worker logs become available while placement logs remain denied. The rule must reflect the task and correct resource. For workloads whose names change, a name restriction requires a support design compatible with that renewal rather than assuming a permanent Pod name.
Scope and negative checks
The same ServiceAccount attempts to read a Pod in the quota namespace and receives Forbidden. It also cannot list Secrets, execute a container command or request server-dry-run Pod deletion. Worker remains running. These checks distinguish diagnostic access from the ability to execute or change work. Dry-run denial matters because requesting no persistence does not remove the operation’s authorization requirement. The experiment grants no global permissions and changes no policies in existing unrelated namespaces. For acceptance, retain examples of allowed and denied actions with identity, scope and observed outcome rather than only a list of Role names.
Query authorization and execute the task
With grants active, auth can-i confirms Pod reading, worker-log reading and denial for Secrets. The lab complements the query with actual requests: reading Pods and logs and attempting to list Secrets. An authorization query helps locate a denial, but does not establish that useful logs exist, networking is available or the process is healthy. Interpret yes alongside the resource, verb, subresource, name and namespace used in the query. Record the precise query and avoid extrapolating from get pods to exec or from one namespace to all namespaces. Complete acceptance connects permission with the support workflow that needs to function in the intended operational environment.
Additive grants and partial revocation
The experiment creates two RoleBindings granting the same log access. After removing the first, the request remains authorized through the second. This is neither failed revocation nor an ignored deny rule: RBAC permissions are additive. Removing one access source does not erase the others. The script then removes the second binding and confirms log denial while Pod reading remains allowed through the reader Role. Only afterwards does it remove reader and confirm get denial. During excessive-access handling, identify every applicable grant and validate the outcome after each authorized change rather than infer success from deleting one binding.
Close credentials and preserve boundaries
The script removes namespaces it created and deletes the private directory containing the support credential and local caches. The token is not saved in evidence. Execution uses a single-node cluster, a synthetic application and permissions created only for the experiment. It does not cover enterprise SSO, external-group management, network policies, distributed resilience, load or human review. In a fictional APS handover, deliver the operation matrix, positive and negative results and revocation procedures. Specialist review should assess whether that matrix fits actual responsibilities and how it will be maintained when workloads and teams change over time.
# Use a dedicated temporary support kubeconfig; never put tokens in reports.
kubectl --kubeconfig SUPPORT_CONFIG -n LAB get pod worker
kubectl --kubeconfig SUPPORT_CONFIG -n LAB logs worker
kubectl --kubeconfig SUPPORT_CONFIG -n LAB auth can-i get pods/worker --subresource=log
# Also test expected denials and revoke every applicable grant at closure.Reading Pods did not permit reading logs; a separate Role allowed only worker’s pods/log while exec, Secrets and another namespace remained denied.
Common pitfalls
Reading Pods as access to logs or exec; RoleBinding as global permission; removing one binding as revoking every authorization path.
Related topics: Resources and scheduling · Minimum access for support
Validate effective access with the intended identity and repeat checks after granting or removing permissions.
Reference: Using RBAC authorization · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed