cert-manager is excellent at automating certificate issuance and renewal in Kubernetes. It is not a governance tool. It has no concept of who approved a cert, whether a domain is authorized, or what your auditors will need next quarter. CertForge fills that gap — as a first-class cert-manager external issuer.
CertForge implements the cert-manager external issuer API. Your Certificate CRDs stay exactly the same. The only change is issuerRef pointing to a CertForgeIssuer instead of a ClusterIssuer.
Install the certforge-issuer controller in your cluster
Create a CertForgeIssuer that maps to a Trust Profile
Your Certificate manifests stay the same — just change issuerRef
CertForge intercepts the request, enforces policy, routes for approval
The controller forwards each CertificateRequest to CertForge. If the request matches an auto-approve policy in the Trust Profile, it is issued immediately. If it requires human review, the request enters an approval queue — approvers get notified, act in the Platform UI, and cert-manager receives the signed cert once approved. Rejections propagate back as cert-manager conditions so Kubernetes events show the reason.
Trust Profiles define which domains are allowed, which CA to use, max validity, and whether human approval is required. No cert leaves without matching a profile.
Every CertificateRequest is logged: cluster, namespace, requestor identity, policy matched, approver, timestamp. Exportable to Splunk, Datadog, or Elastic.
Certs issued through CertForge appear in the unified cert inventory — alongside certs from other environments, with expiry alerts and renewal status.
Configure approvers by domain pattern. A request for *.prod.example.com can require security team sign-off while *.dev.* auto-approves.
When a human rejects a request, CertForge annotates the cert-manager Certificate resource to stop the retry loop. cert-manager won't keep re-submitting.
Cert activity in Kubernetes is included in PCI-DSS, SOC 2, and ISO 27001 attestation reports. Auditors see governance evidence across all cert sources in one report.
One CertForge organization can receive requests from multiple clusters. Each cluster has its own CertForgeIssuer resource mapping to the same (or different) Trust Profiles. The unified inventory shows which cluster each cert came from, and approval workflows can route based on cluster labels.
Alongside it. cert-manager keeps doing what it does best — managing certificate lifecycle in Kubernetes. CertForge adds the governance layer on top. Your Certificate CRDs, renewal logic, and Secret delivery remain cert-manager's job.
Auto-renewal works normally. When cert-manager submits a renewal CertificateRequest, CertForge processes it through the same policy engine. You can configure Trust Profiles to auto-approve renewals that match the original request (same domains, same CA), so renewal is still frictionless.
You configure the CA in the Trust Profile. Options include CertForge's built-in internal CA, your own private CA (via CA connector), or external ACME CAs (Let's Encrypt, ZeroSSL, DigiCert). Each Trust Profile can use a different CA, so dev and prod can issue from different roots.
Yes. The certforge-issuer implements the standard external issuer contract. CMCTL, kubectl cert-manager, and any tool that reads CertificateRequest status work normally.
Add governance to your cluster today
Install the issuer, connect a Trust Profile, and start reviewing cert requests in the Platform UI — no changes to your existing Certificate manifests.
certforge-issuer is open source — Apache 2.0 license.