NE-2821: Add tls-scanner job for TLS1.3 on Gateway API - #82586
Conversation
|
@rikatz: This pull request references NE-2821 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this: Instructions 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 openshift-eng/jira-lifecycle-plugin repository. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (8)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughAdds component-scoped TLS scanning, a reusable TLS scanner recheck step, and optional AWS Gateway API TLS 1.3 scanning jobs for cluster-ingress-operator master and releases 4.23, 5.0, and 5.1. ChangesTLS scanner coverage
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Pipeline
participant GatewaySetup
participant GatewayAPI
participant TLSScanner
Pipeline->>GatewaySetup: Generate Gateway API scanner resources
GatewaySetup->>GatewayAPI: Create gateway resources
Pipeline->>GatewayAPI: Remove first listener hostname
Pipeline->>TLSScanner: Run tls-scanner-run, tls-13, and tls-scanner-recheck
Suggested reviewers: Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error, 1 warning)
✅ Passed checks (13 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 |
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
`@ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-master.yaml`:
- Around line 314-341: Regenerate CI metadata for the new tls-scanner-gatewayapi
job by running make update once after all edits, then commit the generated
output. Apply this for the master job
(ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-master.yaml:314-341),
4.23 job
(ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-4.23.yaml:287-314),
5.0 job
(ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.0.yaml:288-315),
and 5.1 job
(ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.1.yaml:287-314).
In
`@ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.0.yaml`:
- Around line 288-315: Regenerate the Prow-job configuration for the new
tls-scanner-gatewayapi job by running the repository’s make update target, and
commit all generated metadata and Prow-job output alongside the configuration
change.
🪄 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: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 551de558-e2c8-4769-9b1c-7ec8ae4f47f3
⛔ Files ignored due to path filters (4)
ci-operator/jobs/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-master-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-4.23-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.0-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.1-presubmits.yamlis excluded by!ci-operator/jobs/**
📒 Files selected for processing (7)
ci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-master.yamlci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-4.23.yamlci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.0.yamlci-operator/config/openshift/cluster-ingress-operator/openshift-cluster-ingress-operator-release-5.1.yamlci-operator/step-registry/tls/scanner/hypershift-run/tls-scanner-hypershift-run-ref.yamlci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.shci-operator/step-registry/tls/scanner/run/tls-scanner-run-ref.yaml
|
/pj-rehearse --pull=openshift/cluster-ingress-operator#1480 pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-gatewayapi |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@rikatz: job(s): --pull=openshift/cluster-ingress-operator#1480 either don't exist or were not found to be affected, and cannot be rehearsed |
|
/pj-rehearse help |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse list |
|
@rikatz: job(s): help either don't exist or were not found to be affected, and cannot be rehearsed |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/assign @gcs278 |
|
/assign @bentito |
gcs278
left a comment
There was a problem hiding this comment.
Generally LGTM, just a minor point and questions. I also think we need to start adding weekly periodics for some of our obscure pre-submits like this - I think these optional jobs are super easy to miss.
Asking Chai Bot about advise for periodics:
TRT has been actively discouraging new optional presubmit jobs because they "tend to rot."
The approach TRT members have endorsed is a dual strategy:
- Keep a lightweight optional presubmit (or a shim) so developers can still manually trigger it on PRs when relevant
- Add a periodic at a reasonable cadence (daily to weekly) that provides the actual ongoing regression signal
But given this is tech-preview at the moment, and you are just trying to get testing, we can do this as a follow up. Maybe as a larger effort of converting our pre-submits to weekly periodic (like vsphere/metal gateway api testing).
| requests: | ||
| cpu: 100m | ||
| - ref: tls-scanner-run | ||
| workflow: ipi-aws |
There was a problem hiding this comment.
this is a pretty minimal workflow - you won't get loki, must-gathers, etc..
any reason not to use openshift-e2e-aws-ovn-tls-13 which does adds the extra debugging tools? You'd remove you -ref: tls-13 as well since this already includes it.
There was a problem hiding this comment.
was the suggestion from claude, I can check again
There was a problem hiding this comment.
(I mean apparently other teams are doing this way)
There was a problem hiding this comment.
fixed here, will test with your suggestion
There was a problem hiding this comment.
changed to only openshift-e2e-aws-ovn and then I add tls-13 as a step after the first scan
| requests: | ||
| cpu: 100m | ||
| workflow: ingress-vsphere-static-metallb | ||
| - always_run: false |
There was a problem hiding this comment.
Future follow up: Might be good to eventually have a intermediate test for completeness. We are only testing modern via the tls-13 step, but intermediate is untested.
There was a problem hiding this comment.
yes, but this will need to be a different pipeline. I asked claude to check it, but we cannot alias two similar steps
There was a problem hiding this comment.
ok, I am doing some fancy workaround to run the tls scanner re-check
| cpu: 100m | ||
| workflow: ingress-vsphere-static-metallb | ||
| - always_run: false | ||
| as: tls-scanner-gatewayapi |
There was a problem hiding this comment.
nit up to you, but generally all of our jobs have aws/gcp/azure. Also, adding -modern makes it more distinguished incase we decide to add an -intermediate in the future.
| as: tls-scanner-gatewayapi | |
| as: tls-scanner-aws-gatewayapi-modern |
Not blocking - just a thought.
There was a problem hiding this comment.
I did it, and reverted it as we are aiming to do intermediate, then do TLS Adherence change, and run again
|
/pj-rehearse pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-gatewayapi |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Namespaces can host multiple unrelated components (e.g. Gateway API pods sharing openshift-ingress with the non-adherent router-default pods). Expose the scanner's existing --component-filter flag via a new env var so jobs can scope scans to a single component's pods.
Add an optional presubmit that provisions a TechPreview cluster, enables TLSAdherence, stands up a Gateway with a TLS listener, and scans it with tls-scanner to validate NE-2796 (OpenShift TLS profiles in Istio/Gateway API installation). Added to master and the release-4.23, release-5.0, and release-5.1 branches.
76bb84a to
bb01809
Compare
|
/pj-rehearse pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-gatewayapi |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/hold the test is not detecting the TLS port, I will check if I am missing some extra step |
|
/pj-rehearse pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-gatewayapi |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rikatz 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 |
|
[REHEARSALNOTIFIER]
A total of 239 jobs have been affected by this change. The above listing is non-exhaustive and limited to 25 jobs. A full list of affected jobs can be found here Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
/pj-rehearse pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-gatewayapi |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@rikatz: job(s): pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-gatewayapi either don't exist or were not found to be affected, and cannot be rehearsed |
|
/pj-rehearse pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-aws-gatewayapi |
1 similar comment
|
/pj-rehearse pull-ci-openshift-cluster-ingress-operator-master-tls-scanner-aws-gatewayapi |
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
1 similar comment
|
@rikatz: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@rikatz: The following tests 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. |
This PR adds a new set of jobs for cluster-ingress-operator to test TLS 1.3 adherence.
It expects a cluster with TLS 1.3 and Adherence strict, and will provision a new Gateway and validate if the gateway is adherent with the tls-scanner
Summary by CodeRabbit
tls-scannerwith strict TLS 1.3 adherence on AWS clusters.tls-scanner-toolbase image configuration.COMPONENT_FILTERsupport to target selected workloads during TLS scans.tls-scanner-recheckstep for repeated scans in multi-stage tests.