LEARN. PRACTICE. GROW.Diagnose the operation the client performs
A batch can GET configuration at startup and then open LIST and WATCH to track changes. Initial success does not establish the other paths. When resourceNames limits the object, the client needs the name field selector in corresponding list or watch requests. In the exercise, settlement-config exists and the account can GET it, but the watcher sends a selectorless request. Confirm the operation and actual request before removing the restriction. Acceptance testing should use batch identity and include a name that remains denied.
Review creation and delegation changes
Restricting an existing object’s name does not resolve all governance of its creation. For top-level resource create, do not use resourceNames as a guarantee that only that name will be created. Separate provisioning from maintenance or assess appropriate admission. In another change, roleRef is immutable: changing reader to operator requires replacing the binding and reviewing every subject. Plan transition to avoid operational access loss or unnecessary overlap. Project authorization should state who receives each operation and what evidence confirms the new boundary.
Distinguish presentation and authorization
A table displaying Secret names does not mean list permits reading names only. The API response can include contents, so review the grant as sensitive access. Also distinguish both namespaces in a RoleBinding: subject namespace identifies the ServiceAccount, while binding namespace bounds granted access. In the example, runner from ci receives operations in funds-prod. Write both dimensions in handover. Avoid proving access only with an administrative account because that can hide delegation to the wrong principal.
Confirm effective process controls
A nonroot UID is one part of the design but does not replace capability review. For a Linux Restricted v1.35 container, the standard’s permitted add-back after drop ALL is NET_BIND_SERVICE; its need should be justified. RuntimeDefault also does not mean every runtime supplies the same seccomp profile. A runtime change can alter permitted syscalls. Compare runtime, profile and failing operation before opening privileges. Document functional testing and behavior that must remain blocked after correction, with an owner responsible for maintaining the control.
Map writable surfaces and handlers
readOnlyRootFilesystem does not automatically turn mounted volumes into read-only surfaces. For /work, review mount settings, permissions, persistence and need for writes. For additional isolation, a RuntimeClass declares a handler but does not install it on nodes. If new nodes fail while old ones work, compare provisioning and scheduling eligibility. Mitigation can use already prepared capacity when authorized and sufficient. The fix should cover the next created node so every capacity expansion does not require another manual repair.
Hand an acceptance matrix to RUN
Prepare a small matrix containing principal, operation, object, scope, expected outcome and evidence. Include configuration GET and watch, denied reading of another object, behavior on the new pool and writes limited to the intended volume. Each test addresses a concrete claim; one successful capture does not establish every row. Record how to reverse the change and confirm the operations account remains autonomous. This lesson’s exercises are decisions and synthetic models, not cluster execution or verification of a real bank’s policies.
Batch GET works but its selectorless watcher fails; correcting the request retains the boundary and enables close processing.
Common pitfalls
Confusing GET with LIST; delegating to the wrong namespace account; treating UID as complete review; assuming RuntimeClass installs its handler.
Related topics: RBAC and ServiceAccounts · Seccomp and workload isolation
Minimum access and isolation should be demonstrated using the request, process and node that will perform the work.
Reference: RBAC authorization · Kubernetes v1.35; current six-domain CKS outline