Workload Identities in Kubernetes Environments

In Kubernetes and other cloud-native environments, securely identifying and authenticating services is critical for ensuring secure communication and enforcing fine-grained access controls. Traditional methods like IP-based access and long-lived credentials are no longer sufficient.

Workload identity solves these challenges by providing dynamic, verifiable identities for workloads, enabling secure service-to-service communication, enforcing zero-trust policies, and minimizing the risk of credential compromise.

This guide includes the following examples of how to use EJBCA for workload identities:

Key Challenges in Implementing Workload Identities

Setting up workload identities in Kubernetes goes beyond just issuing these identities where needed. To make them effective, there is a need to understand the challenges that can undermine trust and efficiency if not handled correctly, for example:

Managing short-lived credentials and automated rotation
Enforcing least privilege access for dynamic, ephemeral workloads
Integrating Kubernetes-native workloads with cloud IAM systems
Establishing trust between microservices in multi-cluster environments
Aligning access governance with compliance requirements

PKI & Workload Identities

Workload identities on Kubernetes leverage Public Key Infrastructure (PKI), which enables workload identity by issuing and verifying cryptographic credentials (typically X.509 certificates) that serve as secure identities for workloads. These identities are critical for mutual TLS (mTLS) between services, for signing requests, and for authenticating access to sensitive resources such as secrets, APIs, and databases.

It is tempting to rely only on the integrated tools in Kubernetes or the service meshes (e.g., cert-manager defaults, Istio Citadel, Linkerd identity, or cloud-provided workload identity). They make it easy to get started, but without considering the bigger picture, these sometimes ad hoc approaches can quickly fall short when security, compliance, and interoperability requirements increase.

By anchoring Kubernetes workload identities to your InfoSec team’s enterprise PKI standards, you avoid the hidden limitations of the default tools and gain a foundation you can actually trust at scale. This gives you:

Enterprise-grade lifecycle management — automate short-lived certificate issuance and rotation without building custom scripts.
Consistent identity models — the same certificate-based identity works across clusters, service meshes, and hybrid cloud, so you don’t have to re-engineer for each environment.
Compliance and audit built in — visibility into who requested which certificate, when it was issued, and how it was used, making audits straightforward instead of painful.
Integration flexibility — plug into IAM systems, HSMs, and existing security policies, so you align with InfoSec instead of working around them.

EJBCA PKI

EJBCA provides a flexible and extensible foundation for issuing and managing workload identities across Kubernetes clusters. EJBCA integrates with SPIRE, cert-manager, and native cloud IAM systems to enable short-lived, X.509-based workload identity issuance.

As cybersecurity threats become more sophisticated and compliance requirements become more demanding, it is increasingly important to standardize on a few trusted platforms. A well-chosen platform should provide the flexibility to support multiple deployment models, whether on-premises, in the cloud, or in hybrid environments and address a wide range of use cases across the organization.

Standardization streamlines security policies, enhances scalability, simplifies audits, ensures regulatory compliance, and improves overall operational efficiency.

EJBCA for Workload Identities, examples

Secure mTLS Communication with SPIRE + EJBCA

Problem:
Kubernetes workloads need verifiable identities to establish secure mutual TLS connections across clusters.

Solution:
EJBCA issues SPIFFE-compatible X.509 certificates for workloads. SPIRE handles identity attestation and requests short-lived certificates from EJBCA.

Architecture:

Physical: Kubernetes cluster(s), SPIRE server/agent, EJBCA CA backend (cloud/on-prem), HSM
Logical: Root CA → Sub CA → SPIRE External CA -> SPIRE-integrated workload certificates (with SPIFFE IDs)

Automated Workload Credential Issuance for Cloud Access

Problem:
Applications need secure access to cloud resources without hardcoded secrets or shared credentials.

Solution:
EJBCA issues short-lived credentials, while policies enforce which workloads can access which secrets based on their identity.

Architecture:

Physical: Keyfactor CA and Vault integration, Vault or secret storage, and Public Cloud IAM
Logical: Root CA → Sub CA → Workload-specific identities and permissions tied to access policies

Interoperable vs. Cloud-Specific Workload Identities

As cloud-native ecosystems evolve, organizations face a growing need to balance interoperability with cloud-specific integrations. With EJBCA, you can do both.

Keyfactor supports standards-based, cloud-agnostic workload identities (e.g., with SPIRE) while also working alongside native cloud identity options, including Azure Workload Identity. This ensures you can maintain flexibility and vendor neutrality, while also taking advantage of tight cloud-native integrations where they add the most value.

EJBCA has introduced support for Azure Workload Identity, enabling EJBCA applications to authenticate to services like Azure SQL without passwords, using identities managed by Azure AD. This improves both security and developer productivity, while maintaining centralized certificate lifecycle management.

PKI deployment option - Examples

EJBCA PKI can be deployed inside a Kubernetes cluster, outside the cluster, or in a hybrid model, with flexible options for integrating Hardware Security Modules (HSMs) for strong and compliant key protection. Each approach has distinct architectural considerations, benefits, and use cases

Architecture Option 1: EJBCA Deployed Inside the Kubernetes Cluster

EJBCA runs as a containerized CA service within the same Kubernetes cluster as the workloads it serves. This setup simplifies networking and service discovery, and allows EJBCA to scale with the cluster.

Components:

EJBCA CA Pod: Deployed as a StatefulSet or Deployment within the cluster.
SPIRE Server/Agents: Deployed inside the cluster to perform identity attestation and request certs.
Kubernetes Workloads: Request workload identities via SPIRE, which proxies the requests to EJBCA.
HSM: sidecar p11proxy,

Benefits:

Low-latency communication between workloads and EJBCA
Easier integration with in-cluster SPIRE, Vault, or cert-manager
Can scale elastically with cluster resources

Use Case Fit:
Best for fully cloud-native environments where the PKI can be managed alongside other services within Kubernetes.

Architecture Option 2: EJBCA Deployed Outside the Kubernetes Cluster

EJBCA runs outside the Kubernetes cluster, either on-premises or in a separate trusted cloud environment. The Kubernetes cluster connects to EJBCA over a secure interface to request workload certificates.

Components:

EJBCA CA: Hosted on VM or dedicated container infrastructure outside Kubernetes (cloud or on-prem).
SPIRE Server/Agents or cert-manager: Deployed in Kubernetes and configured to communicate with the external EJBCA CA.
Kubernetes Workloads: Obtain certificates indirectly via SPIRE/cert-manager using workload identity.
HSM: Local to the EJBCA deployment for strong key protection.

Benefits:

Clear trust boundary between Kubernetes and PKI infrastructure
Suitable for regulated environments requiring centralized CA governance
Easier to integrate with existing enterprise PKI hierarchy (e.g., Root CA on-prem)

Use Case Fit:
Best for organizations with strict security policies, hybrid/multi-cluster environments, or centralized CA management requirements.

Conclusions

Workload identity is a foundational capability for securing cloud-native infrastructure. It eliminates long-lived secrets, enables zero trust architectures, and ensures that service-to-service communication is verifiable, auditable, and compliant.

EJBCA provides the building blocks to implement scalable, standards-based, and cloud-integrated workload identity systems.

Contact us

Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.

Request a Demo