Kubernetes Secrets are a distribution problem, and the database is where it shows

Nothing in a Secret binds the credential to the workload that reads it. Red Hat's own list of complaints concedes as much: rotation, distribution and revocation are manual operations, and the same value ends up spread across replicas and across teams ^[5]. A credential that can be copied answers no useful question about which caller is on the other end of the connection.

The consequence the post states plainly is the one worth doing arithmetic on. An exposed Secret stays valid until somebody notices ^[6]. Because revocation is a manual step ^[5], the working life of a leaked credential is detection time plus response time, and neither of those is a number the platform sets ^[14]. Cryptographic workload identity issued without long-lived tokens does not make leaks less likely; it moves the leak's useful life from your monitoring into issuance policy ^[7].

Why the database is the wedge rather than service-to-service traffic: most systems serve one class of caller, and databases are the exception, frequently the same instance and sometimes the same tables ^[2]. The human side of that boundary is already settled, through OIDC, SAML or LDAP federated via an identity provider such as Microsoft Entra ID or CyberArk, with authorization landing either in OpenShift RBAC or in database roles and row-level policies ^[8]. Red Hat's position is that the pipeline, the integration service and the AI agent are principals on the same footing as the DBA, each needing to be identifiable, authorized and auditable ^[9]. That is the sentence that does the work, because the database is where the two mechanisms have to agree on one answer.

Two things the material does not settle. The first is delegation: enterprise applications often need to act on behalf of a user ^[12], and the supplied excerpt breaks off mid-sentence as it starts that example ^[13], so the hardest case for workload-bound identity is left open here. The second is operational evidence. What is on offer runs on Red Hat's platform, delivered through Red Hat's own component ^[7], and stops at patterns, lessons learned and a demo ^[11] rather than issuance intervals or a production comparison.

For a team whose agents already query the same store as its analysts, the sequencing is the transferable part. The identity claim is only worth what the data store will accept in place of a password, and that acceptance lives in the database's role model ^[8], not in the platform that issued the certificate.