ci-config: add tls-scanner-run to fips-payload-scan for nightly-4.22 - #79624
redhat-chai-bot wants to merge 1 commit into
Conversation
Integrate the TLS scanner into the existing fips-payload-scan periodic job so that TLS compliance scanning runs alongside the existing FIPS checks (node-scan and art-fips) on the same cluster. Changes: - Add tls-scanner-tool base image from tls-scanner/tls-scanner - Add tls-scanner-run step ref after the existing fips-check steps The tls-scanner-run step deploys the TLS scanner as a privileged pod that enumerates all cluster pod TLS ports and validates their cipher suites and protocol versions.
|
@redhat-chai-bot: GitHub didn't allow me to request PR reviews from the following users: openshift/tls-scanner-maintainers. Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs. 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 kubernetes-sigs/prow repository. |
WalkthroughThis PR adds TLS scanner tooling to the OpenShift release CI configuration. A new ChangesTLS Scanner Tool Integration
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 12✅ Passed checks (12 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
openshift-ci
Bot
added
the
needs-ok-to-test
|
Hi @redhat-chai-bot. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: redhat-chai-bot 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/release/openshift-release-main__nightly-4.22.yaml`:
- Around line 90-93: You added a structural CI config entry (tls-scanner-tool
with name: tls-scanner, namespace: tls-scanner, tag: tls-scanner-tool) under
ci-operator/config; run the downstream artifact regeneration by executing make
update, review changes produced (e.g., generated files under the release/ or
ci-operator/jobs/ dirs), and commit those generated files alongside your config
change — if make update produces no changes, include the make output as evidence
in the PR to confirm it is a true no-op.
🪄 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: Enterprise
Run ID: 2ec35479-5338-4fe6-979c-997fa23e05f6
📒 Files selected for processing (1)
ci-operator/config/openshift/release/openshift-release-main__nightly-4.22.yaml
| tls-scanner-tool: | ||
| name: tls-scanner | ||
| namespace: tls-scanner | ||
| tag: tls-scanner-tool |
There was a problem hiding this comment.
Run and commit downstream CI artifact regeneration for this structural config change.
This PR adds a new base image and a new test ref, which are structural ci-operator/config changes. Please run make update and include any resulting generated artifact updates (or confirm it is a true no-op with evidence).
As per coding guidelines: “After modifying CI configuration files in ci-operator/config/, regenerate downstream artifacts by running make update”.
Also applies to: 2430-2430
🤖 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
`@ci-operator/config/openshift/release/openshift-release-main__nightly-4.22.yaml`
around lines 90 - 93, You added a structural CI config entry (tls-scanner-tool
with name: tls-scanner, namespace: tls-scanner, tag: tls-scanner-tool) under
ci-operator/config; run the downstream artifact regeneration by executing make
update, review changes produced (e.g., generated files under the release/ or
ci-operator/jobs/ dirs), and commit those generated files alongside your config
change — if make update produces no changes, include the make output as evidence
in the PR to confirm it is a true no-op.
|
[REHEARSALNOTIFIER]
A total of 282 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: |
|
Closing in favor of a revised approach that integrates the TLS scanner directly into the fips-check-node-scan step to run in parallel, per feedback. |
1 participant
Summary
Integrate the TLS scanner into the existing
fips-payload-scanperiodic job so that TLS compliance scanning runs alongside the existing FIPS checks on the same cluster.Changes
tls-scanner-toolbase image fromtls-scanner/tls-scanner:tls-scanner-tool(promoted by the openshift/tls-scanner CI)tls-scanner-runstep ref after the existingfips-check-node-scanandfips-check-art-fipsstepsThe existing fips-check steps are not modified. The TLS scanner runs as a third step on the same FIPS-enabled AWS cluster, deploying a privileged pod that enumerates all cluster pod TLS ports and validates their cipher suites and protocol versions.
Context
Requested in Slack thread.
/cc @openshift/tls-scanner-maintainers
Summary by CodeRabbit
This PR integrates TLS compliance scanning into the nightly 4.22 OpenShift CI pipeline by modifying the CI configuration for the openshift/release repository.
Changes to
ci-operator/config/openshift/release/openshift-release-main__nightly-4.22.yaml:Added a new base image reference (
tls-scanner-tool) that pulls the TLS scanner tool image from the openshift/tls-scanner repository. This image is automatically promoted by the tls-scanner CI pipeline and is used as a dependency for the test step.Extended the
fips-payload-scanperiodic job to include a new test step (tls-scanner-run) alongside the existing FIPS validation checks (fips-check-node-scanandfips-check-art-fips). This means TLS compliance validation will now execute as part of the yearly FIPS payload scan for the nightly-4.22 build.Practical impact: The nightly 4.22 release pipeline will now automatically validate TLS cipher suites and protocol versions on cluster pods during its periodic FIPS compliance checks, providing better coverage of security compliance requirements without modifying the existing FIPS check steps.