Skip to main content
certforge-issuer is the cert-manager external issuer controller that bridges Kubernetes CertificateRequest objects to the CertForge API. It runs as a Deployment in your cluster and watches for CertificateRequest resources directed at CertForgeIssuer or CertForgeClusterIssuer objects. For installation and quick-start usage, see the cert-manager Integration guide. cert-manager + certforge-issuer architecture — Helm install, CRDs, namespace scoping, and certificate flow

Version compatibility

Always use the latest patch release. Run helm search repo certforge-issuer --versions to list available releases.

Helm chart values

Install or upgrade with helm upgrade --install:

Full values reference


CRD reference

CertForgeIssuer

Namespaced resource. Issues certificates only for CertificateRequest objects in the same namespace. Exactly one of authSecretRef or workloadIdentity must be set.
Status conditions:

CertForgeClusterIssuer

Cluster-scoped resource. Issues certificates for CertificateRequest objects in any namespace. When using Secret-based auth, the Secret must be in the certforge-system namespace (or secretNamespace if overridden).

Authentication

Secret-based (default)

The controller reads a long-lived API token from a Kubernetes Secret. Create the token under Settings → API Keys in the CertForge dashboard (needs read and enroll scopes).
For CertForgeIssuer (namespaced), create the Secret in the issuer’s namespace:
Workload Identity lets the controller authenticate using a short-lived projected ServiceAccount token instead of a long-lived API key. The kubelet writes and rotates the token automatically — no Kubernetes Secret is required. How it works:
  1. The Helm chart adds a projected serviceAccountToken volume to the controller pod.
  2. The kubelet writes a signed OIDC JWT to /var/run/secrets/certforge/token, bound to the configured audience.
  3. The controller re-reads this file on every API call — token rotation is fully transparent.
  4. CertForge validates the JWT against the cluster’s OIDC JWKS endpoint and grants the permissions configured in the matching Workload Identity Provider.
Step 1 — Find your cluster’s OIDC issuer URL:
Step 2 — Configure a Workload Identity Provider in CertForge: Go to Settings → Workload Identity → Add Provider:
Use an exact subject for production. The system:serviceaccount:certforge-system:certforge-issuer format identifies the precise ServiceAccount — no other workload can impersonate it. Trailing * wildcards are supported (e.g. system:serviceaccount:certforge-system:*) but should only be used in dev/staging environments.
Step 3 — Install or upgrade with workload identity enabled:
Step 4 — Update your issuer spec (omit authSecretRef):
Step 5 — Verify:
Migrating from Secret-based auth:
  1. Add the Workload Identity Provider in CertForge (Step 2 above).
  2. Upgrade the Helm chart with workloadIdentity.enabled=true and tokenSecret.create=false.
  3. Update the issuer spec to use workloadIdentity instead of authSecretRef.
  4. Once Ready=True is confirmed, delete the old Secret.

RBAC

The controller’s service account is granted the following permissions by the Helm chart: No cluster-wide Secret read access is granted.

Security hardening

NetworkPolicy

Restrict the controller pod to only the traffic it actually needs. Enable with networkPolicy.enabled=true in your values. Requires a CNI with NetworkPolicy support (Calico, Cilium, etc.). When enabled, the policy allows:

Prometheus metrics

Enable a ServiceMonitor for Prometheus Operator integration:
The controller exposes standard controller-runtime metrics on :8080/metrics.

Controller logs

The controller writes structured JSON logs:
Common log entries:

Upgrading

The controller performs a rolling update. In-flight certificate requests are not lost — the controller picks up any pending request IDs from CertificateRequest annotations on restart.

v0.1.x → v0.2.x

authSecretRef is now an optional pointer field (previously required). Existing authSecretRef-based issuers continue to work without changes. The new workloadIdentity field is the alternative.

High availability

Only one replica processes requests at a time; the others stand by. All replicas must reach the CertForge API. The leader election lease lives in certforge-system.

Uninstall

Uninstalling does not delete CertificateRequest objects or Kubernetes Secrets containing issued certificates — those remain intact.