An accountable database access pattern
How do you attribute database actions to a workload and manage its access lifecycle?
D01 · Identity Fundamentals · D03 · Authorization & Access Control · D07 · Identity Governance & Administration (IGA) · D09 · Non-Human Identity (NHI) · D10 · Cloud & Workload Identity
Scenario
A fictional application uses a shared database login across multiple services. Teams want distinct ownership and less persistent credential exposure.
Learning outcomes
- Inventory workload and database identities with accountable owners.
- Design credential issuance, rotation and revocation.
- Produce a service-to-database permission table and a revocation test plan.
Engineering investigation
- Inventory each workload, owner, database role and required operation.
- Evaluate supported workload authentication or a credential broker; verify compatibility before choosing a design.
- Test renewal, connection pooling, expiry, revocation and the audit trail.
Proposed trust flow
- Application workload
- Identity / credential broker
- Database role
- Query audit
This flow is an editorial model to investigate, not a verified deployment.
Engineering trade-off
Credential expiry and existing database connection lifetimes are different controls; validate both.
Verified source statement
Primary reference: SPIFFE · Overview. Reviewed 3 November 2026.
Only the bounded statement above is source-backed. The company context, investigation, controls and flow are teaching proposals. Confirm support and behavior in your chosen environment.
Produce evidence
Produce a service-to-database permission table and a revocation test plan.
Use L1 to explain the mechanism, L2 to analyze trade-offs, L3 to implement and test, and L4 to design and justify. Reading alone does not establish competence.