PKIaaS Architecture Patterns for Kubernetes and Cloud-Native Workloads

Kubernetes and cloud-native environments have a certificate problem that traditional PKI was not designed to solve. Containers start and stop in seconds. Pods are scheduled across nodes dynamically. Services authenticate to each other through mutual TLS without human operators involved. Workload identity needs to be cryptographically verifiable but should require no manual certificate provisioning. And the CA/Browser Forum’s reduction of maximum TLS certificate validity to 47 days (effective March 15, 2029 under Ballot SC-081v3) makes manual certificate management in any environment with more than a handful of certificates operationally untenable.

Traditional PKI infrastructure, whether self-managed Microsoft AD CS or an aging on-premises CA, does not integrate with Kubernetes controllers, does not support ACME automation at container scale, and has no concept of workload identity in the SPIFFE sense. PKI as a Service, combined with the right Kubernetes-native tooling, addresses all of these. This post covers the specific architecture patterns: how PKIaaS integrates with cert-manager, SPIFFE/SPIRE, service mesh mTLS, and HashiCorp Vault; when to use each pattern; and how to govern the resulting certificate issuance from a policy and audit standpoint.

Quick Answer: What Does PKIaaS for Kubernetes Look Like?

PKIaaS for Kubernetes provides the root CA and governance layer; Kubernetes-native tooling handles the integration. cert-manager connects to PKIaaS via ACME with External Account Binding and automates certificate provisioning for Ingress TLS, internal services, and application certificates. SPIFFE/SPIRE connects to PKIaaS as its upstream CA for workload identity SVIDs issued to individual pods and processes. Service meshes (Istio via istio-csr, Linkerd via cert-manager trust anchor) use PKIaaS-rooted intermediate CAs for sidecar mTLS certificates. HashiCorp Vault PKI Secrets Engine can sit as an intermediate layer between PKIaaS and high-volume issuance consumers. A CLM layer above all of it provides unified certificate inventory, expiry monitoring, and policy enforcement across the full cloud-native estate.

Key Takeaways

• Kubernetes certificate management has two distinct layers: infrastructure certificates (Ingress TLS, internal service TLS, webhook certificates) managed by cert-manager, and workload identity certificates (pod and process SVIDs) managed by SPIFFE/SPIRE. Both layers benefit from PKIaaS as the upstream CA, but they connect through different integration paths and serve different purposes.
• Short-lived certificates are not just a best practice in cloud-native environments: they are the operationally correct model for ephemeral workloads. A 24-hour certificate on a container that lives for 4 hours never needs revocation infrastructure. A 90-day certificate on the same container creates a phantom entry in the CA’s certificate database that represents a workload that no longer exists. PKIaaS handles high-volume short-lived issuance at the rates cloud-native environments require.
• The cert-manager ACME ClusterIssuer with PKIaaS EAB credentials is the standard integration pattern and requires no custom code. The ClusterIssuer configuration is the only component that is PKIaaS-provider-specific; everything downstream (Certificate resources, Ingress annotations, renewal automation) uses standard cert-manager behavior.
• SPIFFE/SPIRE with PKIaaS as the upstream CA elevates workload identity from a cluster-internal trust domain to an enterprise-governed trust domain. SVIDs issued through a PKIaaS-rooted SPIRE server are verifiable against the organization’s PKI root, auditable through the PKIaaS audit log, and policy-governed by the PKIaaS certificate profile for the SVID issuance CA.
• Policy governance for cloud-native PKI is the gap that most platform teams leave unaddressed. cert-manager and SPIFFE/SPIRE handle issuance automation, but neither provides the certificate policy enforcement (allowlisted SANs, key size minimums, validity period caps, issuing CA restrictions) that compliance teams require. PKIaaS provides this at the CA level; a CA-agnostic CLM layer provides it across the full certificate estate.

Reference Architecture

The diagram below shows the full PKIaaS architecture for a Kubernetes environment, with the PKIaaS root CA at the top of the trust hierarchy and four integration paths serving different certificate consumers within the cluster.

The four integration paths shown in the diagram serve distinct purposes. cert-manager handles infrastructure certificates (Ingress TLS, service certificates, webhook certs). The Vault PKI engine handles high-volume short-lived certificate issuance for DevOps pipelines. SPIRE handles workload identity SVIDs. The service mesh CA integration handles sidecar proxy mTLS certificates. The CLM layer at the bottom collects certificate inventory from all four paths and provides unified governance.

Pattern 1: cert-manager with PKIaaS ACME

cert-manager is the Kubernetes-native certificate controller that watches for Certificate resources and Ingress annotations and automatically requests, stores, and renews certificates. It is the starting point for any Kubernetes PKIaaS integration because it handles the most common certificate consumers: Ingress TLS termination, internal service TLS, and admission webhook certificates.

ClusterIssuer Configuration

The PKIaaS integration requires a ClusterIssuer resource with the ACME server URL and EAB credentials. The EAB key ID and HMAC key are provisioned by the PKIaaS provider and stored as a Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: pkiaas-eab-secret
  namespace: cert-manager
type: Opaque
stringData:
  hmac-key: <base64-encoded-EAB-hmac-key>
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: pkiaas-acme
spec:
  acme:
    server: https://acme.your-pkiaas-provider.example.com/acme/directory
    externalAccountBinding:
      keyID: <EAB-key-id>
      keySecretRef:
        name: pkiaas-eab-secret
        key: hmac-key
    solvers:
    - http01:
        ingress:
          class: nginx
    - dns01:
        webhook:
          groupName: acme.example.com
          solverName: route53

Use DNS-01 challenge solvers for internal services that do not have publicly accessible HTTP endpoints (internal APIs, database TLS, inter-service mTLS that cert-manager manages directly). Use HTTP-01 for internet-facing Ingress endpoints. The ClusterIssuer is cluster-scoped; if namespace-level isolation is required, use Issuer resources per namespace with namespace-specific EAB credentials.

Certificate Resources and Ingress Annotations

Once the ClusterIssuer is configured, certificates are requested through Certificate resources or Ingress annotations. For a Certificate resource:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-api-tls
  namespace: production
spec:
  secretName: internal-api-tls-secret
  issuerRef:
    name: pkiaas-acme
    kind: ClusterIssuer
  duration: 2160h   # 90 days; cert-manager renews at 2/3 of duration
  renewBefore: 720h # Renew 30 days before expiry
  dnsNames:
    - internal-api.production.svc.cluster.local
    - internal-api.example.internal

The duration field controls certificate validity. For the CA/Browser Forum 47-day public TLS schedule (effective March 15, 2029), set duration: 1128h (47 days) and renewBefore: 336h (14 days). cert-manager handles all renewals automatically within those parameters, triggering a new ACME order when the renewal window is reached.

EAB Credential Governance

EAB credentials authenticate Kubernetes clusters to the PKIaaS ACME endpoint. For production environments, do not store EAB credentials as plain Kubernetes Secrets. Use the Kubernetes Secrets Store CSI driver with an external secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) to inject EAB credentials as volumes at pod startup. This ensures EAB credentials are rotated through the secrets manager rather than embedded in cluster state and that access to EAB credentials is auditable through the secrets manager’s access log.

Pattern 2: SPIFFE/SPIRE with PKIaaS as Upstream CA

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for workload identity in distributed systems. The SPIFFE specification (maintained by the Cloud Native Computing Foundation) defines a URI-based identity format called the SPIFFE ID (spiffe://trust-domain/path) and a certificate format called the SVID (SPIFFE Verifiable Identity Document). SVIDs are X.509 certificates with the SPIFFE ID encoded in the Subject Alternative Name URI field.

SPIRE is the reference implementation of SPIFFE. In a Kubernetes environment, SPIRE consists of a SPIRE server (cluster control plane component) and SPIRE agents (DaemonSet pods running on each node). The SPIRE agent attests workloads based on their Kubernetes attributes (namespace, service account, pod labels, node identity) and issues SVIDs to attested workloads through the SPIFFE Workload API, typically via a Unix domain socket mounted into the pod.

Connecting SPIRE to PKIaaS as Upstream CA

By default, SPIRE uses a self-signed root CA internal to the SPIRE server. This means SVIDs are only verifiable within the SPIRE trust domain and are invisible to the organization’s enterprise PKI. Connecting SPIRE to PKIaaS as the upstream CA changes this: the SPIRE server requests an intermediate CA certificate from PKIaaS (signed by the PKIaaS issuing CA), uses it to sign SVIDs, and all SVIDs become verifiable against the organization’s PKIaaS root CA.

SPIRE supports several upstream CA plugins. The most direct integration is through the disk upstream CA plugin (which reads a PKIaaS-issued CA certificate and key from disk) or through the spire-controller-manager with cert-manager integration, where cert-manager requests the SPIRE intermediate CA certificate from PKIaaS and SPIRE reads it from the resulting Kubernetes Secret. A third option is using the Vault upstream CA plugin, which configures SPIRE to request CA certificates from a Vault PKI Secrets Engine backed by PKIaaS as the root:

# SPIRE server configuration excerpt for Vault upstream CA
UpstreamAuthority "vault" {
  vault_addr = "https://vault.internal.example.com:8200"
  pki_mount_path = "pki/spire-intermediate"
  ca_cert_path = "/run/spire/vault-ca.pem"
  # Vault auth via Kubernetes service account
  k8s_auth {
    k8s_auth_mount_path = "kubernetes"
    service_account_name = "spire-server"
  }
}

With the Vault upstream CA plugin, the SPIRE server requests an intermediate CA certificate from the Vault PKI engine when it needs to rotate its signing key. Vault signs the request using its own intermediate CA certificate (which was signed by PKIaaS). The result is a three-level chain: PKIaaS root CA, Vault intermediate CA, SPIRE intermediate CA, workload SVID. All four levels are verifiable against the PKIaaS root.

SVID Issuance and the Workload API

Once SPIRE is connected to PKIaaS, SVIDs are issued to workloads through the SPIFFE Workload API without any application-level certificate management code. The workflow is: the SPIRE agent attests the workload (verifying its pod identity against the SPIRE server’s registration entries); the SPIRE server issues a short-lived SVID (typically 1 hour validity) signed by the SPIRE intermediate CA; the SPIRE agent delivers the SVID and the trust bundle (the PKIaaS root CA certificate) to the workload through the Workload API socket. Applications that implement the SPIFFE Workload API (or use a library like go-spiffe or java-spiffe) receive and rotate their SVIDs automatically without any Kubernetes Secret interaction.

The 1-hour default SVID validity is intentional. At 1-hour validity, a compromised SVID is useless to an attacker after the expiry window. The SPIRE agent begins rotating SVIDs approximately 30 minutes before expiry, so the workload always has a valid credential. The PKIaaS audit log records each SVID issuance event (at the level of the SPIRE intermediate CA signing operation), providing an auditable record of workload identity certificate issuance without requiring per-SVID log entries from the PKIaaS ACME endpoint.

Pattern 3: Service Mesh mTLS with PKIaaS-Rooted Certificates

Service meshes enforce mutual TLS between all services in the mesh by injecting sidecar proxies that handle TLS termination and certificate management transparently. By default, both Istio and Linkerd use self-signed root CAs for the mesh trust domain, making mesh certificates invisible to enterprise PKI governance. PKIaaS integration changes this for both.

Istio: cert-manager istio-csr Integration

The cert-manager istio-csr agent (maintained by the cert-manager project) bridges Istio’s certificate signing request API and cert-manager. When deployed, istiod delegates all workload certificate signing requests to istio-csr, which fulfills them using a cert-manager Issuer backed by the PKIaaS ClusterIssuer.

The deployment sequence is: install cert-manager and configure the PKIaaS ClusterIssuer; create a Certificate resource for the istio-csr serving certificate and the istiod signing CA certificate, both issued by the PKIaaS ClusterIssuer; install istio-csr configured to use these certificates; install Istio with the external CA configuration pointing to istio-csr. After this, every Envoy sidecar in the mesh receives a workload certificate signed by the PKIaaS-rooted istiod CA, and the full certificate chain is verifiable against the PKIaaS root.

Mesh workload certificates issued through this path are typically short-lived (24 hours by default in Istio’s certificate rotation configuration). The total certificate issuance volume for a mesh with 200 services rotating every 24 hours is approximately 200 certificate operations per day from the PKIaaS endpoint, which is well within the rate capacity of any enterprise PKIaaS deployment.

Linkerd: cert-manager Trust Anchor Rotation

Linkerd uses a two-level certificate model for mTLS: a trust anchor (root CA) and an identity issuer (intermediate CA). cert-manager can manage both, but the most important integration point is the identity issuer certificate, which Linkerd uses to sign workload proxy certificates. If the identity issuer certificate expires, Linkerd’s mTLS stops working for the entire mesh.

The integration deploys cert-manager to issue and automatically rotate the Linkerd identity issuer certificate from the PKIaaS ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: linkerd-identity-issuer
  namespace: linkerd
spec:
  secretName: linkerd-identity-issuer
  issuerRef:
    name: pkiaas-acme
    kind: ClusterIssuer
  duration: 48h
  renewBefore: 24h
  isCA: true
  privateKey:
    algorithm: ECDSA
    size: 256
  usages:
    - cert sign
    - crl sign
  dnsNames:
    - identity.linkerd.cluster.local

cert-manager rotates this certificate 24 hours before expiry. Linkerd detects the rotation through its watch on the Secret and picks up the new identity issuer certificate without any service disruption. The resulting mesh trust chain is: PKIaaS root CA, Linkerd identity issuer (cert-manager-managed), Linkerd proxy certificate (per-workload, 24-hour validity).

Pattern 4: HashiCorp Vault PKI as a High-Volume Intermediate Layer

For cloud-native environments with very high certificate issuance volume (DevOps pipelines issuing certificates for every build, CI/CD code signing, infrastructure-as-code that provisions certificates for each ephemeral environment), direct issuance from the PKIaaS ACME endpoint at that volume may be operationally inefficient. HashiCorp Vault’s PKI Secrets Engine provides a high-throughput intermediate layer: a PKIaaS-rooted intermediate CA that issues certificates locally at Vault’s throughput rate (hundreds to thousands per second) without a network round-trip to the PKIaaS ACME endpoint for each certificate.

The Vault PKI Secrets Engine is configured with an intermediate CA certificate signed by the PKIaaS issuing CA. Vault stores the intermediate CA private key in its own HSM-sealed key store (or in an external HSM if Vault is configured with HSM seal). When an application or pipeline requests a certificate from the Vault PKI engine, Vault signs the CSR locally and returns the certificate immediately. The certificate is in the PKIaaS chain of trust and verifiable against the PKIaaS root.

Vault’s authentication methods provide fine-grained access control over which workloads can request which certificate types. The Kubernetes auth method allows Vault to authenticate Kubernetes service accounts using their OIDC tokens, enabling pod-level access control over PKI Secrets Engine roles. A DevOps pipeline running under a specific Kubernetes service account can be granted access to request code signing certificates; another service account can be restricted to requesting TLS certificates with only approved SANs in an allowlist. This is policy governance at the issuance level that neither cert-manager nor the PKIaaS ACME endpoint provides natively.

Short-Lived Certificates: Design Principles and Operational Requirements

Short-lived certificates are the correct default for cloud-native workloads, not a security optimization reserved for high-security environments. The operational model that makes them practical is the same one that makes cloud-native infrastructure practical: automation handles what humans previously did manually.

Recommended Validity Periods by Use Case

The appropriate certificate validity period varies by the use case and the renewal automation model in place.

Certificate use case	Recommended validity	Renewal trigger	Issuer pattern
Ingress TLS (internet-facing)	47 days (CA/B Forum by March 2029)	cert-manager auto at 30 days before expiry	PKIaaS ACME ClusterIssuer
Internal service TLS	90 days	cert-manager auto at 30 days before expiry	PKIaaS ACME ClusterIssuer
Service mesh sidecar	24 hours	Mesh control plane automatic	istio-csr or Linkerd cert-manager
SPIFFE SVID (workload identity)	1 hour	SPIRE agent automatic at 30 min before expiry	SPIRE with PKIaaS upstream CA
DevOps pipeline certs	1 to 4 hours	Issued at pipeline start, expired at end	Vault PKI Secrets Engine
Code signing certs (pipeline)	24 hours	Issued per pipeline run	Vault PKI Secrets Engine or PKIaaS REST API
Kubernetes admission webhooks	90 days	cert-manager auto	PKIaaS ACME ClusterIssuer

Revocation in a Short-Lived Certificate Model

One of the operational benefits of short-lived certificates in cloud-native environments is the reduced dependency on revocation infrastructure. A 1-hour SVID does not need OCSP or CRL checking: by the time revocation information propagates, the certificate has expired. A 24-hour sidecar certificate similarly has minimal revocation utility. For this reason, cloud-native workload identity certificates are typically issued without CRL distribution points or OCSP AIA extensions in the certificate, which simplifies certificate profiles and eliminates the availability dependency on revocation infrastructure for the mesh and workload identity layers.

Infrastructure certificates with longer validity periods (Ingress TLS at 47 days, internal service TLS at 90 days) should include CDP and OCSP AIA extensions and should be listed in the PKIaaS CA’s CRL and OCSP responder. If a Kubernetes cluster’s TLS certificate needs to be revoked immediately (due to a key compromise), the OCSP responder allows dependent systems to detect the revocation without waiting for expiry.

Replacing Static Secrets with PKIaaS-Issued Certificates

Many Kubernetes environments accumulate static TLS credentials: manually created Secrets containing certificates and keys that were generated once, stored in the cluster, and never rotated. These static credentials represent a persistent security exposure: the private key may have been handled insecurely when the Secret was created, the certificate may have an unknown expiry, and there is no renewal automation to replace it before it expires.

Replacing static credential Secrets with PKIaaS-issued certificates managed by cert-manager is a straightforward migration. The process for each Secret is: identify the Secret name and namespace; create a Certificate resource that points to the PKIaaS ClusterIssuer and uses the same secretName as the existing Secret; cert-manager requests a new certificate from PKIaaS and overwrites the Secret with the new certificate and key; restart the pods that reference the Secret to pick up the new credential. From that point forward, cert-manager manages renewal automatically and the Secret is never manually touched again.

For environments that want to eliminate Kubernetes Secrets entirely as the certificate storage mechanism, the Kubernetes Secrets Store CSI driver with external secrets manager integration (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) mounts certificates as volume files that are updated in place without creating Kubernetes Secrets. This pattern is more operationally complex but appropriate for environments where Kubernetes Secrets’ lack of encryption at rest (without a KMS provider) is a compliance concern.

Policy Governance for Cloud-Native PKI

Policy governance is the most commonly neglected dimension of cloud-native PKI. cert-manager and SPIFFE/SPIRE automate certificate issuance, but without additional controls, any developer with access to create Certificate resources can request certificates for any domain name in any namespace, using any key size and any validity period. In a multi-tenant Kubernetes environment with compliance obligations, this is a governance gap.

CA-Level Policy: PKIaaS Certificate Profiles

The first layer of policy enforcement is at the PKIaaS CA. Certificate profiles on the PKIaaS issuing CA define what certificates can be issued: which SANs are permitted (domain allowlists), which key algorithms and sizes are accepted, what EKU values the certificate may contain, and what validity periods are within policy. A certificate request that violates these constraints is rejected by the PKIaaS ACME endpoint before a certificate is issued, regardless of what cert-manager or the requesting application sent.

For a Kubernetes environment, configure at least three PKIaaS certificate profiles: one for internet-facing Ingress TLS (allowlisted to organization-owned domains, Server Authentication EKU only, maximum 47-day validity after March 2029); one for internal cluster services (allowlisted to cluster-internal DNS patterns such as *.svc.cluster.local and *.example.internal, Client and Server Authentication EKU, maximum 90-day validity); and one for service mesh and workload identity intermediates (CA:TRUE constraint, short validity, used by istio-csr and Linkerd cert-manager integrations).

Cluster-Level Policy: cert-manager Certificate Policy

cert-manager’s CertificateRequestPolicy (provided by the cert-manager policy approver) allows cluster administrators to define which Certificate resources are automatically approved and which require manual approval or are rejected. Policies can restrict which Issuers a namespace may use, which SANs are allowed in certificates for a given namespace, and which key parameters are acceptable. This provides a cluster-level enforcement layer that complements the CA-level profile enforcement in PKIaaS.

Kubernetes RBAC is the baseline enforcement mechanism: restrict the ability to create CertificateRequest resources (which trigger cert-manager issuance) to specific service accounts and user groups rather than granting it to all authenticated users. In a multi-tenant cluster, namespace-scoped Issuers (rather than cluster-scoped ClusterIssuers) allow per-namespace CA configuration, with each namespace’s Issuer backed by a PKIaaS EAB credential that is scoped to that namespace’s allowed certificate profiles.

CLM-Level Policy: Continuous Certificate Inventory and Compliance

CA-level and cluster-level policies control what gets issued at issuance time. CLM-level policy provides continuous monitoring of what is currently deployed and flags certificates that violate current policy, whether they were issued before current policies were established or through a path that bypassed the expected controls.

A CLM layer connected to the Kubernetes cluster (via cert-manager Secret discovery, Kubernetes API server certificate store scanning, or the Kubernetes Secrets Store CSI driver’s audit API) provides: a complete inventory of all certificates deployed in the cluster, regardless of which CA issued them; expiry monitoring with configurable advance notification; detection of certificates issued outside the approved PKIaaS CA (self-signed certificates, certificates from unauthorized CAs); key size and algorithm compliance checking (flagging RSA-1024 or SHA-1 certificates); and validity period compliance checking (flagging certificates exceeding the PKIaaS profile’s maximum validity).

Encryption Consulting’s CertSecure Manager provides this CA-agnostic CLM layer for Kubernetes environments, with connectors for cert-manager Secret inventories, the Vault PKI Secrets Engine, and the PKIaaS provider API, giving platform security teams a unified view across all four integration patterns described in this post.

Post-Quantum Readiness for Cloud-Native Workloads

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030. For Kubernetes and cloud-native environments, the PQC migration has specific implications that differ from traditional infrastructure.

The cert-manager, SPIRE, Istio, and Linkerd components that handle certificate issuance in Kubernetes environments each need to support PQC algorithm certificate types before workload certificates can migrate to ML-DSA. cert-manager’s certificate handling is algorithm-agnostic at the Kubernetes Secret level (it stores whatever the ACME server returns), so PKIaaS issuing ML-DSA certificates through the ACME endpoint will work as soon as the PKIaaS provider supports ML-DSA issuance and as long as cert-manager does not validate the key algorithm against a hardcoded list. Envoy (Istio’s sidecar proxy) and Linkerd’s proxy must support TLS handshakes using ML-DSA certificates, which depends on the TLS library (BoringSSL, OpenSSL) versions built into those proxies.

Hybrid certificates, which combine classical (ECDSA or RSA) and ML-DSA algorithms in a single certificate, are the recommended migration bridge for cloud-native environments. They allow systems that do not yet support PQC to verify the classical component while systems that support PQC use the ML-DSA component. PKIaaS providers that support hybrid certificate issuance through the ACME endpoint allow cloud-native environments to begin the migration before every component in the cluster has been updated to support PQC natively. Encryption Consulting’s PQC Readiness service provides assessments of the per-component PQC readiness of Kubernetes environments and produces migration roadmaps aligned to the NIST IR 8547 timeline.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the root CA and issuing CA infrastructure for the patterns described in this post, with ACME+EAB support for cert-manager integration, REST API for Vault PKI Secrets Engine intermediate CA signing, and certificate profile configuration for cluster-level policy enforcement. Contact us at Encryption Consulting to discuss your Kubernetes PKI requirements.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM governance layer for Kubernetes environments, with cert-manager Secret discovery, Vault PKI API connector, PKIaaS provider API connector, and continuous compliance monitoring across all certificate consumers in the cluster.
• PKI Services: For platform teams designing the PKIaaS integration architecture for their Kubernetes environment from scratch, Encryption Consulting’s PKI Services provide advisory and implementation support through ClusterIssuer configuration, SPIRE upstream CA integration, service mesh CA plugin deployment, and CLM governance design.
• PQC Advisory Services: For Kubernetes environments beginning PQC migration planning, Encryption Consulting’s PQC Advisory Services assess the per-component PQC readiness of the cert-manager, SPIRE, Istio, and Linkerd deployments and produce a coordinated migration roadmap aligned to the NIST IR 8547 timeline and the organization’s specific compliance requirements.
• HSM as a Service: For organizations that want dedicated FIPS 140-3 Level 3 HSM capacity for the PKIaaS root CA and Vault PKI intermediate CA without managing the hardware, Encryption Consulting’s HSM as a Service provides dedicated HSM capacity with full customer control over partition configuration, credentials, and audit log access.

Conclusion

PKIaaS for Kubernetes is not a single integration. It is a layered architecture where PKIaaS provides the root of trust and governance framework, and four distinct tooling paths (cert-manager for infrastructure certificates, SPIFFE/SPIRE for workload identity, service mesh CA integration for sidecar mTLS, and Vault PKI for high-volume short-lived issuance) each serve specific certificate consumers within the cluster. The CLM layer above all four provides the unified governance that makes the architecture auditable and compliant.

The patterns described in this post are all production-tested and documented in their respective project documentation. The integration points are well-defined: PKIaaS ACME+EAB for cert-manager, PKIaaS intermediate CA for Vault PKI, PKIaaS upstream CA plugin for SPIRE, and cert-manager PKIaaS ClusterIssuer for service mesh CA integration. The operational work is in configuration and governance, not in building custom integrations.

The post-quantum timeline is the forcing function. Kubernetes environments that are operating short-lived certificates through cert-manager and SPIRE today are well-positioned for PQC migration because their certificate infrastructure is already automated and their certificates are already short-lived. Migrating from ECDSA to ML-DSA in a cert-manager deployment is a PKIaaS profile configuration change and a cert-manager ClusterIssuer update, not a manual re-keying program across thousands of certificates.

If your platform team is designing a PKIaaS integration for Kubernetes or needs help validating the architecture against compliance requirements, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when cert-manager, SPIRE, Istio, or Linkerd release changes that affect their PKI integration models, or when NIST updates PQC migration guidance relevant to cloud-native workloads.

Frequently Asked Questions

How does cert-manager integrate with PKIaaS?

cert-manager integrates with PKIaaS through an ACME ClusterIssuer configured with the PKIaaS ACME endpoint URL and External Account Binding (EAB) credentials. Once configured, cert-manager automatically requests, stores, and renews certificates from PKIaaS in response to Certificate resource definitions or Ingress annotations. The renewal is fully automated and handles the CA/Browser Forum 47-day certificate validity schedule transparently.

What is SPIFFE and how does it relate to PKIaaS?

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for workload identity. SPIRE is its reference implementation. In a PKIaaS context, the SPIRE server can be configured to use the PKIaaS CA as its upstream certificate authority for signing SVIDs (SPIFFE Verifiable Identity Documents), replacing the default self-signed SPIRE CA root. This gives workload identity certificates a chain of trust rooted in the PKIaaS hierarchy, making them auditable and policy-governed alongside other enterprise certificates.

Why are short-lived certificates preferred for cloud-native workloads?

Short-lived certificates (24 hours to 1 hour for workload identity) reduce the window of exposure if a private key is compromised. For ephemeral containers, they also eliminate the need for revocation checking: the certificate expires before revocation infrastructure can be meaningfully called upon. PKIaaS and cert-manager/SPIRE provide the automated issuance and renewal that makes short-lived certificates operationally practical.

Can PKIaaS replace Kubernetes Secrets for certificate storage?

PKIaaS replaces long-lived static TLS credentials in Kubernetes Secrets with automatically provisioned and rotated certificates issued by a governed CA. The Kubernetes Secret storage mechanism itself is not replaced; cert-manager stores certificates as Secrets by default. For environments that want to eliminate Kubernetes Secrets entirely, the Kubernetes Secrets Store CSI driver with an external secrets manager (Vault, AWS Secrets Manager, Azure Key Vault) mounts certificates as volumes without creating Kubernetes Secrets.

What is the difference between cert-manager and SPIFFE/SPIRE for Kubernetes workload identity?

cert-manager manages certificates for Kubernetes resources at the resource level; certificates are stored in Kubernetes Secrets. SPIFFE/SPIRE manages workload identity for individual processes and containers, issuing SVIDs in-memory through the SPIFFE Workload API without Kubernetes Secret storage. Both can coexist: cert-manager handles infrastructure certificates while SPIFFE/SPIRE handles service-to-service workload identity.

How does PKIaaS support service mesh mTLS in Istio and Linkerd?

For Istio, the cert-manager istio-csr agent intercepts workload certificate signing requests from istiod and fulfills them using a PKIaaS-backed cert-manager ClusterIssuer, replacing the default self-signed mesh root with a PKIaaS-rooted hierarchy. For Linkerd, cert-manager issues and rotates the Linkerd identity issuer certificate from the PKIaaS CA, which Linkerd uses to sign sidecar proxy workload certificates. Both integrations make mesh certificates auditable under the organization’s PKIaaS governance framework.