Description
I have identified an issue in the ETCD operator during the reconciliation process of a cluster when using cert-manager as the TLS certificate provider. When cert-manager is configured to automatically manage TLS certificate generation, the reconciliation flow of the ETCD operator attempts to patch the Kubernetes Secret resources generated from Certificate resources. This patch operation is intended to add an owner reference so that the Secrets are marked as managed by the ETCD controller.
However, when cert-manager is installed with the Helm chart option enableCertificateOwnerRef=true, cert-manager already sets its own owner reference on the generated Secretresources. This leads to a conflict when the ETCD operator tries to modify the same field, causing the reconciliation process to fail.
Environment
Kubernetes version: v1.35.1
ETCD Operator version: v0.2.0
cert-manager version: v1.20.0
Steps to Reproduce
- Install cert-manager using Helm with
enableCertificateOwnerRef: true
- Deploy the ETCD operator using the YAML file from the releases page.
- Create an ETCD cluster configured to use cert-manager for TLS certificates.
- Observe the reconciliation process.
Expected Behavior
The ETCD operator should successfully reconcile the cluster even when cert-manager manages the Secrets, without conflicting over owner references.
Actual Behavior
The reconciliation fails when attempting to patch Secrets generated by cert-manager due to conflicting owner references. Error example:
2026-04-08T10:06:14Z ERROR Reconciler error {"controller": "etcdcluster", "controllerGroup": "operator.etcd.io", "controllerKind": "EtcdCluster", "EtcdCluster": {"name":"ptf0000000","namespace"
:"sare0000"}, "namespace": "sare0000", "name": "ptf0000000", "reconcileID": "ed373930-eda5-436a-a2a4-a0ec622a7e50", "error": "patching certificate secret: ptf0000000-server-tls with ownerReference faile
d: Object sare0000/ptf0000000-server-tls is already owned by another Certificate controller ptf0000000-server-tls"}
Proposed solutions
Conditional ownership handling
The ETCD operator should detect if a Secret is already managed by cert-manager and avoid overriding or adding conflicting owner references.
Configurable behavior via spec parameter
Provide a configuration flag in the ETCD resource to disable Secret ownership patching when external certificate managers (like cert-manager) are used.
Description
I have identified an issue in the ETCD operator during the reconciliation process of a cluster when using cert-manager as the TLS certificate provider. When cert-manager is configured to automatically manage TLS certificate generation, the reconciliation flow of the ETCD operator attempts to patch the Kubernetes
Secretresources generated fromCertificateresources. This patch operation is intended to add an owner reference so that the Secrets are marked as managed by the ETCD controller.However, when cert-manager is installed with the Helm chart option
enableCertificateOwnerRef=true, cert-manager already sets its own owner reference on the generatedSecretresources. This leads to a conflict when the ETCD operator tries to modify the same field, causing the reconciliation process to fail.Environment
Kubernetes version: v1.35.1
ETCD Operator version: v0.2.0
cert-manager version: v1.20.0
Steps to Reproduce
enableCertificateOwnerRef: trueExpected Behavior
The ETCD operator should successfully reconcile the cluster even when cert-manager manages the Secrets, without conflicting over owner references.
Actual Behavior
The reconciliation fails when attempting to patch Secrets generated by cert-manager due to conflicting owner references. Error example:
Proposed solutions
Conditional ownership handling
The ETCD operator should detect if a Secret is already managed by cert-manager and avoid overriding or adding conflicting owner references.
Configurable behavior via spec parameter
Provide a configuration flag in the ETCD resource to disable
Secretownership patching when external certificate managers (like cert-manager) are used.