Governance & Power
Service Accounts and Delegated Identity
Identity is how the cluster knows who is acting. Delegation is how it limits what they can do.
Text
Authored as doctrine; evaluated as operations.
Doctrine
A service account is institutional identity. It is not an implementation detail. It is the boundary between a workload and the authority of the platform.
Kubblai doctrine: delegated identity must be minimal, auditable, and revocable.
Token behavior and modern best practice
Prefer projected, short-lived tokens with explicit audiences. Avoid long-lived secrets-backed tokens where possible.
Identity that cannot expire becomes permanent liability.
Workload identity integrations (tradeoffs)
Cloud workload identity can remove static credentials, but it adds a policy layer and a failure mode. Understand token exchange, caching, and rotation semantics.
Test what happens when the identity provider is slow or down.
Operator checklist
Identity is governance; govern it like governance.
- Every service account has an owner and a purpose.
- RBAC bindings are minimal and reviewed.
- Secrets access is rare and justified.
- Audit logs are retained and searchable for identity actions.
Canonical Link
Canonical URL: /library/service-accounts-and-delegated-identity
Related Readings
Governance & Power
LibraryRBAC and the Governance of Power
RBAC is the cluster’s constitution. Poorly written, it becomes silent catastrophe during incident response.
Governance & Power
LibrarySecrets, Sealing, and the Cost of Exposure
Secrets are not ‘data.’ They are risk with a lifecycle. Treat them as such or they will own your platform.
Governance & Power
LibraryAdmission Control and the Rite of Judgment
Admission is where governance becomes enforceable. It is also a place where outages are born.