openshift/certman-operator

Description: Operator to Manage Let's Encrypt certificates for OpenShift Clusters

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 3 hours ago
Added to GitGenius on June 23rd, 2026
Created on March 13th, 2019
Open Issues & Pull Requests: 7 (+0)
Number of forks: 86
Total Stargazers: 57 (+0)
Total Subscribers: 34 (+0)

Issue Activity (beta)

Open issues: 1
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 353 days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • lifecycle/rotten (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Repository Insights (GitGenius)

Median issue/PR response: 19.7 hours
Mean response time: 19.7 hours
90th percentile: 19.7 hours
Tracked items: 1

Most active contributors

Detailed Description

The Certman Operator is a Kubernetes operator written in Go that automates the provisioning, renewal, and revocation of TLS certificates from Let's Encrypt for OpenShift Dedicated clusters. It serves as a centralized certificate management solution specifically designed for environments where large numbers of OpenShift clusters need to be managed from a single control point. The operator integrates deeply with Hive, an API-driven OpenShift operator that handles cluster provisioning and management, relying on Hive's ClusterDeployment custom resource definition to track cluster lifecycle events.

The operator's core workflow begins when a new OpenShift Dedicated cluster is requested through cloud.redhat.com. Once Hive marks the cluster as installed by setting the Installed field to true on the ClusterDeployment resource, the Certman Operator creates a CertificateRequest resource for that cluster. The operator then initiates certificate requests from Let's Encrypt, proving domain ownership through DNS-01 challenges by publishing ACME challenge records to the cluster's DNS zone with a one-minute TTL. The operator verifies challenge record propagation using Cloudflare's DNS over HTTPS service, retrying up to five times before failing. After Let's Encrypt validates the challenge and issues certificates, the operator stores them in secrets on the management cluster. Hive monitors these secrets and synchronizes them to the OpenShift Dedicated cluster using SyncSets, allowing OpenShift to apply the new certificates automatically.

Certificate lifecycle management is handled through a reconciliation loop that runs every ten minutes by default. During reconciliation, the operator checks certificate validity and automatically reissues certificates when they approach 45 days before expiry. This proactive reissuance prevents expiry notifications from Let's Encrypt and ensures continuous certificate availability. When clusters are decommissioned, the operator revokes all valid certificates before deleting the associated secrets, allowing Hive to proceed with removing other cluster resources.

The operator has several important limitations. It requires Hive as a dependency and is therefore not suitable as a standalone Let's Encrypt certificate management solution for general use cases. Currently, it only supports DNS challenges through AWS Route53 and does not support HTTP challenges. The operator cannot create Let's Encrypt accounts and requires pre-existing accounts with keys to be provided. Additionally, the operator does not configure TLS certificates within OpenShift clusters; this responsibility belongs entirely to Hive through its SyncSet mechanism.

The implementation relies on two custom resource definitions: CertificateRequest, which specifies the details needed to request certificates from Let's Encrypt, and ClusterDeployment from Hive, which defines the target OpenShift managed cluster. The operator performs label and annotation checks during reconciliation, exiting early if certain conditions are not met, such as the presence of managed cluster or fake cluster labels. Finalizer logic ensures proper cleanup during cluster deletion.

Configuration is managed through a ConfigMap containing the default notification email address for Let's Encrypt expiry notifications, and two secrets are required for operation: the lets-encrypt-account secret storing the Let's Encrypt account URL and keys. The operator requires Go 1.19, Operator-SDK 1.21.0, and Hive v1 as dependencies. According to GitGenius activity tracking, the repository shows a median issue and pull request response latency of 19.7 hours, with sebrandon1 being the most active contributor tracked across five events. The repository shares contributors with openshift/cloud-ingress-operator, openshift/hive, and openshift/image-registry.

certman-operator
by
openshiftopenshift/certman-operator

Repository Details

Fetching additional details & charts...