Why Kubernetes certificate management changes when every cluster needs its own trust chain
Several clusters, ingress controllers and service-to-service TLS connections multiply the number of certificates an operations team must track, and most of them expire without anyone being paged. cert-manager is the usual controller for this job, and the decision that shapes the design is which issuer signs internal certificates: ACME, a CA key pair, OpenBao PKI or step-ca. Public ACME can issue for names that resolve on the public internet, so it covers the ingress hostnames customers reach. It does not fit internal service names, cluster-local DNS suffixes or workloads that must authenticate to each other, because those certificates need to chain to a CA your organization controls and trusts.
Regulated buyers should treat the issuer as a control, not a convenience. The HIPAA Security Rule at 45 CFR 164.312 asks for unique user identification, audit controls and transmission security, and the FTC Safeguards Rule at 16 CFR 314.4 asks for encryption in transit and logging of authorized activity. A private CA that issues certificates for pods gives you a place to enforce those expectations, but only if the CA's signing keys, issuance policy and audit trail are documented. The licenses also matter for procurement: cert-manager and step-ca are both published under Apache-2.0, which means your legal team can review a standard permissive license rather than a bespoke commercial agreement before the platform goes into production.
Before choosing an issuer, confirm three things with your platform team: which clusters must trust the same root, where the CA signing keys will live, and who approves changes to issuers and certificate profiles. Those answers determine whether OpenBao or step-ca is the better signing back end, and they set the scope of your trust distribution work. An implementation partner should be able to show how each cluster's issuer chains to the shared root and how a compromised issuer would be replaced without reissuing every workload at once.
Which requirements shape the Kubernetes certificate design
This table maps two US requirements to concrete decisions in a cert-manager and private CA design, so you can see which choices an assessor will ask you to justify. Read each row as a question to answer in your own design document, not as a finished compliance claim. DeployOpen prepares the systems and evidence, but your own assessor decides whether the evidence is sufficient.
| Requirement | Design decision for Kubernetes certificates | Evidence to prepare |
|---|---|---|
| Unique user identification (45 CFR 164.312, access control) | Give each workload its own identity and certificate, never a shared wildcard certificate copied across namespaces | Issuer and certificate inventory mapping each Secret to a named service and owner |
| Person or entity authentication (45 CFR 164.312) | Authorize certificate requests through Kubernetes service account identity or an ACME or CA issuer policy, not open issuance | Issuer configuration, RBAC rules for Certificate and CertificateRequest objects |
| Audit controls (45 CFR 164.312) | Record issuance, renewal and failure events from cert-manager and the CA, and forward them to your log platform | Retained logs of issuance and renewal events, with a review procedure and owner |
| Transmission security (45 CFR 164.312) | Enforce TLS on ingress and on internal hops that carry protected data, including service-to-service traffic | Ingress and service configuration showing TLS settings and certificate sources |
| Encryption in transit (16 CFR 314.4) | Issue certificates for every endpoint that carries customer information, and reject plaintext listeners on those paths | Scan results and configuration review of listeners, with exceptions documented |
| Encryption at rest (16 CFR 314.4) | Store private keys in Kubernetes Secrets only with encryption at rest enabled, or in an external store such as OpenBao | Cluster encryption configuration and secret storage design |
| Logging of authorized user activity (16 CFR 314.4) | Log administrative changes to issuers, CA keys and cert-manager configuration | Audit records of issuer changes and who approved them |
| CA key protection (both regulations' safeguards) | Keep the CA signing key in an HSM, cloud KMS or a dedicated secrets engine, with access limited to the issuing component | Key custody record, access list and documented key ownership |
Which issuers and tools fit Kubernetes, and why
In Kubernetes, the controller that requests and renews certificates is separate from the authority that signs them and the store that holds the keys. The cards below cover the three components a private design usually combines, and the decision each one forces.
cert-manager as the renewal controller
cert-manager is a Kubernetes controller under the Apache-2.0 license. It obtains certificates for workloads and ingress, stores them in Kubernetes Secrets, and renews them before they expire. Its issuer types include ACME, a CA key pair, HashiCorp Vault, CyberArk and self-signed certificates. Decide which issuer each namespace or cluster may use, and confirm that the issuer's CA key is protected at the level your policy requires, since cert-manager itself does not hold that protection.
step-ca when you need a small private CA
step-ca is Smallstep's Apache-2.0 online certificate authority for X.509 certificates, including TLS and mutual TLS, and short-lived SSH certificates. It supports ACME for automated renewal and OIDC, JWK and cloud instance identity provisioners. CA keys can sit in an HSM, cloud KMS or a YubiKey. Choose it when you want one authority that cert-manager's ACME issuer can call directly, and check that your HSM or KMS integration matches your key custody rules.
OpenBao when secrets and PKI share one platform
OpenBao is an MPL-2.0 secrets manager and Vault fork hosted under the OpenSSF at the Linux Foundation. It offers a Kubernetes auth method, dynamic secrets and a PKI engine for issuing certificates. Its storage options are integrated Raft or PostgreSQL for high availability. Choose it when your organization already needs a central secrets store and wants certificates managed beside it. Confirm which storage backend your operations team can run safely, and test Kubernetes auth roles before production.
Vault licensing before you choose it
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1, with IBM named as licensor. That license is not OSI-approved open source. If your policy requires OSI-approved licenses, Vault is excluded, and the same applies to any fork you adopt without reviewing its license. Ask your legal and procurement teams to confirm the license terms against your policy before you design around Vault's API or auth methods.
Matching the issuer to the cluster's trust
Pods trust a certificate only if its root is present in their trust store. A cluster that uses cert-manager with a private CA must distribute the CA bundle to workloads, typically through a ConfigMap or a trust-manager style sync. Ask who owns that bundle, how a root rotation reaches every namespace, and which workloads pin certificates and will not pick up a new root without a restart.
Expiry monitoring across clusters
Each cluster's cert-manager reports its own Certificate resources, but a certificate that fails to renew can sit unnoticed in a namespace nobody watches. Decide where the inventory lives, which alerts fire before expiry, and who is paged. Confirm that the monitoring covers ingress certificates managed outside cert-manager and any certificates loaded directly from Secrets by applications.
How trust reaches pods without copying CA bundles by hand
The trust bundle a workload uses to verify a certificate is a separate delivery problem from the certificate itself. cert-manager puts each leaf certificate and its issuing chain into a Kubernetes Secret, usually with a ca.crt key, but that does not make pods trust anything by default. Each pod needs the root or intermediate chain in its trust store or in the path its client library reads. The common options are mounting a ConfigMap or Secret that holds the CA chain at a known path and pointing the runtime at it, baking the root into base images and updating the system trust store at build time, or using a trust-manager style controller that syncs bundles into namespaces. Confirm with your platform team which mechanism each workload family uses, and confirm how each language runtime, sidecar and ingress controller reads its CA file, since some ignore the system store and some cache it at startup.
A stale bundle is the failure mode to plan for. When an intermediate CA is rotated, new leaf certificates chain to the new intermediate while pods that were built with the old bundle keep rejecting them, or the reverse during a staged cutover. Image-baked roots are the most fragile because a rebuild and redeploy is needed for every change, and mounted bundles are only refreshed if the pod reads the file again, which many processes do not do without a restart. Ask the vendor and your own cluster whether a changed ConfigMap or Secret reaches running pods, how long propagation takes in your kubelet and sync settings, and whether a reload signal or rolling restart is required for each service.
Test every chain change in a non-production cluster before it reaches production. A useful test publishes the new bundle alongside the old one, issues a certificate from the new intermediate, and checks handshakes from representative workloads, including one per language runtime, plus the ingress controller and any service mesh. Keep the old chain available until the last consumer confirms it validates the new one, and record the change in your certificate inventory. This test does not replace a rollback plan, so agree on who can revert the bundle and how quickly.
Rollout phases and the output of each
The sequence moves from an inventory of every certificate-bearing endpoint to a documented, monitored and handed-over certificate service, with each phase closing on a named artifact the client keeps. Nothing is migrated until the CA design and trust model are approved in writing.
Inventory ingress and internal endpoints
DeployOpen works with the client's platform and network teams to list every ingress controller, Service that terminates TLS, internal endpoint and existing certificate across all clusters, including certificates issued by external CAs or manually renewed. Each entry records the owner, hostname, issuer, expiry, the workloads that trust it and whether it can be automated. The step is done when the inventory has been reviewed with the owners and every gap is assigned. The output is a certificate inventory workbook with an owner and renewal method for each endpoint.
Design the CA hierarchy and issuers
The team decides how many CAs are needed, which tier signs issuing certificates, where CA keys are stored and who can request certificates. Options include step-ca, OpenBao PKI and cert-manager's CA or Vault issuers, and the design records which provisioners or auth roles each cluster may use. The step closes when the security and platform owners sign off on key custody and issuer scope. The output is a PKI design document with a hierarchy diagram, a key custody statement and an issuer matrix per cluster and namespace.
Pilot cert-manager on one cluster
DeployOpen installs cert-manager in a non-production cluster, configures the chosen ClusterIssuer or Issuer, and moves one internal service onto it. The pilot checks that certificates are created as Kubernetes Secrets, that renewal happens before expiry and that the workload picks up the new certificate without manual steps. Failures are recorded and fixed before the pattern is copied. The output is a tested Helm values file, issuer manifests and a pilot report listing each test and its result.
Distribute trust to pods and clients
The team delivers the CA root and intermediate chain to clients, pods and base images that need to validate internal certificates, and tests trust in each runtime, including language runtimes that keep their own trust store. Trust bundles are distributed through a controlled mechanism, such as a ConfigMap sync or image build step, and the rotation path for the bundle is documented. The step is done when a test pod in each environment validates an internal certificate without disabling verification. The output is a trust distribution specification and a verified bundle per environment.
Migrate workloads in controlled waves
Services move from manually managed or externally issued certificates to cert-manager in waves grouped by owner and risk. Each wave updates the inventory, retires the old certificate and confirms that renewal runs without intervention. Ingress changes are rolled out with the application team's change process, and rollback steps are written before each wave. The step closes when the inventory shows every in-scope endpoint with an automated issuer or a named exception. The output is a migration log and a updated inventory with exceptions approved by the owner.
Monitor expiry across clusters
DeployOpen configures expiry monitoring that reads certificate resources from every cluster and from the CA inventory, then raises alerts to the owning team and the on-call channel before a certificate reaches its renewal threshold. Alert thresholds, routing and suppression rules are set with the client. The step is complete when a test certificate triggers each alert level and the alert reaches the intended recipient. The output is a monitoring configuration, a dashboard of certificate status by cluster and a list of alert rules with owners.
Hand over with runbooks
The client's operations team receives runbooks for CA unavailability, renewal failure, emergency reissuance, trust bundle rotation and CA key compromise, and runs at least one tabletop or live exercise of the renewal failure runbook with DeployOpen before acceptance. Support terms, if any, are set in a separate written agreement such as a retainer. The step is done when the client signs acceptance against the agreed scope. The output is a runbook set, an operations handover record and a recorded exercise outcome with follow-up actions.
Integration points and deployment pattern for regulated clusters
How should cert-manager authenticate to a private CA in Kubernetes?
Use the CA's own workload identity rather than a shared static credential. In OpenBao, the Kubernetes auth method lets pods and the cert-manager controller log in with their service account token, and the PKI secrets engine then signs certificates under a policy scoped to specific namespaces and domains. With step-ca, cert-manager reaches the CA through its ACME or external issuer path, and provisioners decide who may request what. Choose a provisioner type that matches the cluster: OIDC or JWK provisioners add an identity check beyond network reachability. Before committing, confirm which auth method your cluster distribution exposes, how service account token audiences are configured, and who owns the policy files. Those answers determine whether a compromised namespace can request certificates for names it does not own.
Where should CA keys and OpenBao or step-ca secrets live?
Keep the signing keys for issuing CAs in an HSM, a cloud KMS or a hardware key where the platform supports it, and keep the offline root out of the clusters entirely. step-ca can protect CA keys in HSMs, cloud KMS or YubiKeys, and OpenBao stores its data encrypted before it reaches storage. Its documented storage options are integrated storage (Raft), PostgreSQL, PebbleDB and in-memory, and only Raft and PostgreSQL are supported for high availability. Confirm your key custody rules with your compliance team, the storage backend your operations staff can run safely, and where unseal material and recovery keys are held. Ask the implementation partner to document the key ceremony and the restore test.
How does cert-manager work with an ingress controller?
cert-manager can watch ingress resources and create the TLS certificates they reference, storing each one in a Kubernetes Secret that the ingress controller loads. Annotate the ingress with the issuer you want, or create Certificate resources directly when the certificate should not depend on an ingress object. Check that the ingress controller reloads secrets when they change, because a renewed certificate that the proxy never picks up is a common outage pattern. Also confirm which issuer handles public names and which handles internal names, so internal hostnames never reach a public ACME endpoint. Test renewal on a non-production ingress before relying on it for regulated traffic.
Does a service mesh replace cert-manager for mTLS?
Usually no. A service mesh often runs its own short-lived workload certificates for mutual TLS between sidecars, while cert-manager handles certificates for ingress and for services that terminate TLS themselves. Running both is common, but they must not overlap in trust: decide which CA anchors the mesh, whether the mesh root is imported from your private CA, and who can rotate it. Confirm how the mesh rotates its root and intermediate, whether it can consume an external CA, and whether any workloads need certificates that the mesh does not manage. The sibling topic on service-to-service mTLS covers the workload identity side in more depth.
How do you monitor certificate expiry across several clusters?
Export certificate status from every cluster into one inventory and alert on expiry from that inventory, not from each cluster separately. cert-manager records readiness and expiry on its Certificate resources, and a central collector can read them alongside endpoint scans of live TLS listeners, which catches certificates installed outside cert-manager. Set alert thresholds with enough lead time for a human to act when automated renewal fails, and route alerts to a team that owns the issuer, not only the application. Ask the partner how the inventory is kept current when clusters are added or retired, and how the alerts are tested. Expired certificates are often the cause of outages, so this check belongs in the operations runbook, not in a dashboard nobody reads.
Where should the CA sit relative to regulated clusters?
Place the issuing CA in a management network that the clusters can reach on a narrow, audited path, and keep the root offline. The CA should not sit inside a workload cluster it signs certificates for, because a cluster compromise would then reach the signing service. Many designs run the issuing CA and OpenBao in a dedicated security enclave with firewall rules limiting access to the cert-manager controllers and the ACME or API endpoints. Confirm the availability target for issuance, what happens to pods when the CA is unreachable (cached certificates keep working until they expire), and how the CA is backed up and restored. Ask the partner for a network diagram and a list of every flow the CA requires.
What does the engagement cover, and what can your team run alone?
The engagement typically covers the design, installation and hardening of cert-manager and the chosen CA, issuer and policy configuration, trust distribution to pods, the expiry monitoring setup, backup and restore testing, and documentation for your operators. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own clusters and networks, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Teams with strong Kubernetes operations can run cert-manager day to day once the design and runbooks are handed over. Ongoing upgrades and support are available as retainers. Quotes follow from the written scope, so list your cluster count, distributions, and CA requirements when you ask for one.
Evidence assessors ask for and which component produces it
This table maps each evidence item an assessor is likely to request for a cert-manager and private CA setup to the component that produces it. Use it to plan where logs, exports and records come from before an assessment starts. DeployOpen prepares this evidence, but independent auditors decide what is sufficient for their scope.
| Evidence item | Producing component | What the reader should confirm |
|---|---|---|
| Issuer and CA configuration exports | cert-manager ClusterIssuer and Issuer resources, plus the step-ca or OpenBao PKI configuration | Exports are taken from the cluster and CA on a schedule, and the export shows who approved each issuer change. |
| Certificate resource inventory | cert-manager Certificate resources and their Kubernetes Secrets, collected across every cluster | Inventory covers all namespaces, ingress resources and internal services, including certificates created outside the GitOps repository. |
| Issuance and renewal logs | cert-manager controller logs and the CA audit log (step-ca or OpenBao audit devices) | Logs are retained for the period the auditor samples, and each entry can be matched to a Certificate resource and a requesting identity. |
| Expiry monitoring reports | cert-manager metrics exported to a monitoring stack, with alerts on certificates nearing expiry | Alert thresholds, alert routing and the record of how each near-expiry event was resolved are documented. |
| CA key custody records | step-ca key protection (HSM, cloud KMS or YubiKey) or OpenBao seal and key management records | Custody of root and issuing keys is recorded, including who holds unseal or recovery material and how that access is reviewed. |
| Trust distribution change records | GitOps commit history for trust bundles and ConfigMaps, plus the CA root distribution process | Each change to the trust bundle that pods rely on has an approved change record, a date and a rollback path. |
| Access reviews for issuer creation | Kubernetes RBAC bindings on Issuer and ClusterIssuer resources, reviewed against the identity provider | Reviews name who can create or modify issuers, cover service accounts and show the date and reviewer of each review. |
Questions to ask an implementation partner before scoping Kubernetes certificates
Start with how issuers are scoped. Ask the partner whether they will use one ClusterIssuer for the whole estate or separate Issuer resources per namespace, and who can create or edit them. A cluster-wide issuer backed by a CA key lets any namespace administrator who can reach it request certificates for any name, so ask how the partner will restrict issuance by namespace, by DNS name and by certificate profile. Then ask where the CA private key lives: in OpenBao PKI, in step-ca with a key held in an HSM, cloud KMS or YubiKey, or in a Kubernetes Secret. Ask which roles can sign, who holds the unseal or key material, and how that access is logged. Confirm the answers against the cert-manager issuer configuration documentation before you accept a design.
Next, ask how the chain will be rotated without outages, and how expiry will be watched across clusters. A good answer describes an overlap period in which both the old and new intermediate are trusted, the order in which trust bundles are pushed to pods and ingress controllers, and a rehearsal in a non-production cluster first. For monitoring, ask which tool reports certificate expiry for every cluster, which alert thresholds are proposed, and who receives them. Ask what the partner will do when the CA is unavailable: whether cached certificates keep working, how long renewals can be deferred, and what the runbook says. Finally, ask how cert-manager and CA versions will be upgraded, and whether the partner will test upgrades against your cluster versions. Ask for the evidence package in writing: issuer configuration exports, key custody records, rotation test results, alert rules, and audit log samples. Finally, require a fixed-scope statement of work with a numbered deliverable list and acceptance criteria. Confirm the timeline and any retainer for upgrades before signing.
What buyers ask before hiring help with Kubernetes certificates
What drives the cost of Kubernetes certificate automation?
The main drivers are the number of clusters, the number of issuers, how the CA key is protected, and how many legacy workloads need manual handling. Each cluster needs its own cert-manager installation, issuer configuration, monitoring and runbook, so cost grows with the estate rather than with the certificate count. A single CA key held in software is simpler than a key held in an HSM, cloud KMS or OpenBao, but the protected option adds design and integration work. Legacy workloads that cannot read a Kubernetes Secret or reload a certificate add custom work. Ask for a quote that lists each cluster, issuer, key storage option and workload type separately, so you can see which items drive the total.
How long does a Kubernetes certificate project take?
The duration depends on the written scope, and no fixed figure applies across environments. The schedule follows the number of clusters, whether a CA already exists or must be built, how many workloads need migration, and how many change windows the team can offer. Engagements are fixed-scope, so the timeline is agreed in writing before work begins, with deliverables and dates tied to that scope. Ask the partner to break the timeline into phases: discovery and inventory, issuer design, pilot cluster, rollout to remaining clusters, and handover. Confirm which phases depend on your change approvals or on work done by other teams.
What does the client team need to provide?
The work needs three things from your side: access to the clusters, a named owner for the CA, and agreed change windows. Cluster access means a service account or role that can install cert-manager, create issuers and read the resources that the work touches, approved through your normal access process. The CA owner makes decisions on lifetimes, certificate profiles, trust distribution and revocation, and signs off on the CA key design. Change windows matter because rolling out new issuers and replacing ingress certificates can interrupt traffic if done carelessly. Confirm also who owns the DNS records, ingress controllers and any internal trust bundles that applications depend on.
Can our team set up Kubernetes certificates without outside help?
A team with Kubernetes and PKI experience can usually manage a single cluster with a clear runbook. The work is bounded: install cert-manager, configure one issuer, issue certificates for ingress and a few internal services, and document renewal and expiry checks. Across many clusters, the difficulty rises because each cluster may use different issuers, different Kubernetes versions, different trust bundles and different owners. Drift between clusters is the usual failure mode, and it is hard to catch without a central inventory and expiry monitoring. Assess your team against the number of clusters, the availability of someone who can own the CA, and the time available for testing renewals before they matter.
Does DeployOpen issue certificates or audit reports?
No. DeployOpen plans, implements, configures and documents the certificate platform and the controls around it, and prepares evidence for compliance assessments. It does not issue certificates on your behalf as a certificate authority, and it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. In practice, the deliverables may include a configured cert-manager deployment, issuer and CA design documentation, renewal and expiry monitoring, and runbooks, which your auditors can review. Confirm the exact deliverables and evidence formats in the written scope before work starts.
How should we protect the CA key used by cert-manager?
Protect the CA key according to your own key management policy, and decide that before the first issuer goes live. cert-manager can use a CA key pair stored in a Kubernetes Secret, which is simple but ties the key's protection to cluster access controls. cert-manager can also use HashiCorp Vault or other external issuers, and OpenBao is a community fork of Vault that can serve as the CA backend in a self-hosted design, subject to confirmation of the PKI features your version provides. Options such as HSM or cloud KMS protection are usually provided through the CA layer, such as step-ca. Ask the partner which option fits your policy and what it costs to operate.
What happens to legacy workloads that cannot reload certificates?
Legacy workloads are a common source of outages during certificate rollouts, because some applications read certificates only at startup or cannot read a Kubernetes Secret at all. Start by inventorying every workload that terminates TLS, including those outside Kubernetes that talk to cluster services. For each one, decide whether it can reload a certificate, needs a restart hook, needs a sidecar or proxy, or must keep a longer-lived certificate on a documented exception list. Exceptions should have owners and expiry dates so they do not become permanent. Ask the partner how they plan to test these workloads before changing their certificates.
How do we monitor certificate expiry across several clusters?
Monitoring should cover every certificate in every cluster from one place, with alerts that reach the team that can act. cert-manager records certificate status and renewal state in Kubernetes resources, which can be exported to a monitoring stack, but each cluster reports only its own certificates. Plan for a central view that pulls expiry data from all clusters, alerts before renewal windows close, and flags certificates that were issued outside cert-manager. Confirm which monitoring tool your organization already runs, who receives alerts, and how the team will test that an alert fires before a real expiry.
How DeployOpen scopes and supports Kubernetes certificate work
DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own clusters, cloud accounts and networks, and certificate automation is no exception. For a cert-manager and private CA design, that means the work touches your ingress controllers, the issuers that sign for your internal services, the trust bundles your pods depend on, and the expiry monitoring that tells you something is about to break. Most engagements are fixed-scope, so the cluster inventory, the issuers in use, the CA backend (step-ca or OpenBao), the namespaces covered and the deliverables are agreed in writing before any work starts.
Ask for a scope document that names each piece explicitly: which clusters and namespaces are in, which ClusterIssuer and Issuer resources will be created or migrated, how the CA private key is protected, how trust distribution to workloads is handled, and what expiry alerting covers. Confirm who owns the CA signing keys and the cert-manager configuration after handover. DeployOpen prepares controls and evidence for compliance assessments, such as the certificate inventory and renewal records, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and your scope should say which evidence your auditor expects to see.
Ongoing support, upgrades of cert-manager and the CA backend, and periodic review of issuer configuration are available as retainers, which suit clusters that change often. DeployOpen does not publish a price list. A quote follows from the written scope, so the cost will reflect the number of clusters, the issuers and integrations involved, and the support level you choose. Use the cert-manager documentation to check your issuer types against your scope before requesting a quote.
