A transit-authority microservice on OKE must call the Kubernetes API (and later OCI APIs via workload identity) under a least-privilege identity. Which Pod-level object supplies that identity?

A transit-authority microservice that must call the Kubernetes API—and later OCI APIs via workload identity—under least privilege gets its identity from a ServiceAccount referenced in the Pod specification. Every in-cluster API call the Pod makes as itself is authenticated as that ServiceAccount; RBAC (and workload identity mappings) bind permissions to that account. Dedicated ServiceAccounts per workload keep municipal blast radius small compared with sharing a broad default identity.

A ClusterRoleBinding that names the kube-admin user fails by concept because a binding grants permissions to a subject—it is not the Pod-level identity object the workload runs as, and naming a human admin identity for a Pod is the opposite of least privilege. An OCI IAM group attached to the node pool shape fails because node-pool or instance principal scope is about the worker, not the individual Pod’s identity, and would over-share credentials across every Pod on those nodes. A NetworkPolicy that lists allowed egress CIDRs fails because NetworkPolicy controls which network peers a Pod may talk to; it does not supply who the Pod is when it authenticates.

Exam caveat: creating a ServiceAccount without a tight Role/RoleBinding (and later IAM mapping) still leaves the Pod either powerless or accidentally relying on broader defaults—identity and authorization are a pair. Operational check: set serviceAccountName on the Pod, deny the namespace default SA for that Deployment, bind only the needed verbs/resources, then confirm from inside a debug path that the projected token audience and subject match the dedicated account.