{
  "id": "cert-manager",
  "title": "Integrate cert-manager with Redis for Kubernetes",
  "url": "https://redis.io/docs/latest/operate/kubernetes/8.0.18/security/cert-manager/",
  "summary": "Automate TLS certificate management for Redis for Kubernetes using 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\nThe 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 Enterprise operator installed\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\nIf 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\nThe `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/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\n\nFor production environments, you can use Let's Encrypt:\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n  name: letsencrypt-prod\nspec:\n  acme:\n    server: https://acme-v02.api.letsencrypt.org/directory\n    email: admin@example.com\n    privateKeySecretRef:\n      name: letsencrypt-prod-account-key\n    solvers:\n      - http01:\n          ingress:\n            class: nginx\n```\n\nThen reference this issuer in your `Certificate` resources:\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: Certificate\nmetadata:\n  name: redis-api-cert\nspec:\n  secretName: redis-api-tls\n  issuerRef:\n    name: letsencrypt-prod\n    kind: ClusterIssuer\n  dnsNames:\n    - redis-api.example.com\n```\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/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-06-04T14:49:57+01:00"
}