Add hub-spoke trust config, root CA monitoring, and kubeconfig guidance - #773
Closed
sebrandon1 wants to merge 1 commit into
Closed
Add hub-spoke trust config, root CA monitoring, and kubeconfig guidance#773sebrandon1 wants to merge 1 commit into
sebrandon1 wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sebrandon1 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (21)
📝 WalkthroughWalkthroughThis PR adds cert-manager hub-spoke trust resources, root CA expiration monitoring, expanded certificate policy coverage, optional cluster annotations, and documentation for issuer configuration, deployment ordering, kubeconfig trust recovery, and certificate rotation. ChangesCert-manager trust and monitoring
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant RootCASecret
participant HubCAConfigMap
participant KlusterletConfig
participant ManagedCluster
RootCASecret->>HubCAConfigMap: provide root CA bundle
HubCAConfigMap->>KlusterletConfig: expose trusted CA bundle
ManagedCluster->>KlusterletConfig: select cert-manager-ca-config
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
telco-ran/configuration/source-crs/cert-manager/README.md (1)
66-75:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftAdd kubeconfig update step in Deployment Order for custom CA scenarios.
For Option B (self-signed CA) and Option C (existing internal CA), the kubeconfig must be updated to trust the new root CA before applying the APIServer configuration in step 7. Otherwise, administrators will be locked out and unable to run
occommands.📝 Suggested addition to Deployment Order
Add a new step between 6 and 7:
6. Wait for certificates to be issued and secrets created +6a. **(For Option B & C only)** Extract the root CA certificate and update kubeconfig (see "Important: Kubeconfig Trust After API Server Cert Replacement" section below) 7. Apply the APIServer and IngressController configurations🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-ran/configuration/source-crs/cert-manager/README.md` around lines 66 - 75, Deployment order misses a necessary kubeconfig update for custom CA flows: for Option B (self-signed CA) and Option C (existing internal CA) update the cluster-admin kubeconfig to trust the new root CA before applying the APIServer and IngressController configurations; insert a new step between steps 6 and 7 in the "Deployment Order" that instructs operators to add the new CA certificate to their local kubeconfig (or cluster trust store) and verify oc client connectivity (e.g., confirm oc whoami and oc get pods) so administrators are not locked out when APIServer changes are applied.telco-hub/configuration/reference-crs/optional/cert-manager/README.md (1)
66-73:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftAdd kubeconfig update step in Deployment Order for custom CA scenarios.
For Option B (self-signed CA) and Option C (existing internal CA), the kubeconfig must be updated to trust the new root CA before applying the APIServer configuration in step 5. Otherwise, administrators will be locked out and unable to run
occommands.📝 Suggested additions to Deployment Order
Add two missing steps:
3. Deploy the ClusterIssuer -4. Wait for certificates to be issued and secrets created -5. Apply the APIServer and IngressController configurations +4. Deploy the Certificate resources +5. Wait for certificates to be issued and secrets created +5a. **(For Option B & C only)** Extract the root CA certificate and update kubeconfig (see "Important: Kubeconfig Trust After API Server Cert Replacement" section below) +6. Apply the APIServer and IngressController configurations🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-hub/configuration/reference-crs/optional/cert-manager/README.md` around lines 66 - 73, The Deployment Order is missing a kubeconfig update step for Option B (self-signed CA) and Option C (existing internal CA); before applying the APIServer configuration in step 5, add a step that updates administrators' kubeconfig to trust the new root CA (e.g., import the new CA into the cluster admin kubeconfig or distribute the updated kubeconfig) so `oc` commands continue to work; reference the existing steps involving ClusterIssuer, APIServer and IngressController and ensure the new kubeconfig-trust step appears after "Wait for certificates to be issued and secrets created" and immediately before "Apply the APIServer and IngressController configurations."telco-core/configuration/reference-crs/optional/cert-manager/README.md (1)
66-74:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftAdd kubeconfig update step in Deployment Order for custom CA scenarios.
For Option B (self-signed CA) and Option C (existing internal CA), the kubeconfig must be updated to trust the new root CA before applying the APIServer configuration in step 6. Otherwise, administrators will be locked out and unable to run
occommands.📝 Suggested addition to Deployment Order
Add a new step between 5 and 6:
5. Wait for certificates to be issued and secrets created +5a. **(For Option B & C only)** Extract the root CA certificate and update kubeconfig (see "Important: Kubeconfig Trust After API Server Cert Replacement" section below) 6. Apply the APIServer and IngressController configurations🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md` around lines 66 - 74, Update the "Deployment Order" section in README.md to insert a new step between steps 5 and 6 that instructs operators, for Option B (self-signed CA) and Option C (existing internal CA), to update cluster admin kubeconfigs to trust the new root CA before applying the APIServer and IngressController configurations; reference the Deployment Order heading and explicitly state that kubeconfigs must be updated so admins can run oc commands and avoid being locked out, and link or mention the mechanism to update kubeconfigs (e.g., adding the new CA to kubeconfig trust) so it's clear when and why this step is required.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@telco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCACertificate.yaml`:
- Line 6: The namespace templating in certManagerRootCACertificate.yaml ("{{
.metadata.namespace | default \"cert-manager\" }}") must be removed so the
Secret is created in cert-manager where ClusterIssuer.spec.ca.secretName looks
for it; update certManagerRootCACertificate.yaml to use a fixed namespace value
of "cert-manager" (or remove the namespace field so it defaults to cert-manager)
so the Secret and ClusterIssuer.spec.ca.secretName resolve correctly.
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 83-111: Update the "Kubeconfig Trust After API Server Cert
Replacement" section to make clear this kubeconfig update is a required
deployment step for Option B (Self-signed CA) and Option C (Existing internal
CA) and must be done before applying the APIServer configuration; add a
prominent note/callout at the top of the section (referencing the section title
and the commands shown, e.g., the oc get secret root-ca-secret ... and oc config
set-cluster ... examples) stating that performing the kubeconfig update prior to
applying the APIServer config prevents being locked out and that running oc get
secret after APIServer replacement will fail with x509 errors.
In
`@telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCACertificate.yaml`:
- Line 6: The template sets namespace via metadata.namespace which can place the
root CA Secret outside cert-manager's cluster-resource namespace so
ClusterIssuer.spec.ca.secretName cannot find it; change the resource so the
Secret is created in the cert-manager cluster-resource namespace by removing the
templated metadata.namespace and/or hardcoding namespace: "cert-manager" (or
using the cluster-resource namespace value) so ClusterIssuer.spec.ca.secretName
can always resolve the Secret.
In
`@telco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCATrustPolicy.yaml`:
- Around line 29-40: The lookup of the CA Secret is running on managed clusters;
change the template to fetch the Secret from the hub by wrapping the lookup in
hub delimiters and applying protect so the hub Secret is resolved server-side:
replace the current (lookup "v1" "Secret" "cert-manager" "root-ca-secret") usage
for variable $hubCA with a hub-scoped lookup (e.g. using the hub lookup ... hub
pattern) and apply | protect, and keep the subsequent conditional if $hubCA
unchanged so the rendered ConfigMap uses the hub CA bundle.
In
`@telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yaml`:
- Around line 45-55: Update CertManagerRootCAExpirationWarning and
CertManagerRootCAExpirationCritical to scope by both labels and prevent overlap:
add namespace filtering to the metric
certmanager_certificate_expiration_timestamp_seconds by including
namespace="{{...}}" in the expr for both alerts (since the metric has both name
and namespace labels) and change the warning alert expression
(CertManagerRootCAExpirationWarning) so it only matches certificates expiring in
>=30 days and <90 days (e.g., include an explicit lower bound like
certmanager_certificate_expiration_timestamp_seconds{name="root-ca",
namespace="{{...}}"} - time() >= 30 * 24 * 3600 && ... < 90 * 24 * 3600) while
CertManagerRootCAExpirationCritical remains <30d with the same namespace filter;
use the alert names CertManagerRootCAExpirationWarning and
CertManagerRootCAExpirationCritical to locate and update the rules.
In
`@telco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yaml`:
- Around line 9-12: The comment in kustomization.yaml is misleading: instead of
instructing users to "uncomment one" when choosing alternative issuers, clarify
that the self-signed bootstrap flow requires enabling multiple manifests
together (certManagerClusterIssuerSelfSigned.yaml,
certManagerRootCACertificate.yaml, and certManagerClusterIssuerCA.yaml) while
the ACME issuer is an alternative; update the comment to instruct users to
uncomment either the ACME issuer block or the full set of self-signed manifests
(list them explicitly) so operators know to enable all required files for the
self-signed path and avoid partial/invalid configurations.
In `@telco-hub/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 82-110: Update the "Kubeconfig Trust After API Server Cert
Replacement" section to clarify this is a required deployment step for Option B
and C (not just a recovery step) by adding a prominent note before the steps
that says users must update kubeconfig before applying the APIServer
configuration; reference the section title and the commands shown (oc get secret
root-ca-secret -n cert-manager -o jsonpath=..., oc config set-cluster ...
--certificate-authority=... --embed-certs) and explicitly warn that applying the
APIServer config first will cause oc and API clients to fail with x509 errors
and prevent retrieving the secret.
In `@telco-ran/configuration/source-crs/cert-manager/README.md`:
- Around line 84-112: Add a clear pre-deployment callout to the "Important:
Kubeconfig Trust After API Server Cert Replacement" section stating that the
kubeconfig update is a required deployment step for Option B (Self-signed CA)
and Option C (Existing internal CA) and must be completed before applying the
APIServer configuration (referenced as "step 7 of the deployment order"); update
the title or first paragraph to explicitly warn users that applying the
APIServer config first will lock them out and cause the `oc get secret` command
shown in the example to fail with an x509 error, and ensure the note references
Options B & C and the APIServer deployment step so readers know this is not a
post-incident recovery but a mandatory pre-apply step.
---
Outside diff comments:
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 66-74: Update the "Deployment Order" section in README.md to
insert a new step between steps 5 and 6 that instructs operators, for Option B
(self-signed CA) and Option C (existing internal CA), to update cluster admin
kubeconfigs to trust the new root CA before applying the APIServer and
IngressController configurations; reference the Deployment Order heading and
explicitly state that kubeconfigs must be updated so admins can run oc commands
and avoid being locked out, and link or mention the mechanism to update
kubeconfigs (e.g., adding the new CA to kubeconfig trust) so it's clear when and
why this step is required.
In `@telco-hub/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 66-73: The Deployment Order is missing a kubeconfig update step
for Option B (self-signed CA) and Option C (existing internal CA); before
applying the APIServer configuration in step 5, add a step that updates
administrators' kubeconfig to trust the new root CA (e.g., import the new CA
into the cluster admin kubeconfig or distribute the updated kubeconfig) so `oc`
commands continue to work; reference the existing steps involving ClusterIssuer,
APIServer and IngressController and ensure the new kubeconfig-trust step appears
after "Wait for certificates to be issued and secrets created" and immediately
before "Apply the APIServer and IngressController configurations."
In `@telco-ran/configuration/source-crs/cert-manager/README.md`:
- Around line 66-75: Deployment order misses a necessary kubeconfig update for
custom CA flows: for Option B (self-signed CA) and Option C (existing internal
CA) update the cluster-admin kubeconfig to trust the new root CA before applying
the APIServer and IngressController configurations; insert a new step between
steps 6 and 7 in the "Deployment Order" that instructs operators to add the new
CA certificate to their local kubeconfig (or cluster trust store) and verify oc
client connectivity (e.g., confirm oc whoami and oc get pods) so administrators
are not locked out when APIServer changes are applied.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 5a1209f0-501f-4c13-840f-2d96de51484a
📒 Files selected for processing (27)
telco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCACertificate.yamltelco-core/configuration/reference-crs/optional/cert-manager/README.mdtelco-core/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-core/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-core/configuration/reference-crs/optional/cert-manager/certManagerRootCACertificate.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCACertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/README.mdtelco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCATrustPolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCATrustPolicyPlacement.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCATrustPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCACertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerSpokeCATrustCM.yamltelco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yamltelco-ran/configuration/source-crs/cert-manager/README.mdtelco-ran/configuration/source-crs/cert-manager/certManagerClusterIssuerCA.yamltelco-ran/configuration/source-crs/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-ran/configuration/source-crs/cert-manager/certManagerRootCACertificate.yaml
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
3 times, most recently
from
May 19, 2026 19:18
30229a7 to
29b4fd7
Compare
imiller0
reviewed
May 20, 2026
sebrandon1
changed the title
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
telco-ran/configuration/source-crs/cert-manager/certManagerRootCACertificate.yaml (1)
6-7: ⚡ Quick winUse a later ZTP deploy wave for
root-cathanselfsigned-issuer.
root-cacurrently uses the same wave ("10") as its issuer, which can make first-pass ordering non-deterministic. Set thisCertificateto a later wave (for example"11") so issuer creation is deterministically sequenced before issuance.Proposed change
metadata: name: root-ca namespace: cert-manager annotations: - ran.openshift.io/ztp-deploy-wave: "10" + ran.openshift.io/ztp-deploy-wave: "11"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-ran/configuration/source-crs/cert-manager/certManagerRootCACertificate.yaml` around lines 6 - 7, The Certificate resource 'root-ca' is annotated with the same ZTP deploy wave ("10") as its issuer 'selfsigned-issuer', which can cause non-deterministic ordering; update the annotation on the 'root-ca' Certificate (certManagerRootCACertificate.yaml, resource name root-ca) to use a later deploy wave (e.g., change ran.openshift.io/ztp-deploy-wave from "10" to "11") so the issuer (selfsigned-issuer) is created before the root CA is issued.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 53-56: The docs use inconsistent secret keys: they instruct
creating a Secret named `root-ca-secret` with `tls.crt`/`tls.key` but later
extraction commands expect `ca.crt`; update the README to use the same key name
everywhere (choose either `tls.crt` or `ca.crt`) and make the `root-ca-secret`
creation, the `certManagerClusterIssuerCA.yaml` usage, and the Certificate
`issuerRef` examples all reference that single consistent secret key name so the
kubeconfig/root CA extraction step will succeed in the internal/disconnected CA
flow.
In `@telco-hub/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 53-56: The README has a key mismatch: the secret is documented as
named root-ca-secret containing tls.crt/tls.key but the kubeconfig trust command
reads ca.crt; update the docs so the secret key names match the command (either
change the secret description to use ca.crt/ca.key or change the command to read
tls.crt/tls.key) and ensure references to root-ca-secret, cert-manager
namespace, certManagerClusterIssuerCA.yaml, and issuerRef: ca-issuer are
consistent across the file (also apply the same fix to the other occurrence
around lines 97-100).
In `@telco-ran/configuration/source-crs/cert-manager/README.md`:
- Around line 53-56: The README is inconsistent: Option C tells users to create
a Secret named root-ca-secret with tls.crt/tls.key, but the kubeconfig
extraction step expects ca.crt and fails to produce /tmp/root-ca.crt; update the
docs so both places use the same key name (either tls.crt or ca.crt). Search for
root-ca-secret, certManagerClusterIssuerCA.yaml, ca-issuer and the kubeconfig
extraction that writes /tmp/root-ca.crt, then change the extraction command or
the Secret key name so they match (and update any references to tls.key/tls.crt
or ca.crt/ca.key accordingly). Ensure the README consistently documents the
chosen key names across Option C and the kubeconfig step.
---
Nitpick comments:
In
`@telco-ran/configuration/source-crs/cert-manager/certManagerRootCACertificate.yaml`:
- Around line 6-7: The Certificate resource 'root-ca' is annotated with the same
ZTP deploy wave ("10") as its issuer 'selfsigned-issuer', which can cause
non-deterministic ordering; update the annotation on the 'root-ca' Certificate
(certManagerRootCACertificate.yaml, resource name root-ca) to use a later deploy
wave (e.g., change ran.openshift.io/ztp-deploy-wave from "10" to "11") so the
issuer (selfsigned-issuer) is created before the root CA is issued.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: b5c17fd7-a763-4751-a732-766cb671e8ab
📒 Files selected for processing (27)
telco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-core/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCACertificate.yamltelco-core/configuration/reference-crs/optional/cert-manager/README.mdtelco-core/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-core/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-core/configuration/reference-crs/optional/cert-manager/certManagerRootCACertificate.yamltelco-hub/configuration/reference-crs-kube-compare/compare_ignoretelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCACertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/README.mdtelco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerCA.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCACertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerSpokeCATrustCM.yamltelco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yamltelco-ran/configuration/kube-compare-reference/hack/compare_ignoretelco-ran/configuration/source-crs/cert-manager/README.mdtelco-ran/configuration/source-crs/cert-manager/certManagerClusterIssuerCA.yamltelco-ran/configuration/source-crs/cert-manager/certManagerClusterIssuerSelfSigned.yamltelco-ran/configuration/source-crs/cert-manager/certManagerRootCACertificate.yaml
✅ Files skipped from review due to trivial changes (4)
- telco-hub/configuration/reference-crs-kube-compare/compare_ignore
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCACertificate.yaml
- telco-ran/configuration/kube-compare-reference/hack/compare_ignore
- telco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yaml
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
May 20, 2026 21:08
a0c7607 to
fdcccb5
Compare
Collaborator
|
I don't think we should be adding self-signed certificates to the reference configuration. ACME can be used in disconnected environments with suitable issuer/pki |
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
May 27, 2026 16:11
fdcccb5 to
4710a27
Compare
sebrandon1
changed the title
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
4 times, most recently
from
May 28, 2026 19:19
4930307 to
644fd05
Compare
sebrandon1
changed the title
sebrandon1
changed the title
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
June 1, 2026 16:33
b846cb2 to
40129b5
Compare
openshift-ci
Bot
added
the
needs-rebase
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
June 1, 2026 16:34
40129b5 to
f56c0a8
Compare
openshift-ci
Bot
removed
the
needs-rebase
imiller0
reviewed
Jun 2, 2026
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
4 times, most recently
from
June 2, 2026 15:06
31dd12b to
b9664ab
Compare
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
2 times, most recently
from
July 1, 2026 19:58
7e5a0dd to
bcc7120
Compare
sebrandon1
added a commit
to sebrandon1/telco-reference
that referenced
this pull request
Jul 6, 2026
Cert-manager was removed from RAN for 4.22 GA (PR openshift-kni#801, OCPBUGS-86666). Now that branches have been cut, restore it to main for IBU testing. Restored files: - 9 source CRs + README in source-crs/cert-manager/ - 3 kube-compare templates in kube-compare-reference/cert-manager/ - metadata.yaml, compare_ignore, default_value.yaml, acm-common-ranGen.yaml README updated with ACME-only issuer wording and kubeconfig trust guidance aligned with hub cert-manager improvements (PR openshift-kni#773).
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
July 6, 2026 16:18
bcc7120 to
2790250
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (2)
telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml (1)
1-15: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winMissing ArgoCD sync-wave/sync-options annotations.
Same gap as the sibling Placement — this PlacementBinding has no
sync-wave/sync-optionsannotations, unlike the Policy it binds (-10) and other Policy/Placement/PlacementBinding sets in this repo (e.g.observabilityRoutePlacementBinding). This is a downstream repeat of the missing-annotation issue incertManagerRootCAExpirationPolicyPlacement.yaml.Suggested diff
metadata: name: root-ca-expiration-placementbinding namespace: default + annotations: + argocd.argoproj.io/sync-wave: "-11" + argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true placementRef:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml` around lines 1 - 15, The PlacementBinding resource is missing the ArgoCD sync annotations needed to match the related Policy/Placement ordering. Update the metadata on certManagerRootCAExpirationPolicyPlacementBinding to include the same sync-wave and sync-options annotations used by sibling resources such as observabilityRoutePlacementBinding, and keep it aligned with the root-ca-expiration-policy/placement set so ArgoCD applies them in the intended order.telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml (1)
1-16: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winMissing ArgoCD sync-wave/sync-options annotations.
This Placement lacks
argocd.argoproj.io/sync-waveandsync-options: SkipDryRunOnMissingResource=true, unlike the siblingcertManagerRootCAExpirationPolicy.yaml(sync-wave "-10") and the analogousobservabilityRoutePlacement.yamlpattern elsewhere in the repo. Without a sync-wave, ArgoCD may attempt to apply this alongside/after resources it should precede, and withoutSkipDryRunOnMissingResource, dry-run could fail if the Placement CRD isn't yet established on a fresh hub.Suggested diff
metadata: name: root-ca-expiration-placement namespace: default + annotations: + argocd.argoproj.io/sync-wave: "-11" + argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true spec:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml` around lines 1 - 16, The Placement manifest for root-ca-expiration-placement is missing the ArgoCD annotations needed for ordered sync and safe dry-run. Add the same metadata annotations used by certManagerRootCAExpirationPolicy and the observabilityRoutePlacement pattern: set argocd.argoproj.io/sync-wave to the appropriate earlier wave (matching the sibling policy) and include argocd.argoproj.io/sync-options with SkipDryRunOnMissingResource=true so ArgoCD can apply the Placement even when the CRD is not yet present.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml`:
- Around line 1-16: The Placement manifest for root-ca-expiration-placement is
missing the ArgoCD annotations needed for ordered sync and safe dry-run. Add the
same metadata annotations used by certManagerRootCAExpirationPolicy and the
observabilityRoutePlacement pattern: set argocd.argoproj.io/sync-wave to the
appropriate earlier wave (matching the sibling policy) and include
argocd.argoproj.io/sync-options with SkipDryRunOnMissingResource=true so ArgoCD
can apply the Placement even when the CRD is not yet present.
In
`@telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml`:
- Around line 1-15: The PlacementBinding resource is missing the ArgoCD sync
annotations needed to match the related Policy/Placement ordering. Update the
metadata on certManagerRootCAExpirationPolicyPlacementBinding to include the
same sync-wave and sync-options annotations used by sibling resources such as
observabilityRoutePlacementBinding, and keep it aligned with the
root-ca-expiration-policy/placement set so ArgoCD applies them in the intended
order.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 4876510d-9fee-442c-8ac1-80d75b8e1948
📒 Files selected for processing (29)
telco-core/configuration/reference-crs-kube-compare/optional/cert-manager/apiServerCertificate.yamltelco-core/configuration/reference-crs-kube-compare/optional/cert-manager/ingressCertificate.yamltelco-core/configuration/reference-crs/optional/cert-manager/README.mdtelco-core/configuration/reference-crs/optional/cert-manager/apiServerCertificate.yamltelco-core/configuration/reference-crs/optional/cert-manager/ingressCertificate.yamltelco-core/install/example-standard-clusterinstance.yamltelco-hub/configuration/reference-crs-kube-compare/compare_ignoretelco-hub/configuration/reference-crs-kube-compare/default_value.yamltelco-hub/configuration/reference-crs-kube-compare/metadata.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/apiServerCertificate.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerHubCAConfigMap.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerKlusterletConfig.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/ingressCertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/README.mdtelco-hub/configuration/reference-crs/optional/cert-manager/apiServerCertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCAConfigMap.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerKlusterletConfig.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/ingressCertificate.yamltelco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yamltelco-ran/configuration/argocd/example/clusterinstance/example-3node.yamltelco-ran/configuration/argocd/example/clusterinstance/example-sno.yamltelco-ran/configuration/argocd/example/clusterinstance/example-standard.yaml
✅ Files skipped from review due to trivial changes (9)
- telco-hub/configuration/reference-crs/optional/cert-manager/apiServerCertificate.yaml
- telco-core/configuration/reference-crs-kube-compare/optional/cert-manager/apiServerCertificate.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-standard.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerKlusterletConfig.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-3node.yaml
- telco-core/install/example-standard-clusterinstance.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-sno.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yaml
🚧 Files skipped from review as they are similar to previous changes (4)
- telco-hub/configuration/reference-crs-kube-compare/compare_ignore
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yaml
imiller0
reviewed
Jul 7, 2026
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
telco-core/configuration/reference-crs/optional/cert-manager/README.md (1)
103-105: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winScope the PKI trust-store note to workstation clients. The trust-store step only affects clients that use
/etc/pki/ca-trust/...; existing kubeconfigs with embeddedcertificate-authority-datastill need the kubeconfig update above.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md` around lines 103 - 105, The PKI trust-store guidance in the cert-manager README is too broad and should be scoped to workstation clients only. Update the wording in the “Best practice for PKI environments” section so it clearly states that adding the root CA to the local trust store via /etc/pki/ca-trust/source/anchors and update-ca-trust only helps workstation/client trust, while kubeconfigs using embedded certificate-authority-data still require the kubeconfig update described earlier.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 48-52: Clarify the TLS 1.3 guidance in the cert-manager README:
the current text overstates RSA’s removal by implying RSA certificates are
unsupported, when only RSA key exchange was removed. Update the wording in the
referenced note near the ECDSA/RSA guidance to state that RSA certificates are
still supported in TLS 1.3 for authentication, while this reference
configuration uses ECDSA P-256 as the documented deployment path.
---
Outside diff comments:
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 103-105: The PKI trust-store guidance in the cert-manager README
is too broad and should be scoped to workstation clients only. Update the
wording in the “Best practice for PKI environments” section so it clearly states
that adding the root CA to the local trust store via
/etc/pki/ca-trust/source/anchors and update-ca-trust only helps
workstation/client trust, while kubeconfigs using embedded
certificate-authority-data still require the kubeconfig update described
earlier.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: b63f36ae-73b4-4c90-8ca2-003a7036d5f5
📒 Files selected for processing (2)
telco-core/configuration/reference-crs/optional/cert-manager/README.mdtelco-hub/configuration/reference-crs/optional/cert-manager/README.md
🚧 Files skipped from review as they are similar to previous changes (1)
- telco-hub/configuration/reference-crs/optional/cert-manager/README.md
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
2 times, most recently
from
July 7, 2026 16:28
e85f636 to
1a42ce8
Compare
Contributor
Author
|
The
This uses ACM's official CA bundle distribution mechanism instead of the insecure |
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
July 7, 2026 16:54
1a42ce8 to
e94e162
Compare
Contributor
Author
|
Renamed |
yuvalk
reviewed
Jul 7, 2026
yuvalk
reviewed
Jul 7, 2026
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
July 7, 2026 18:49
e94e162 to
5042ddd
Compare
sebrandon1
commented
Jul 7, 2026
sebrandon1
left a comment
sebrandon1
left a comment
Contributor
Author
There was a problem hiding this comment.
Good catch! I've updated the documentation to address both concerns:
- Platform-specific instructions: Added explicit commands for Red Hat/Fedora/CentOS, Debian/Ubuntu, and macOS
- Kubeconfig certificate data blocking OS trust store fallback: Added a new section explaining that
oc/kubectlwon't fall back to the OS trust store if the kubeconfig contains embeddedcertificate-authority-data, with instructions on how to clear it usingoc config unset
The updated section now provides complete guidance for users on all major platforms and makes it clear that removing the embedded kubeconfig CA data is required for the OS trust store to take effect.
Thanks for the detailed feedback!
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 128-132: The kubeconfig cleanup command in the cert-manager README
uses a brittle dotted path in `oc config unset` that can break when the cluster
name contains punctuation. Update the documented recovery step to use a stable
kubeconfig edit approach in the same section so users can reliably remove
`certificate-authority-data` regardless of cluster name formatting.
In `@telco-hub/configuration/reference-crs/optional/cert-manager/README.md`:
- Around line 128-132: The kubeconfig unset command is using a brittle dotted
cluster path that can break when the cluster name contains punctuation, so
update the cert-manager README to show a stable way to target the current
cluster entry via a quoted or explicitly resolved path. Keep the guidance
centered around the `oc config view --minify` cluster name lookup and the `oc
config unset` example, but replace the direct
`clusters.$(...).certificate-authority-data` form with a safer edit pattern that
reliably removes the embedded CA field.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 666b9a08-c7bb-4a1b-9f49-364ccf1daecf
📒 Files selected for processing (21)
telco-core/configuration/reference-crs/optional/cert-manager/README.mdtelco-core/install/example-standard-clusterinstance.yamltelco-hub/configuration/reference-crs-kube-compare/compare_ignoretelco-hub/configuration/reference-crs-kube-compare/default_value.yamltelco-hub/configuration/reference-crs-kube-compare/metadata.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerHubCAConfigMap.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerKlusterletConfig.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/README.mdtelco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCAConfigMap.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerKlusterletConfig.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yamltelco-ran/configuration/argocd/example/clusterinstance/example-3node.yamltelco-ran/configuration/argocd/example/clusterinstance/example-sno.yamltelco-ran/configuration/argocd/example/clusterinstance/example-standard.yaml
✅ Files skipped from review due to trivial changes (8)
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-3node.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml
- telco-core/install/example-standard-clusterinstance.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-sno.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-standard.yaml
- telco-hub/configuration/reference-crs-kube-compare/compare_ignore
🚧 Files skipped from review as they are similar to previous changes (11)
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerHubCAConfigMap.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCAConfigMap.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerKlusterletConfig.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerKlusterletConfig.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yaml
- telco-hub/configuration/reference-crs-kube-compare/metadata.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml
- telco-hub/configuration/reference-crs-kube-compare/default_value.yaml
Contributor
Author
|
/retest |
Contributor
Author
✅ Verification Complete (2026-07-08)Successfully validated cert-manager hub-spoke trust on OCP 4.21.22 hub + OCP 4.22 spoke with ACM 2.13. All critical success criteria met:
Full verification report: https://gist.github.com/sebrandon1/bba27f3e662c16e62fb552ea24c90d02 Recommendation: This PR is production-ready and ready to merge. |
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
July 23, 2026 19:50
896c084 to
be6da47
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@telco-core/configuration/reference-crs/optional/cert-manager/README.md`:
- Line 105: Limit the root-CA generation and workstation trust-store guidance to
non-public ACME issuers, including self-hosted/private ACME, or CA issuers;
explicitly exclude public ACME flows because their certificate chains are
already publicly trusted. Apply this wording change at
telco-core/configuration/reference-crs/optional/cert-manager/README.md lines
105-105 and
telco-hub/configuration/reference-crs/optional/cert-manager/README.md lines
105-105.
- Around line 94-95: Replace the context-derived cluster target in the oc config
set-cluster commands with the resolved .clusters[0].name value from oc config
view --minify. Apply this change at
telco-core/configuration/reference-crs/optional/cert-manager/README.md lines
94-95 and telco-hub/configuration/reference-crs/optional/cert-manager/README.md
lines 94-95, preserving the existing CA update behavior.
In `@telco-hub/configuration/reference-crs-kube-compare/compare_ignore`:
- Line 37: Remove the blanket ignore for certManagerRootCAExpirationPolicy.yaml
in compare_ignore so kube-compare validates the root CA expiration
PrometheusRule Policy. Either ignore only unavoidable dynamic fields or add a
minimal comparison template, and ensure the Policy is included in the monitoring
component’s all-or-none coverage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: c5445bd9-95b2-4d8a-b2e8-883f4267182c
📒 Files selected for processing (21)
telco-core/configuration/reference-crs/optional/cert-manager/README.mdtelco-core/install/example-standard-clusterinstance.yamltelco-hub/configuration/reference-crs-kube-compare/compare_ignoretelco-hub/configuration/reference-crs-kube-compare/default_value.yamltelco-hub/configuration/reference-crs-kube-compare/metadata.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerHubCAConfigMap.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerKlusterletConfig.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/README.mdtelco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCAConfigMap.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerKlusterletConfig.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yamltelco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yamltelco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yamltelco-ran/configuration/argocd/example/clusterinstance/example-3node.yamltelco-ran/configuration/argocd/example/clusterinstance/example-sno.yamltelco-ran/configuration/argocd/example/clusterinstance/example-standard.yaml
🚧 Files skipped from review as they are similar to previous changes (17)
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerCertificatePolicy.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerCertificatePolicy.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicy.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerRootCAExpirationPolicyPlacementBinding.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-sno.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerHubCAConfigMap.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerRootCAExpirationPolicyPlacement.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerKlusterletConfig.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/certManagerKlusterletConfig.yaml
- telco-hub/configuration/reference-crs-kube-compare/optional/cert-manager/certManagerHubCAConfigMap.yaml
- telco-core/install/example-standard-clusterinstance.yaml
- telco-hub/configuration/reference-crs-kube-compare/default_value.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-3node.yaml
- telco-hub/configuration/reference-crs/optional/cert-manager/kustomization.yaml
- telco-ran/configuration/argocd/example/clusterinstance/example-standard.yaml
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
July 23, 2026 19:55
be6da47 to
4514651
Compare
Hub-spoke CA trust distribution via KlusterletConfig and CA ConfigMap, made mandatory with kube-compare validation templates. Root CA expiration monitoring via ACM Policy with PrometheusRule alerts. CertificatePolicy expanded to monitor cert-manager namespace. Kubeconfig trust documentation added to all profile READMEs, applicable to any non-publicly-trusted issuer. Certificate Algorithm: ECDSA P-256 All Certificate resources use ECDSA P-256, which is required for TLS 1.3 compatibility. RSA key exchange has been removed from TLS 1.3 as it does not provide Forward Secrecy. ACME is the reference recommendation. Other issuer types are allowable but only ACME is provided in the reference. ZTP Integration: Document ZTP-native ClusterInstance extraAnnotations for cert-manager trust. Users can configure the KlusterletConfig annotation declaratively via ClusterInstance extraAnnotations instead of manual post-deployment steps. Related: lifecycle-agent PR #7610
sebrandon1
force-pushed
the
cert-manager-trust-store-ca-issuers
branch
from
July 23, 2026 20:03
4514651 to
a5bc214
Compare
|
@sebrandon1: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
openshift-ci
Bot
added
the
needs-rebase
Contributor
Author
|
Closing this PR — cert-manager is not ready for 4.22.z (targeted for November). The root CA monitoring piece has been split out and submitted independently:
The remaining hub-spoke trust, kubeconfig guidance, and README updates will be revisited when cert-manager is ready. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds hub-spoke trust configuration, root CA expiration monitoring, and kubeconfig trust recovery guidance for cert-manager deployments.
Companion RDS MR: reference-design-specifications!192
Changes
Hub-Spoke Trust Distribution (OCPBUGS-85774)
Requires ACM 2.11+ for
serverVerificationStrategysupport.Adds KlusterletConfig and CA ConfigMap to distribute the cert-manager root CA to managed spokes. Spokes trust the root CA instead of the hub's leaf certificate, enabling seamless cert rotation with no ManifestWork timing dependency.
New resources:
certManagerHubCAConfigMap.yaml- Root CA bundle ConfigMapcertManagerKlusterletConfig.yaml- KlusterletConfig withUseCustomCABundlesRoot CA Expiration Monitoring (OCPBUGS-85777)
Adds PrometheusRule alerting on root CA expiration (warning at 90 days, critical at 30 days). Extends existing
certManagerCertificatePolicyto monitor thecert-managernamespace.Kubeconfig Trust Recovery (OCPBUGS-85776)
Documents kubeconfig update procedure for non-publicly-trusted CAs. When cert-manager replaces the API server cert, existing kubeconfigs become invalid and must be updated to trust the new root CA.
Certificate Algorithm
All Certificate resources use ECDSA P-256 (recommended for TLS 1.3). While RSA certificates are still supported for authentication in TLS 1.3, ECDSA provides Forward Secrecy and better performance.
Note: Lifecycle-agent has limited ECDSA support (being addressed in lifecycle-agent#7610). QE may use RSA for testing; production should use ECDSA.
Issuer Guidance
ACME is the reference recommendation. Other issuer types (CA issuer for disconnected environments) are allowable—users may configure their own ClusterIssuer.
Testing
OCP 4.21.15 Validation
Validated on OCP 4.21.15 hub+spoke (SNO, ZTP, bare metal) with cert-manager v1.19.0:
OCP 4.22 Verification (2026-07-08)
Full end-to-end validation on OCP 4.21.22 hub + OCP 4.22 spoke with ACM 2.13:
CA:TRUE) ✅AVAILABLE=Trueduring hub cert rollout ✅