K8s: cert manager#3001
Conversation
🛡️ Jit Security Scan Results
✅ No security findings were detected in this PR
Security scan by Jit
|
dwdougherty
left a comment
dwdougherty
left a comment
There was a problem hiding this comment.
Just one comment you should feel free to ignore. Otherwise, language LGTM.
| 1. After verifying the new certificates work correctly, delete the old manually created secrets: | ||
|
|
||
| ```bash | ||
| kubectl delete secret old-api-tls -n redis-namespace |
There was a problem hiding this comment.
Maybe change "old-api-tls" to "api-tls-old" to more closely match "api-tls-new".
| - `tls.crt`: The certificate in PEM format | ||
| - `tls.key`: The private key in PEM format | ||
| - `ca.crt`: (Optional) The root CA certificate |
There was a problem hiding this comment.
This one is actually important.
The thing is that the ca.crt field is populated only if the cert-manager has access to the root certificate.
If it does not have access to the root certificate then it's up to the user to either populate the ca.crt field manually or make sure that tls.crt has been modified to include the root certificate.
Our documentation clearly requires the whole certificate chain to be uploaded to redis enterprise.
So our secrets must contain the whole certificate chain.
3 participants
Note
Low Risk
Documentation-only changes that add new guidance and cross-links; no product or operator behavior is modified.
Overview
Adds a new
cert-managerintegration page describing how to use cert-manager-issued TLS secrets across Redis Enterprise cluster components, replication, LDAP, and SSO, including renewal, troubleshooting, and migration guidance.Updates the Kubernetes Security index to link to the new page and adds a note in
manage-rec-certificatespointing readers to cert-manager as an automation alternative.Reviewed by Cursor Bugbot for commit 7d094b3. Bugbot is set up for automated code reviews on this repo. Configure here.