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.
| ## Prerequisites | ||
|
|
||
| - Kubernetes cluster with Redis Enterprise operator installed | ||
| - cert-manager v1.0 or later installed |
There was a problem hiding this comment.
We never tested the solution with v1.0.
The earliest version we tested with was 1.19.0, because this was the latest available version. I'm not sure if it's critical though.
| |---------|---------------------| | ||
| | Certificate | `tls.crt`, `cert`, `certificate` | | ||
| | Private key | `tls.key`, `key` | | ||
| | CA certificate | `ca.crt` (optional) | |
There was a problem hiding this comment.
Even though the field itself is optional, the operator requires access to the whole certificate chain.
Also, ca.crt is something we expect only TLS secrets created by the cert manager to have.
|
|
||
| {{<note>}}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.{{</note>}} | ||
|
|
||
| ## Quick start |
There was a problem hiding this comment.
Maybe we could shorten some of the examples in this section. Specifically, we can omit the pars that are setting up the "Issuer"/"ClusterIssuer" things. It's best to focus on providing examples of our APIs.
One thing important to stress in this document is that users can switch from opaque secrets that they are currently using to TLS secrets (the cert manager is creating K8s secrets of type "TLS") without any additional configurations.
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.