Identity and workload hardening

Separate who a process is from what it may do

Linux user IDs govern operating-system file/process permissions. Kubernetes ServiceAccounts identify workloads to the Kubernetes API. RBAC grants API operations through Roles/ClusterRoles and their bindings. Application users and account authorization are another layer. A process running as UID 10001 has not thereby gained or lost permission to read a customer's account through the API.

For a worked permissions case, a diagnostic workload only needs to read Pods in microbank. A namespaced Role could allow get and list on Pods, then a RoleBinding could grant it to the selected ServiceAccount. It should not need get secrets, create deployments, or a cluster-admin binding. A Role describes permissions; the binding connects them to an identity. Creating a Pod can itself be powerful because the Pod may mount credentials or run with another account, so least privilege needs more than avoiding the word “admin.”

Read-only practice: with the lab cluster and your existing administrator access, run kubectl --context kind-microbank-advanced auth can-i list pods -n microbank and compare it with auth can-i get secrets -n microbank. These inspect your current credentials, not an application's. In your design note, predict what a restricted diagnostic account should answer: yes to its allowed Pod read, no to Secret reads. Creating and testing that account requires an explicit Role/Binding exercise; do not claim the predictions were enforced.

Start with what a process needs

Accounts does not need permission to administer Kubernetes just to receive an HTTP request. Disable unnecessary service-account token mounting. Use an image that can run as a non-root user, drop unneeded capabilities, and disallow privilege escalation. Test required writes before enabling a read-only root filesystem.

The following is a Pod-template fragment to adapt, not a complete workload:

spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: accounts
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]

The image must make required files readable to that user. PostgreSQL has its own file-ownership and initialization requirements; do not apply the same UID patch to every database container.

Read the fragment as separate controls: non-root restricts the runtime user; dropping Linux capabilities removes extra kernel privileges; disallowing privilege escalation constrains gaining more privilege; the runtime seccomp profile restricts system calls. None is a universal sandbox. Test an image's actual file access and required temporary writes before adding a read-only root filesystem. A failed write to a necessary application directory is a compatibility failure to fix, while a denied write to a protected system path can be an intended result.

Admission and network controls

Pod Security Admission can warn, audit, or enforce defined standards on a namespace. Start with warnings and review each workload before enforcing. Kyverno policy authoring and broader admission governance belong to Platform engineering.

A NetworkPolicy only works when the network implementation enforces it. Verify NetworkPolicy support in your kind network before relying on it for isolation. In a policy-capable lab, test both the allowed path and a denied path. Remember DNS and the app's database/emulator dependencies when designing egress rules.

Checkpoint

Show the effective user, mounted-token choice, required writable paths, and a successful transaction after hardening. Then deliberately attempt one operation that should be denied. A manifest containing security fields is evidence of intent; the observed enforcement and working application establish whether that intent was implemented.

Separate identity layers

Revisit application authentication. Kubernetes RBAC governs API operations, cloud workload identity governs provider calls, and MicroBank authorization governs a user's account operations. A non-root Pod or signed image does not implement those missing application checks.

For a future cloud adapter, inspect how each SDK obtains credentials before adding a ServiceAccount. The inspected Ledger uses explicit static credentials; changing only a manifest annotation will not select a different credential provider in that code.

Checkpoint answer: verify both a permitted user journey and an intended denied operation. If the manifest looks correct but the operation succeeds, inspect the effective Pod, identity, storage mounts, and network implementation. A NetworkPolicy object alone is not proof of enforcement. Bring one concrete before/after finding to the security lab.

Sources

Security contexts↗, Pod Security Standards↗, and NetworkPolicy enforcement↗.