Enterprise security used to draw a clean line: humans log in; machines use secrets. But that line is blurring, and interactions with databases are often where you’ll encounter that ambiguity. Historically, authentication has followed a familiar path: usernames and passwords are stored in configuration or Kubernetes Secrets; long-lived tokens and API keys are often kept in Secrets as well, on the assumption they are safer than passwords. In practice, however, Secrets bring many of the same problems. They must be rotated, distributed, and revoked manually; they are frequently shared across replicas or teams; and if a Secret is exposed, an attacker has a credential that remains valid until someone notices.For applications like databases, the situation is even more complex. The same data store must serve humans (analysts and DBAs connecting through corporate identity systems like OIDC and OAuth) and machines (microservices, pipelines, and AI agents that connect programmatically). The risks of misconfiguration, identity theft, and security breaches grow quickly.In this blog post, we’ll delve into this problem in more detail, and then walk through how SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment), delivered on Red Hat OpenShift via the zero trust workload identity manager, give workloads cryptographic identity without long-lived passwords or tokens. We’ll start with the ideal situation—2 SPIFFE-enabled applications talking to one another—then provide a roadmap for enterprises to actually adopt the solution, using application-to-database access as a practical first step. We’ll finish with 2 concrete authentication patterns, a discussion of the lessons learned as we built them, and a demo that you can run yourself.Why identity matters in the enterpriseHumans, workloads, and security principalsIn a previous blog post, we described how authentication and authorization work in Kubernetes and OpenShift for microservices architectures. If you’ve worked with those types of platforms for a while, you’ll know that a lot of the complexity around security starts with a simple question: who is calling what?A key consideration in that blog post is the difference between human users and non-human users like service accounts. In secured enterprise systems, a human might need to prove their identity for a number of reasons: to access web applications interactively, to use command-line interface (CLI) tools, or to connect to administrative consoles. In most enterprises, that path is already well understood. People authenticate through OpenID Connect (OIDC), SAML, or LDAP, often federated via an identity provider (IdP) such as Microsoft Entra ID or CyberArk. Once you’re authenticated, authorization might be configured in the platform itself (via OpenShift role-based access control, or RBAC, for example), or may be specified further downstream in an application or a data store (such as database roles or row-level policies). That human identity, an entity that a system can verify and then use to grant permission to access resources, is what we call a security principal, or simply a principal.But workloads must also be identifiable. A microservice, a batch job, a data pipeline, an AI agent, or an integration service is still a caller. When a containerized application makes a request to an API or opens a database connection, that caller is a principal too. It needs to be identifiable, authorized, and auditable, in the same way a person logging into a web console would be.However, as outlined in Table 1, the mechanisms for authenticating each type of caller are different and that’s where a lot of the confusion (and risk) arises.Table 1. Authenticating humans vs. authenticating workloadsIdentity typeTypical credentialTypical useHumanOIDC/OAuth token, sessionConsole, ad hoc queries, break-glassWorkloadCryptographic identity (certificate or token)Service-to-service, app-to-databaseEven though the underlying question is the same—which principal is this caller?—the answer is usually provided by different mechanisms, as illustrated in Figure 1.