NO-JIRA: Add optional TLS scanner CI job for cert-manager-operator - #82715
NO-JIRA: Add optional TLS scanner CI job for cert-manager-operator#82715arun717 wants to merge 1 commit into
Conversation
Add a manually triggered tls-scanner presubmit on master that installs the operator, deploys the CertManager operand, and runs tls-scanner-run against the cert-manager namespaces.
WalkthroughThe cert-manager operator CI configuration adds a ChangesTLS scanner CI coverage
Estimated code review effort: 3 (Moderate) | ~15–30 minutes Sequence Diagram(s)sequenceDiagram
participant Workflow as tls-scanner workflow
participant AWS as AWS cluster
participant Operator as cert-manager operator
participant Scanner as TLS scanner tests
Workflow->>AWS: Configure AWS cluster and install operator bundle
AWS->>Operator: Deploy cert-manager operand
Operator-->>Workflow: Report deployment readiness
Workflow->>Scanner: Run TLS 1.3 and tls-scanner tests
Possibly related PRs
Suggested reviewers: Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (2 errors)
✅ Passed checks (13 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: arun717 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]
Prior to this PR being merged, you will need to either run and acknowledge or opt to skip these rehearsals. Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, 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: 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/cert-manager-operator/openshift-cert-manager-operator-master.yaml`:
- Around line 468-469: The workflow references tls-scanner-run without
TLS_SCANNER_CLUSTER_LABEL, causing the scanner to use its privileged host-mode
configuration. Update this workflow to select a supported restricted scanner
mode for standard AWS clusters by configuring the required cluster label, or
remove the scanner reference until the shared step supports restricted
execution; do not enable host mode without documented approval.
- Around line 460-463: Update the operand-wait sequence after the “Waiting for
cert-manager operand deployments...” message to first wait for creation of the
cert-manager namespace and each deployment using oc wait --for=create, then
retain the existing --for=condition=Available checks for cert-manager,
cert-manager-webhook, and cert-manager-cainjector.
🪄 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: a60eeb49-e9b2-441e-827c-909c4e928439
⛔ Files ignored due to path filters (1)
ci-operator/jobs/openshift/cert-manager-operator/openshift-cert-manager-operator-master-presubmits.yamlis excluded by!ci-operator/jobs/**
📒 Files selected for processing (1)
ci-operator/config/openshift/cert-manager-operator/openshift-cert-manager-operator-master.yaml
| echo "Waiting for cert-manager operand deployments..." | ||
| oc wait --for=condition=Available -n cert-manager deployment/cert-manager --timeout=5m | ||
| oc wait --for=condition=Available -n cert-manager deployment/cert-manager-webhook --timeout=5m | ||
| oc wait --for=condition=Available -n cert-manager deployment/cert-manager-cainjector --timeout=5m |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
file="ci-operator/config/openshift/cert-manager-operator/openshift-cert-manager-operator-master.yaml"
printf '%s\n' '--- target file ---'
sed -n '420,490p' "$file"
printf '%s\n' '--- related CertManager submission and wait commands ---'
rg -n -C 8 'CertManager|cert-manager|oc wait|tls-scanner-run' "$file"
printf '%s\n' '--- scanner definitions and references ---'
rg -n -C 10 'tls-scanner-run|tls-scanner|hostNetwork|hostPID|privileged|allowPrivilegeEscalation|securityContext' ci-operator/config openshift 2>/dev/null | head -300
printf '%s\n' '--- cert-manager operator source references ---'
rg -n -C 5 'cert-manager operand namespace|operand namespace|namespace.*cert-manager|deployment.*cert-manager' . --glob '!vendor/**' --glob '!node_modules/**' | head -300Repository: openshift/release
Length of output: 1920
🌐 Web query:
openshift/release openshift-cert-manager-operator-master.yaml lines 460 oc wait cert-manager tls-scanner-run
💡 Result:
The command oc wait cert-manager tls-scanner-run is not a standard OpenShift or cert-manager command [1][2][3]. It is part of a custom CI/CD automation workflow within the OpenShift release repository [4]. The tls-scanner is an official OpenShift tool used to audit Kubernetes/OpenShift clusters for TLS compliance, including TLS version, cipher suite, and post-quantum (ML-KEM) readiness [5][6][7]. The scanner is designed to be deployed as a Kubernetes Job [8][9][5]. In OpenShift CI pipelines, specific steps are defined to run this scanner and wait for the results [4]. The syntax oc wait... tls-scanner-run suggests a command intended to wait for a specific Kubernetes resource (likely a Job or Pod) labeled or named in relation to a tls-scanner execution [8][9]. In the context of CI automation, such commands typically use kubectl wait --for=condition=... to ensure the scanner Job completes before proceeding with log collection or analysis [8][9]. If you encountered this in a specific openshift/release configuration file, it is an environment-specific directive used to orchestrate end-to-end (E2E) testing of TLS configurations [4]. For standard operations, users should refer to the official repository for running the tls-scanner manually using its provided deploy scripts rather than relying on CI-specific wait commands [5][6].
Citations:
- 1: https://github.com/openshift/cert-manager-operator
- 2: https://docs.redhat.com/en/documentation/red_hat_openshift_service_mesh/3.1/html/installing/ossm-cert-manager
- 3: https://docs.kuberocketci.io/docs/operator-guide/infrastructure-providers/okd/ssl-automation-okd
- 4: Add TLS Scanner Component #71526
- 5: https://github.com/openshift/tls-scanner
- 6: https://pkg.go.dev/github.com/openshift/tls-scanner
- 7: feat: add tls-compliance skill for Kubernetes TLS hardening and PQC readiness RedHatProductSecurity/prodsec-skills#18
- 8: https://github.com/damdo/tls-scanner
- 9: https://github.com/smith-xyz/tls-scanner
🏁 Script executed:
#!/bin/bash
set -eu
base="https://raw.githubusercontent.com/openshift/release/master/ci-operator/config/openshift/cert-manager-operator/openshift-cert-manager-operator-master.yaml"
tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT
curl -fsSL --max-time 20 "$base" -o "$tmp"
printf '%s\n' '--- target lines ---'
nl -ba "$tmp" | sed -n '430,485p'
printf '%s\n' '--- all relevant commands ---'
rg -n -C 8 'CertManager|cert-manager|oc wait|tls-scanner-run' "$tmp"
printf '%s\n' '--- current file metadata ---'
curl -fsSL --max-time 20 "https://api.github.com/repos/openshift/release/contents/ci-operator/config/openshift/cert-manager-operator/openshift-cert-manager-operator-master.yaml" |
jq -r '{name,sha,download_url}'
printf '%s\n' '--- PR reference ---'
curl -fsSL --max-time 20 "https://api.github.com/repos/openshift/release/pulls/71526" |
jq -r '{state,title,merged_at,head:.head.sha,base:.base.sha}'Repository: openshift/release
Length of output: 1920
🌐 Web query:
site:github.com/openshift/release/blob/master/ci-operator/config/openshift/cert-manager-operator/openshift-cert-manager-operator-master.yaml "oc wait --for=condition=Available"
💡 Result:
The file contains the command at line 1087:
oc wait --for condition=Available -n cert-manager-operator deployment cert-manager-operator-controller-managerNote: the current GitHub path uses main, not master. [1]
🌐 Web query:
site:github.com/openshift/cert-manager-operator "cert-manager" namespace deployment reconciliation
💡 Result:
In the context of cert-manager, namespace deployment reconciliation refers to how the cert-manager components (the controller, webhook, and CA injector) are managed and maintained within a Kubernetes cluster. For most standard installations using the upstream Helm charts, reconciliation is handled by the Helm release controller. The cert-manager installation is typically defined as a set of deployments and supporting resources within a designated namespace (usually cert-manager). When deploying via an operator (such as the OpenShift Cert-Manager Operator), reconciliation is performed by the operator's controllers [1][2]. These controllers observe the state of a custom resource (e.g., a CertManager object) and ensure that the underlying operand deployments (controller, webhook, CA injector) match the desired configuration [1][3]. Key aspects of this process include: 1. Controller Reconciliation: The operator uses specific controllers to manage the deployment manifests for the operand [1][4]. These controllers monitor the lifecycle of these deployments, ensuring they remain in the desired state [3]. 2. Resource Ownership: By design, some operators, such as the OpenShift variant, do not set ownerReferences on all resources created by the operator to prevent automatic garbage collection that could cause unintended service disruptions or certificate unavailability [5]. 3. Configuration Overrides: Reconciliation logic often includes support for passing custom arguments or environment variables to the operand pods, which can be managed via the operator's custom resource (e.g., using an unsupportedConfigOverrides or similar spec field) [1][6][4]. 4. Status Tracking: The operator monitors the generation of the operand deployments to verify their status and ensure successful reconciliation [3]. If you are encountering issues with reconciliation, check the logs of the managing operator or the status of the relevant deployment resources in the target namespace [3]. If using Helm, check the status of the Helm release.
Citations:
- 1: https://github.com/openshift/cert-manager-operator
- 2: https://github.com/openshift/cert-manager-operator/tree/4ce10b86d1583a8ea66775611fb61526528b46b7
- 3: openshift/cert-manager-operator@81a60fb
- 4: https://github.com/openshift/cert-manager-operator/tree/0431e1878087c139b41051e8add803e06ec72efe
- 5: Missing ownerReferences on resources created by operator cert-manager-operator#307
- 6: openshift/cert-manager-operator@c49fd4e
🌐 Web query:
kubectl wait --for=create documentation oc wait --for=create
💡 Result:
The --for=create option is a valid and documented feature for the kubectl wait command [1][2]. It allows users to pause execution until a specified resource is created [1][3]. kubectl wait --for=create When you run kubectl wait with --for=create, the command monitors the API server for the existence of the specified resource [1][3]. If the resource does not yet exist, the command will wait until it is created or until the --timeout period expires [1][3]. It is commonly used in scripting and automation to ensure that a resource (such as a Secret, ConfigMap, or CRD) is available before proceeding with subsequent operations [1][3]. If multiple conditions are provided with --for, the --for=create condition is always evaluated first [1][3]. oc wait --for=create The OpenShift CLI (oc) is a wrapper around the Kubernetes CLI (kubectl) and inherits its command functionality [4][5]. Because oc utilizes the underlying kubectl binary for many operations, the --for=create option is also available when using the oc wait command, provided the version of the OpenShift CLI is recent enough to include the corresponding upstream Kubernetes feature. Summary of Behavior: - Purpose: Wait for a resource to exist [1][3]. - Syntax: kubectl wait --for=create <resource_type>/<resource_name> --timeout= [1][3]. - Priority: If combined with other --for flags (e.g., --for=condition=Ready), --for=create is processed first [1][3]. - Compatibility: Supported in modern versions of kubectl; functionality is mirrored in oc [1][4].
Citations:
- 1: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_wait/
- 2: https://github.com/kubernetes/kubectl/blob/master/pkg/cmd/wait/wait.go
- 3: https://man.archlinux.org/man/extra/kubectl/kubectl-wait.1.en
- 4: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/cli_tools/openshift-cli-oc
- 5: https://docs.okd.io/latest/cli_reference/openshift_cli/developer-cli-commands.html
🌐 Web query:
github openshift/release pull 71526 cert-manager operator cert-manager-webhook cert-manager-cainjector
💡 Result:
The GitHub pull request openshift/release #71526, merged on February 6, 2026, is unrelated to the cert-manager operator components [1]. Its purpose was to add an OpenShift TLS scanner CI component to the repository to verify TLS configuration compliance (e.g., minimum TLS versions and ciphersuites) across OpenShift clusters [1]. Regarding the cert-manager operator components you mentioned: cert-manager operator: This is the Red Hat OpenShift operator responsible for deploying and managing the cert-manager lifecycle on OpenShift clusters [2][3]. cert-manager-webhook: A component of the cert-manager installation on OpenShift that provides admission control services for cert-manager custom resources [2][3]. It validates and mutates incoming requests [3]. cert-manager-cainjector: A component responsible for automatically injecting CA bundles into various Kubernetes resources, such as ValidatingWebhookConfigurations, MutatingWebhookConfigurations, CustomResourceDefinitions, and APIServices [4]. This ensures that the Kubernetes API server can trust the serving certificates of these components [4]. These components work together to provide automated certificate management within an OpenShift environment [2][3]. Detailed technical documentation for their configuration and management can be found in the official Red Hat OpenShift product documentation [2][3].
Citations:
- 1: Add TLS Scanner Component #71526
- 2: https://docs.redhat.com/en/documentation/openshift_container_platform/4.13/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
- 3: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
- 4: https://cert-manager.io/v1.15-docs/concepts/ca-injector/
🌐 Web query:
site:github.com/openshift/release "Waiting for cert-manager operand deployments"
💡 Result:
The message "Waiting for cert-manager operand deployments" typically appears during the automated installation or configuration of cert-manager within OpenShift environments, particularly within CI/CD pipelines (such as those managed by openshift/release) [1][2][3]. This message indicates that the cert-manager operator is in the process of deploying its required operands—the actual cert-manager controller, webhook, and CA injector components—but they have not yet reached a ready state [4]. Troubleshooting Steps: 1. Check Operator Status: Use the OpenShift CLI to inspect the status of the cert-manager operator and the corresponding operand deployment. oc get certmanager -n cert-manager oc get pods -n cert-manager 2. Review Controller Logs: If the operands remain in a "Waiting" or "Pending" state, examine the logs of the cert-manager operator pod for specific configuration errors, image pull issues, or resource constraints. 3. Verify Dependencies: Ensure that any required dependencies, such as the Cluster Controller Manager (CCM) or specific node-level initializations, have completed successfully, as failures in these areas can prevent operand pods from scheduling or initializing correctly [4]. 4. Check Cluster Operators: Run oc get clusteroperators to ensure all core platform operators are stable. Intermittent issues with the Kubernetes API server or node readiness can occasionally cause deployment cycles to stall [5][6]. In automated pipeline contexts, this status is often part of a sequence that waits for cluster readiness [7][5]. If you encounter this in a managed environment, ensure that you have sufficient cluster resources and that your network policies allow the operator to communicate with the Kubernetes API [8][4].
Citations:
- 1: 96a5a4b
- 2: 32def63
- 3: 42b4b60
- 4: https://github.com/openshift/release/blob/main/ci-operator/step-registry/platform-external/cluster/wait-for/ccm-nodes-initialized/platform-external-cluster-wait-for-ccm-nodes-initialized-ref.yaml
- 5: Add another wait for install and improve wipe step #80803
- 6: Add a sleep before re-checking clusteroperators #23419
- 7: https://github.com/openshift/release/blob/main/ci-operator/step-registry/platform-external/cluster/wait-for/install-complete/platform-external-cluster-wait-for-install-complete-chain.yaml
- 8: https://github.com/openshift/release/blob/main/ci-operator/step-registry/platform-external/cluster/wait-for/api-bootstrap/platform-external-cluster-wait-for-api-bootstrap-ref.yaml
🌐 Web query:
site:github.com/openshift/cert-manager-operator "cert-manager-cainjector" "namespace"
💡 Result:
The namespace for the cert-manager-cainjector deployment depends on how cert-manager is installed: 1. Standard Upstream Installation: By default, cert-manager is typically installed in the cert-manager namespace [1][2]. The cert-manager-cainjector component is deployed within this same operand namespace. 2. OpenShift Operator Managed Installation: If you are using the Cert Manager Operator on OpenShift, the operator itself resides in the cert-manager-operator namespace, while the managed operand (which includes cert-manager-cainjector) is deployed into the cert-manager namespace [1][3]. In this specific implementation, these namespaces are hardcoded and not intended to be changed [1][3]. If you need to verify where cainjector is running in your specific cluster, you can use the following kubectl command: kubectl get deployment -n -l app=cainjector Replace with the namespace where you installed cert-manager (commonly cert-manager).
Citations:
- 1: https://github.com/openshift/cert-manager-operator/blob/master/README.md
- 2: https://github.com/openshift/cert-manager-operator
- 3: https://github.com/openshift/cert-manager-operator/blob/ae53ee1a5c3a515497f70435e9aaedba0a118f0d/README.md
🌐 Web query:
site:github.com/openshift/release/commit/96a5a4b5e56df3c12b3237331b481e07270fb346 cert-manager
💡 Result:
I am unable to provide a detailed explanation of cert-manager because my search results did not return information defining or describing the project. The available results only contain technical logs related to image registry updates for cert-manager within a specific OpenShift repository [1].
Citations:
- 1: 96a5a4b
🌐 Web query:
site:github.com/openshift/release/commit/32def638220ead749e1ac6e6cbb523e674f9f00a "Waiting for cert-manager operand deployments"
💡 Result:
There is no specific, widely documented error message phrased exactly as Waiting for cert-manager operand deployments in official cert-manager or OpenShift documentation. This message appears to be a specific status string generated by a custom operator or an internal management controller rather than a standard cert-manager component. If you encounter a status indicating that an operator is waiting for operand deployments, you should perform the following general troubleshooting steps to identify why the managed resources are not reconciling: 1. Check the Operator Status: Verify the health and status of the cert-manager operator itself by inspecting its logs and the status of its custom resource definitions (CRDs). kubectl get pods -n kubectl logs -l name=cert-manager-operator -n 2. Inspect Managed Resources: The operator is likely waiting for deployments such as cert-manager-controller, cert-manager-cainjector, or cert-manager-webhook to become available. Check the status of these pods: kubectl get pods -n 3. Describe the Operator Resource: If the operator is managed by a custom resource (e.g., a CertManager Custom Resource), describe that object to see if there are events or status updates explaining the delay. kubectl describe certmanager -n 4. Check Cluster Events: Review cluster-wide events to identify resource constraints, such as pending pods due to insufficient CPU/memory or image pull errors. kubectl get events -A --sort-by='.lastTimestamp' If this is happening in an OpenShift environment, ensure that the operator has the necessary permissions and that all required service accounts are correctly configured, as indicated by standard deployment manifests [1].
Citations:
- 1: 32def63
🌐 Web query:
site:github.com/openshift/release/commit/42b4b607cb876c1a1952065d434cb186ba45f35b cert-manager
💡 Result:
cert-manager is an open-source project that runs within a Kubernetes cluster to automate the management, issuance, and renewal of TLS/SSL certificates [1]. It ensures that certificates are valid and up-to-date by integrating with various certificate authorities [1]. Key aspects of cert-manager include: Functionality: It automates the process of obtaining certificates from certificate authorities (such as Let's Encrypt) and managing their lifecycle, which includes automatic renewal [1][2]. Integration: It is commonly used with Kubernetes Ingress controllers to secure web traffic, enabling HTTPS for applications hosted in a cluster [3][1][2]. Core Components: cert-manager utilizes Custom Resource Definitions (CRDs) to manage its operations [2]. The primary resources used to configure and control the system are Issuers (which define how certificates are requested and issued) and Certificates (which represent the requested certificate) [2]. Installation: The project is typically deployed into a Kubernetes cluster using tools like Helm or standard Kubernetes manifests [2]. For further details, implementation guides, and conceptual documentation, you can refer to the official website at cert-manager.io [4][5][3].
Citations:
- 1: https://cert-manager.io/v1.10-docs/getting-started/
- 2: https://cert-manager.io/docs/tutorials/acme/nginx-ingress/
- 3: https://cert-manager.io/v1.14-docs/getting-started/
- 4: https://cert-manager.io/v1.10-docs/concepts/
- 5: https://cert-manager.io/v1.15-docs/reference/tls-terminology/
🌐 Web query:
OpenShift cert-manager operator creates cert-manager namespace CertManager custom resource
💡 Result:
The cert-manager Operator for Red Hat OpenShift automatically manages the cert-manager operand and its associated resources. Key details regarding the namespace and custom resource creation include: 1. Automatic Resource Creation: The operator automatically deploys a cluster-scoped CertManager custom resource (CR) named cluster if it is missing, using default values [1][2]. This CR is used to configure and customize the cert-manager components (such as the controller, CA injector, and webhook) [3][4]. 2. Namespaces: The operator itself typically runs in the cert-manager-operator namespace (or openshift-cert-manager-operator in some versions), while the cert-manager operand (the actual cert-manager components) is deployed into a hardcoded cert-manager namespace [1][5][2]. These namespaces are created automatically if they do not already exist when the operator is installed [5][6]. In summary, you do not need to manually create the cert-manager namespace or the CertManager custom resource; the operator handles both tasks automatically upon installation [1][5][2]. You can subsequently edit the cluster-named CertManager resource to apply custom configurations or overrides [7][3].
Citations:
- 1: https://github.com/openshift/cert-manager-operator/blob/master/README.md
- 2: https://github.com/openshift/cert-manager-operator
- 3: https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
- 4: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
- 5: https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
- 6: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
- 7: https://docs.redhat.com/en/documentation/openshift_container_platform/4.12/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift
Wait for operand resources to be created before checking availability.
The operator creates the cert-manager namespace and deployments asynchronously. oc wait --for=condition=Available can fail immediately when a resource does not exist. Wait for the namespace and deployments with --for=create before checking Available.
🤖 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/cert-manager-operator/openshift-cert-manager-operator-master.yaml`
around lines 460 - 463, Update the operand-wait sequence after the “Waiting for
cert-manager operand deployments...” message to first wait for creation of the
cert-manager namespace and each deployment using oc wait --for=create, then
retain the existing --for=condition=Available checks for cert-manager,
cert-manager-webhook, and cert-manager-cainjector.
Source: MCP tools
| - ref: tls-13 | ||
| - ref: tls-scanner-run |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
Do not use the scanner’s default privileged host mode without an explicit security decision.
This workflow does not set TLS_SCANNER_CLUSTER_LABEL. The shared tls-scanner-run step therefore uses its default host-mode path, which creates a pod with privileged: true, hostNetwork: true, hostPID: true, and runAsUser: 0. It also grants cluster-admin to the scanner service account. OO_SECURITY_CONTEXT: restricted only affects operator installation; it does not restrict this scanner pod. (raw.githubusercontent.com)
Use a supported restricted scanner mode for standard AWS clusters, or update the shared step before adding this workflow. If host mode is required, document and approve the exception.
#!/usr/bin/env bash
set -euo pipefail
fd -t f -g 'tls-scanner-run-ref.yaml' -g 'tls-scanner-run-commands.sh' \
-x rg -n -C 4 \
'TLS_SCANNER_CLUSTER_LABEL|privileged: true|hostNetwork|hostPID|runAsUser|cluster-admin|allowPrivilegeEscalation|runAsNonRoot|capabilities'As per path instructions, this YAML review must flag privileged: true, hostPID, hostNetwork, and root execution.
🤖 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/cert-manager-operator/openshift-cert-manager-operator-master.yaml`
around lines 468 - 469, The workflow references tls-scanner-run without
TLS_SCANNER_CLUSTER_LABEL, causing the scanner to use its privileged host-mode
configuration. Update this workflow to select a supported restricted scanner
mode for standard AWS clusters by configuring the required cluster label, or
remove the scanner reference until the shared step supports restricted
execution; do not enable host mode without documented approval.
|
/pj-rehearse pull-ci-openshift-cert-manager-operator-master-tls-scanner |
|
@arun717: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
arun717
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@arun717: This pull request explicitly references no jira issue. 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. |
|
@arun717: 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. |
|
/pj-rehearse pull-ci-openshift-cert-manager-operator-master-tls-scanner |
|
@arun717: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
2 participants
Summary
tls-scannerpresubmit foropenshift/cert-manager-operatoronmaster.CertManageroperand, enables TLS 1.3 strict adherence, and runstls-scanner-runagainst thecert-manager-operatorandcert-managernamespaces.Test plan
/pj-rehearse listconfirmspull-ci-openshift-cert-manager-operator-master-tls-scanneris rehearsable/pj-rehearse pull-ci-openshift-cert-manager-operator-master-tls-scannersucceedsmaster,/test tls-scannercan trigger the job after this mergesSummary by CodeRabbit
tls-scannerpresubmit job foropenshift/cert-manager-operatoronmaster.CertManageroperand, and waits for deployments.tls-scanner-runagainst thecert-manager-operatorandcert-managernamespaces.tls-scanner-toolbase image required by the workflow.