{
  "schema_version": 2,
  "id": "operate/kubernetes/security/certificates/cert-manager",
  "title": "Integrate cert-manager with Redis for Kubernetes",
  "url": "https://redis.io/docs/latest/operate/kubernetes/8.2.0/security/certificates/cert-manager/",
  "summary": "Automate TLS certificate management for Redis for Kubernetes using cert-manager.",
  "aliases": ["/operate/kubernetes/security/cert-manager/"],
  "content": "\n[cert-manager](https://cert-manager.io/) is a Kubernetes add-on that automates the management and issuance of TLS certificates. The Redis operator integrates with cert-manager, so you can use automatically managed certificates for:\n\n- Redis Enterprise cluster (REC) components (API, CM, proxy, syncer, and others)\n- Database replication with TLS\n- LDAP client authentication\n- SSO/SAML certificates\n\nBenefits of using cert-manager include:\n\n- **Automatic certificate renewal**: cert-manager handles certificate rotation before expiration.\n- **Standardized management**: Use the same certificate management approach across your Kubernetes infrastructure.\n- **Multiple certificate authorities**: Support for Let's Encrypt, private CAs, Vault, and more.\n- **Automatic propagation**: For Active-Active databases, certificate changes automatically sync across all participating clusters.\n\n\u003e [!WARNING]\n\u003e The cert-manager integration uses Kubernetes secrets. It is not compatible with Vault-based secret management (when `clusterCredentialSecretType: vault`). See [HashiCorp Vault integration](https://redis.io/docs/latest/operate/kubernetes/security/vault) for details.\n\n## Prerequisites\n\n- Kubernetes cluster with Redis Software for Kubernetes 8.0.18 or later\n- cert-manager v1.19.0 or later installed\n\nIf cert-manager is not already installed, see the [cert-manager installation documentation](https://cert-manager.io/docs/installation/).\n\n## How it works\n\ncert-manager creates standard Kubernetes TLS secrets with the following fields:\n\n- `tls.crt`: The certificate in PEM format\n- `tls.key`: The private key in PEM format\n- `ca.crt`: The root CA certificate\n\nThe Redis Enterprise operator automatically recognizes these secrets and can use them interchangeably with manually created secrets.\n\n\u003e [!NOTE]\n\u003e If you currently use opaque secrets for your certificates, you can switch to cert-manager's TLS secrets without any additional configuration changes to your Redis resources.\n\n### Supported secret formats\n\nThe operator supports multiple field names for backward compatibility:\n\n| Purpose | Accepted field names |\n|---------|---------------------|\n| Certificate | `tls.crt`, `cert`, `certificate` |\n| Private key | `tls.key`, `key` |\n| CA certificate | `ca.crt` |\n\n\u003e [!NOTE]\n\u003e Support for the `tls.crt` and `tls.key` field names requires Redis Software for Kubernetes 8.0.18 or later. For secret requirements on earlier versions, see [Manage REC certificates](https://redis.io/docs/latest/operate/kubernetes/security/certificates/manage-rec-certificates).\n\n\u003e [!NOTE]\n\u003e The `ca.crt` field is automatically appended to the certificate chain when present. cert-manager typically populates this field when it has access to the root certificate.\n\n## Quick start\n\nAfter you install cert-manager and configure an [`Issuer` or `ClusterIssuer`](https://cert-manager.io/docs/concepts/issuer/), create a `Certificate` resource to generate TLS secrets, then reference the secret name in your Redis custom resources.\n\n### Create a certificate and configure your REC\n\nThe following example creates a certificate and references the generated secret in a `RedisEnterpriseCluster` resource:\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: Certificate\nmetadata:\n  name: redis-api-cert\n  namespace: redis-namespace\nspec:\n  secretName: redis-api-tls\n  duration: 2160h # 90 days\n  renewBefore: 360h # 15 days before expiration\n  issuerRef:\n    name: my-issuer\n    kind: ClusterIssuer\n---\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\n  namespace: redis-namespace\nspec:\n  nodes: 3\n  certificates:\n    apiCertificateSecretName: redis-api-tls\n```\n\nThe operator automatically reads the certificate from the `redis-api-tls` secret created by cert-manager. No additional configuration is needed, even if you are migrating from manually created opaque secrets.\n\n## Secure all cluster components\n\nRequest certificates for each component and reference them in the REC:\n\n```yaml\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\nspec:\n  nodes: 3\n  certificates:\n    apiCertificateSecretName: api-tls\n    cmCertificateSecretName: cm-tls\n    proxyCertificateSecretName: proxy-tls\n    syncerCertificateSecretName: syncer-tls\n    metricsExporterCertificateSecretName: metrics-tls\n```\n\nEach secret name corresponds to a `Certificate` resource managed by cert-manager. For details on these fields, see the [RedisEnterpriseCluster API reference](https://redis.io/docs/latest/operate/kubernetes/reference/api/redis_enterprise_cluster_api).\n\n## Database replication with TLS\n\nFor database replication with client certificates:\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: Certificate\nmetadata:\n  name: replication-client-cert\n  namespace: redis-namespace\nspec:\n  secretName: replication-client-tls\n  issuerRef:\n    name: my-ca-issuer\n    kind: ClusterIssuer\n  commonName: replication-client\n---\napiVersion: app.redislabs.com/v1alpha1\nkind: RedisEnterpriseDatabase\nmetadata:\n  name: target-db\nspec:\n  replicaSources:\n    - replicaSourceType: SECRET\n      replicaSourceName: source-uri-secret\n      clientKeySecret: replication-client-tls\n```\n\n## LDAP client authentication\n\nWhen using LDAP with client certificate authentication:\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: Certificate\nmetadata:\n  name: ldap-client-cert\n  namespace: redis-namespace\nspec:\n  secretName: ldap-client-tls\n  issuerRef:\n    name: ldap-ca-issuer\n    kind: ClusterIssuer\n  commonName: redis-ldap-client\n---\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\nspec:\n  nodes: 3\n  certificates:\n    ldapClientCertificateSecretName: ldap-client-tls\n  ldap:\n    protocol: LDAPS\n    servers:\n      - host: ldap.example.com\n        port: 636\n```\n\nFor more details on LDAP configuration, see [Enable LDAP authentication](https://redis.io/docs/latest/operate/kubernetes/security/authentication/ldap).\n\n## Active-Active databases with automatic certificate sync\n\nFor Active-Active databases, certificate updates to proxy or syncer certificates automatically trigger synchronization across all participating clusters:\n\n```yaml\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\nspec:\n  nodes: 3\n  certificates:\n    proxyCertificateSecretName: proxy-tls\n    syncerCertificateSecretName: syncer-tls\n```\n\nWhen cert-manager renews these certificates, the operator:\n\n1. Detects the secret change.\n1. Updates the certificate generation counter.\n1. Triggers a CRDB force update automatically.\n1. Synchronizes the new certificates to all participating clusters.\n\nNo manual intervention is required.\n\n## Use production certificate authorities\n\n### Let's Encrypt and ACME issuers\n\nYou can use Let's Encrypt and other ACME issuers, but not as an out-of-the-box integration. ACME issuers don't populate the `ca.crt` field of the generated TLS secret with the root certificate, so the secret that cert-manager creates doesn't include the full certificate chain.\n\nRedis Software needs the full chain, including the root CA, to trust the certificate. Whenever cert-manager doesn't populate `ca.crt` with the root certificate, supply the full chain yourself:\n\n1. Assemble the full certificate chain, including the root CA certificate.\n1. Create a Kubernetes secret that contains the full chain.\n1. Reference that secret in your Redis custom resource instead of the secret that cert-manager generates.\n\n\u003e [!NOTE]\n\u003e This applies to any issuer that doesn't populate `ca.crt` with the root certificate, not only Let's Encrypt.\n\nFor production environments where the issuer supplies the full chain automatically, such as a private CA or HashiCorp Vault, no extra steps are required.\n\n### Private CA\n\nFor internal deployments with a private certificate authority:\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n  name: private-ca-issuer\nspec:\n  ca:\n    secretName: ca-key-pair\n```\n\nThe `ca-key-pair` secret must contain your CA's certificate and private key.\n\n## Migrate from manual certificate management\n\nIf you currently use manually created secrets, you can migrate to cert-manager without downtime.\n\n1. Install cert-manager and create issuers (as shown in previous examples).\n\n1. Create `Certificate` resources with **different secret names** than your current secrets:\n\n    ```yaml\n    apiVersion: cert-manager.io/v1\n    kind: Certificate\n    metadata:\n      name: new-api-cert\n    spec:\n      secretName: api-tls-new\n      issuerRef:\n        name: my-issuer\n        kind: ClusterIssuer\n    ```\n\n1. Update your REC to reference the new secrets:\n\n    ```yaml\n    apiVersion: app.redislabs.com/v1\n    kind: RedisEnterpriseCluster\n    metadata:\n      name: rec\n    spec:\n      certificates:\n        apiCertificateSecretName: api-tls-new\n    ```\n\n    The operator updates the cluster with the new certificates. For Active-Active databases, the changes automatically sync to all clusters.\n\n1. After verifying the new certificates work correctly, delete the old manually created secrets:\n\n    ```bash\n    kubectl delete secret old-api-tls -n redis-namespace\n    ```\n\n## Certificate renewal and monitoring\n\n### Automatic renewal\n\ncert-manager automatically renews certificates before they expire based on the `renewBefore` setting in the `Certificate` spec:\n\n```yaml\nspec:\n  duration: 2160h    # 90 days\n  renewBefore: 360h  # Renew 15 days before expiration\n```\n\n### Monitor certificate status\n\nCheck certificate status:\n\n```bash\nkubectl get certificate -n redis-namespace\n```\n\nView detailed certificate information:\n\n```bash\nkubectl describe certificate redis-api-cert -n redis-namespace\n```\n\n## Troubleshooting\n\n### Certificate not issued\n\nCheck the certificate status and cert-manager logs:\n\n```bash\nkubectl describe certificate \u003ccertificate-name\u003e -n \u003cnamespace\u003e\nkubectl logs -n cert-manager deployment/cert-manager\n```\n\nCommon issues:\n\n- **Issuer not ready**: Verify your `Issuer` or `ClusterIssuer` is configured correctly.\n- **DNS validation failure**: For ACME issuers, ensure DNS records are correctly configured.\n- **Rate limits**: Let's Encrypt has rate limits. Use the staging environment for testing.\n\n### Operator not detecting certificate changes\n\nVerify the secret exists and has the correct format:\n\n```bash\nkubectl get secret \u003csecret-name\u003e -n \u003cnamespace\u003e -o yaml\n```\n\nConfirm the secret contains `tls.crt` and `tls.key` fields. Check operator logs:\n\n```bash\nkubectl logs -n \u003coperator-namespace\u003e deployment/redis-enterprise-operator\n```\n\n### Certificate chain issues\n\nIf you encounter certificate chain validation errors:\n\n1. Verify the `ca.crt` field is present in the secret (cert-manager populates this automatically when it has access to the root CA).\n1. If `ca.crt` is not present, ensure the certificate in `tls.crt` includes the full chain inline.\n1. Confirm the certificate chain is in the correct order: leaf certificate first, then intermediates, then root.\n\n## Best practices\n\n- **Use appropriate certificate lifetimes**: 90 days with a 15-day renewal window for production. Use shorter lifetimes in development to test renewal.\n- **Configure proper DNS names**: Include all necessary DNS names and SANs in your `Certificate` spec.\n- **Monitor certificate expiration**: Set up alerts for certificate expiration, even with automatic renewal.\n- **Use `ClusterIssuers` for shared issuers**: If multiple namespaces need certificates from the same CA, use `ClusterIssuers` instead of namespace-scoped `Issuers`.\n- **Back up CA private keys**: If using a private CA, ensure the CA private key secret is backed up.\n\n## See also\n\n- [cert-manager documentation](https://cert-manager.io/docs/)\n- [Manage REC certificates](https://redis.io/docs/latest/operate/kubernetes/security/certificates/manage-rec-certificates)\n- [RedisEnterpriseCluster API reference](https://redis.io/docs/latest/operate/kubernetes/reference/api/redis_enterprise_cluster_api)\n- [RedisEnterpriseDatabase API reference](https://redis.io/docs/latest/operate/kubernetes/reference/api/redis_enterprise_database_api)\n- [HashiCorp Vault integration](https://redis.io/docs/latest/operate/kubernetes/security/vault)\n",
  "tags": ["docs","operate","kubernetes"],
  "last_updated": "2026-10-19T14:33:15-05:00"
}