DPF: Add a load-kubeconfig step (2)#81564
Conversation
Signed-off-by: Jose Castillo Lema <josecastillolema@gmail.com>
gitleaks.version: 8.30.0
gitleaks.check-secrets: ENABLED
WalkthroughAdds a new CI step registry entry ChangesDPF hypervisor load-kubeconfig step
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CIStep as CI Step
participant Script as load-kubeconfig script
participant Hypervisor as Hypervisor host
participant SharedDir as SHARED_DIR
CIStep->>Script: Run dpf-hypervisor-load-kubeconfig-commands.sh
Script->>Script: Build SSH key from Vault secret
Script->>Hypervisor: SSH connectivity check
Script->>Hypervisor: scp last-openshift-dpf-dir.sh
Script->>Script: Source script, get LAST_OPENSHIFT_DPF
Script->>Hypervisor: scp kubeconfig.doca8
Script->>Script: Extract cluster name & server hostname
Script->>Hypervisor: SSH DNS resolve hostname to IP
Script->>Script: Patch kubeconfig server URL to IP, mark insecure
Script->>SharedDir: Copy patched kubeconfig
Script-->>CIStep: Log success
Compact metadata:
Suggested labels: ok-to-test, jira/valid-bug Suggested reviewers: josecastillolema, linoyaslan, szigmon, tsorya, wabouhamad 🐰 A hypervisor's secrets, once locked away, Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error)
✅ Passed checks (14 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 |
openshift-ci
Bot
added
the
approved
openshift-merge-bot
Bot
added
the
rehearsals-ack
|
[REHEARSALNOTIFIER] Note: If this PR includes changes to step registry files ( |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.sh`:
- Around line 55-63: The kubeconfig load script is logging sensitive cluster API
hostname/IP details; update the logging in the cluster resolution block to use
generic status messages instead of echoing CLUSTER_API_SERVER_HOSTNAME or
CLUSTER_API_IP. Keep the resolution logic in
dpf-hypervisor-load-kubeconfig-commands.sh intact, but change the status and
error messages around the SSH/getent lookup to avoid exposing endpoint details
in CI logs.
- Line 56: The hostname passed through the remote resolver in
dpf-hypervisor-load-kubeconfig-commands.sh should be quoted and narrowed to a
single IP so the captured server value stays valid. Update the CLUSTER_API_IP
assignment to safely pass CLUSTER_API_SERVER_HOSTNAME into the ssh command, and
ensure the resolver output is reduced to one address instead of returning
multiple lines. Use the existing CLUSTER_API_IP and CLUSTER_API_SERVER_HOSTNAME
references in that command block to locate and adjust the fix.
- Around line 32-39: The kubeconfig loader currently sources a copied remote
helper file in the CI pod, which can execute arbitrary content with mounted
credentials available. Update dpf-hypervisor-load-kubeconfig-commands.sh to
avoid cat/source of /tmp/last-openshift-dpf-dir.sh; instead, read only the
LAST_OPENSHIFT_DPF value from the file in a safe, non-executing way and use that
value directly in the existing echo/logging path. Keep the fix localized around
the scp and the LAST_OPENSHIFT_DPF handling block.
- Around line 71-74: The kubeconfig setup in the dpf hypervisor load script is
disabling TLS verification and removing certificate-authority-data, which should
be avoided. Update the cluster configuration in the oc config set-cluster flow
to keep verification enabled by using --tls-server-name with the original API
hostname, and stop unsetting clusters.${CLUSTER_NAME}.certificate-authority-data
so the existing CA data remains intact.
🪄 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: 7f73c8e3-c519-4e14-9b2f-b1545bed676a
📒 Files selected for processing (4)
ci-operator/step-registry/dpf/hypervisor/load-kubeconfig/OWNERSci-operator/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.shci-operator/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-ref.metadata.jsonci-operator/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-ref.yaml
| scp ${SSH_OPTS} root@${REMOTE_HOST}:${REMOTE_LAST_OPENSHIFT_DPF_DIR_LOCATION} /tmp | ||
|
|
||
| if [ -f /tmp/last-openshift-dpf-dir.sh ]; then | ||
| cat /tmp/last-openshift-dpf-dir.sh | ||
| set -a | ||
| source /tmp/last-openshift-dpf-dir.sh | ||
| set +a | ||
| echo "Last openshift-dpf dir is: '${LAST_OPENSHIFT_DPF}'" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Avoid sourcing remote content inside the CI pod.
Line 37 executes the copied hypervisor file locally with the pod’s mounted credentials available. Retrieve only the LAST_OPENSHIFT_DPF value, and avoid printing the whole helper file.
Safer pattern
-scp ${SSH_OPTS} root@${REMOTE_HOST}:${REMOTE_LAST_OPENSHIFT_DPF_DIR_LOCATION} /tmp
-
-if [ -f /tmp/last-openshift-dpf-dir.sh ]; then
- cat /tmp/last-openshift-dpf-dir.sh
- set -a
- source /tmp/last-openshift-dpf-dir.sh
- set +a
- echo "Last openshift-dpf dir is: '${LAST_OPENSHIFT_DPF}'"
-else
- echo "ERROR: Failed to find scp-ed file '/tmp/last-openshift-dpf-dir.sh'"
+LAST_OPENSHIFT_DPF="$(
+ ssh ${SSH_OPTS} root@${REMOTE_HOST} \
+ "set -euo pipefail; source '${REMOTE_LAST_OPENSHIFT_DPF_DIR_LOCATION}'; printf '%s' \"\${LAST_OPENSHIFT_DPF}\""
+)"
+
+if [[ -z "${LAST_OPENSHIFT_DPF}" ]]; then
+ echo "ERROR: Failed to determine last openshift-dpf install dir"
exit 1
fi
+echo "Last openshift-dpf dir located"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| scp ${SSH_OPTS} root@${REMOTE_HOST}:${REMOTE_LAST_OPENSHIFT_DPF_DIR_LOCATION} /tmp | |
| if [ -f /tmp/last-openshift-dpf-dir.sh ]; then | |
| cat /tmp/last-openshift-dpf-dir.sh | |
| set -a | |
| source /tmp/last-openshift-dpf-dir.sh | |
| set +a | |
| echo "Last openshift-dpf dir is: '${LAST_OPENSHIFT_DPF}'" | |
| LAST_OPENSHIFT_DPF="$( | |
| ssh ${SSH_OPTS} root@${REMOTE_HOST} \ | |
| "set -euo pipefail; source '${REMOTE_LAST_OPENSHIFT_DPF_DIR_LOCATION}'; printf '%s' \"\${LAST_OPENSHIFT_DPF}\"" | |
| )" | |
| if [[ -z "${LAST_OPENSHIFT_DPF}" ]]; then | |
| echo "ERROR: Failed to determine last openshift-dpf install dir" | |
| exit 1 | |
| fi | |
| echo "Last openshift-dpf dir located" |
🧰 Tools
🪛 ast-grep (0.44.1)
[warning] 34-34: Writing to or reading from a hardcoded, predictable path under /tmp is vulnerable to symlink and TOCTOU attacks: a local attacker can pre-create the file (or a symlink pointing elsewhere) and hijack or corrupt the contents. Generate a unique, unpredictable temporary file with mktemp instead, e.g. tmpfile="$(mktemp)" (or mktemp -d for directories) and reference "$tmpfile".
Context: /tmp/last-openshift-dpf-dir.sh
Note: [CWE-377] Insecure Temporary File.
(predictable-tmp-file-bash)
[warning] 36-36: Writing to or reading from a hardcoded, predictable path under /tmp is vulnerable to symlink and TOCTOU attacks: a local attacker can pre-create the file (or a symlink pointing elsewhere) and hijack or corrupt the contents. Generate a unique, unpredictable temporary file with mktemp instead, e.g. tmpfile="$(mktemp)" (or mktemp -d for directories) and reference "$tmpfile".
Context: /tmp/last-openshift-dpf-dir.sh
Note: [CWE-377] Insecure Temporary File.
(predictable-tmp-file-bash)
🪛 Shellcheck (0.11.0)
[info] 32-32: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 32-32: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 37-37: Not following: /tmp/last-openshift-dpf-dir.sh was not specified as input (see shellcheck -x).
(SC1091)
🤖 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/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.sh`
around lines 32 - 39, The kubeconfig loader currently sources a copied remote
helper file in the CI pod, which can execute arbitrary content with mounted
credentials available. Update dpf-hypervisor-load-kubeconfig-commands.sh to
avoid cat/source of /tmp/last-openshift-dpf-dir.sh; instead, read only the
LAST_OPENSHIFT_DPF value from the file in a safe, non-executing way and use that
value directly in the existing echo/logging path. Keep the fix localized around
the scp and the LAST_OPENSHIFT_DPF handling block.
| echo "Resolving cluster API server hostname '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor..." | ||
| CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")" | ||
|
|
||
| if [[ -z "${CLUSTER_API_IP}" ]]; then | ||
| echo "ERROR: Failed to resolve '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor" | ||
| exit 1 | ||
| fi | ||
|
|
||
| echo "Resolved '${CLUSTER_API_SERVER_HOSTNAME}' to '${CLUSTER_API_IP}'" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not log the cluster API endpoint details.
Lines 55, 59, and 63 expose the internal API hostname/IP in CI logs. Log generic resolution status instead. As per coding guidelines, “Step registry command scripts must avoid leaking sensitive information into CI logs: do not echo passwords, tokens, API keys, cluster URLs, or kubeconfig contents.”
Proposed fix
-echo "Resolving cluster API server hostname '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor..."
+echo "Resolving cluster API server hostname from the hypervisor..."
CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")"
if [[ -z "${CLUSTER_API_IP}" ]]; then
- echo "ERROR: Failed to resolve '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor"
+ echo "ERROR: Failed to resolve cluster API server hostname from the hypervisor"
exit 1
fi
-echo "Resolved '${CLUSTER_API_SERVER_HOSTNAME}' to '${CLUSTER_API_IP}'"
+echo "Resolved cluster API server hostname from the hypervisor"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo "Resolving cluster API server hostname '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor..." | |
| CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")" | |
| if [[ -z "${CLUSTER_API_IP}" ]]; then | |
| echo "ERROR: Failed to resolve '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor" | |
| exit 1 | |
| fi | |
| echo "Resolved '${CLUSTER_API_SERVER_HOSTNAME}' to '${CLUSTER_API_IP}'" | |
| echo "Resolving cluster API server hostname from the hypervisor..." | |
| CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")" | |
| if [[ -z "${CLUSTER_API_IP}" ]]; then | |
| echo "ERROR: Failed to resolve cluster API server hostname from the hypervisor" | |
| exit 1 | |
| fi | |
| echo "Resolved cluster API server hostname from the hypervisor" |
🧰 Tools
🪛 Shellcheck (0.11.0)
[info] 56-56: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 56-56: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 56-56: Note that, unescaped, this expands on the client side.
(SC2029)
🤖 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/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.sh`
around lines 55 - 63, The kubeconfig load script is logging sensitive cluster
API hostname/IP details; update the logging in the cluster resolution block to
use generic status messages instead of echoing CLUSTER_API_SERVER_HOSTNAME or
CLUSTER_API_IP. Keep the resolution logic in
dpf-hypervisor-load-kubeconfig-commands.sh intact, but change the status and
error messages around the SSH/getent lookup to avoid exposing endpoint details
in CI logs.
Source: Coding guidelines
| CLUSTER_NAME="$(oc --kubeconfig=/tmp/kubeconfig.doca8 config view -o jsonpath='{.clusters[0].name}')" | ||
| CLUSTER_API_SERVER_HOSTNAME="$(oc --kubeconfig=/tmp/kubeconfig.doca8 config view -o jsonpath='{.clusters[0].cluster.server}' | sed -E 's#https://([^:]+):.*#\1#')" | ||
| echo "Resolving cluster API server hostname '${CLUSTER_API_SERVER_HOSTNAME}' from the hypervisor..." | ||
| CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Quote the resolver input and select one address.
Line 56 interpolates a kubeconfig-derived hostname into a remote root shell and captures every getent result. A multi-record response can produce an invalid multiline server URL.
Proposed fix
-CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")"
+CLUSTER_API_HOSTNAME_QUOTED="$(printf '%q' "${CLUSTER_API_SERVER_HOSTNAME}")"
+CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent ahostsv4 ${CLUSTER_API_HOSTNAME_QUOTED} | awk 'NR == 1 { print \$1; exit }'")"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent hosts ${CLUSTER_API_SERVER_HOSTNAME} | awk '{print \$1}'")" | |
| CLUSTER_API_HOSTNAME_QUOTED="$(printf '%q' "${CLUSTER_API_SERVER_HOSTNAME}")" | |
| CLUSTER_API_IP="$(ssh ${SSH_OPTS} root@${REMOTE_HOST} "getent ahostsv4 ${CLUSTER_API_HOSTNAME_QUOTED} | awk 'NR == 1 { print \$1; exit }'")" |
🧰 Tools
🪛 Shellcheck (0.11.0)
[info] 56-56: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 56-56: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 56-56: Note that, unescaped, this expands on the client side.
(SC2029)
🤖 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/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.sh`
at line 56, The hostname passed through the remote resolver in
dpf-hypervisor-load-kubeconfig-commands.sh should be quoted and narrowed to a
single IP so the captured server value stays valid. Update the CLUSTER_API_IP
assignment to safely pass CLUSTER_API_SERVER_HOSTNAME into the ssh command, and
ensure the resolver output is reduced to one address instead of returning
multiple lines. Use the existing CLUSTER_API_IP and CLUSTER_API_SERVER_HOSTNAME
references in that command block to locate and adjust the fix.
Source: Linters/SAST tools
| oc --kubeconfig=/tmp/kubeconfig.doca8 config set-cluster "${CLUSTER_NAME}" \ | ||
| --server="https://${CLUSTER_API_IP}:6443" \ | ||
| --insecure-skip-tls-verify=true | ||
| oc --kubeconfig=/tmp/kubeconfig.doca8 config unset "clusters.${CLUSTER_NAME}.certificate-authority-data" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="ci-operator/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.sh"
echo "== File excerpt =="
cat -n "$file" | sed -n '1,180p'
echo
echo "== Search for related kubeconfig handling =="
rg -n "tls-server-name|insecure-skip-tls-verify|certificate-authority-data|set-cluster|load-kubeconfig" ci-operator/step-registry/dpf -S || true
echo
echo "== Search for API hostname source =="
rg -n "CLUSTER_API_SERVER_HOSTNAME|CLUSTER_API_IP|CLUSTER_NAME" ci-operator/step-registry/dpf -S || trueRepository: openshift/release
Length of output: 12803
🌐 Web query:
oc config set-cluster tls-server-name kubeconfig supported by oc or kubectl
💡 Result:
Yes, the --tls-server-name option is officially supported by both the OpenShift CLI (oc) and the Kubernetes CLI (kubectl) when using the config set-cluster command [1][2][3]. This option allows you to specify a custom server name for TLS certificate validation [1][4][5]. When provided, it overrides the default behavior where the CLI uses the hostname from the server URL to validate the TLS certificate [4][5]. Usage examples: To set the tls-server-name for a specific cluster entry in your kubeconfig: oc config set-cluster --tls-server-name= kubectl config set-cluster --tls-server-name= This functionality was added to support TLS Server Name Indication (SNI) overrides in kubeconfig files, which is useful in environments where the hostname used to connect to the cluster differs from the name presented in the cluster's TLS certificate [6][7][3]. The parameter is stored directly in the cluster configuration within the kubeconfig file [5][8].
Citations:
- 1: https://manpages.opensuse.org/Tumbleweed/oc/oc-config-set-cluster.1.en.html
- 2: https://man.archlinux.org/man/kubectl-config-set-cluster.1.en
- 3: https://github.com/kubernetes/kubernetes/pull/88769/files
- 4: https://manpages.opensuse.org/Tumbleweed/oc/oc-config-set.1.en.html
- 5: https://kubernetes.io/docs/reference/config-api/kubeconfig.v1/
- 6: Support TLS Server Name overrides in kubeconfig file kubernetes/kubernetes#82056
- 7: Support TLS Server Name overrides in kubeconfig file kubernetes/kubernetes#80596
- 8: https://kubernetes.ltd/docs/reference/config-api/kubeconfig.v1/
🌐 Web query:
kubeconfig tls-server-name field oc config set-cluster help
💡 Result:
The tls-server-name field in a kubeconfig file is used to specify an alternative hostname for TLS certificate verification [1][2][3]. When a client connects to a Kubernetes API server, it typically validates the server's certificate against the hostname used to contact the server (the address specified in the cluster server field) [2][3]. By setting tls-server-name, you instruct the client to instead verify the certificate against this specified name, which is useful in environments where the API server is accessed via a proxy or load balancer whose hostname differs from the one in the certificate's Common Name (CN) or Subject Alternative Name (SAN) [4][3]. You can set this field using the oc config set-cluster command as follows: oc config set-cluster <cluster_nickname> --tls-server-name=<hostname_to_verify> If the field is left empty or not provided, the client defaults to using the hostname from the cluster's server URL for verification [5][2]. This flag is functionally identical to the kubectl config set-cluster command [6][7].
Citations:
- 1: https://kubernetes.io/docs/reference/config-api/kubeconfig.v1/
- 2: https://kubernetes.ltd/docs/reference/config-api/kubeconfig.v1/
- 3: Support tls-server-name field from kubeconfig for SNI kubernetes-client/java#4402
- 4: Support TLS Server Name overrides in kubeconfig file kubernetes/kubernetes#80596
- 5: https://manpages.opensuse.org/Tumbleweed/oc/oc-config-set.1.en.html
- 6: https://manpages.opensuse.org/Tumbleweed/oc/oc-config-set-cluster.1.en.html
- 7: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_config/kubectl_config_set-cluster/
🌐 Web query:
kubectl config set-cluster --tls-server-name documentation
💡 Result:
The --tls-server-name flag for the kubectl config set-cluster command is used to specify a custom server name for server certificate validation when connecting to a Kubernetes cluster [1][2][3]. By default, when kubectl connects to a cluster, it uses the hostname from the server URL to validate the TLS certificate provided by the server [2]. If you need to use a different name for validation—for example, if the server certificate is issued to a specific Subject Alternative Name (SAN) that does not match the server's public URL—you can use this flag to override that behavior [1][3]. Usage syntax: kubectl config set-cluster [NAME] --tls-server-name=[SERVER_NAME] Example: kubectl config set-cluster my-cluster --tls-server-name=example.com If the flag is not provided, kubectl falls back to using the hostname found in the cluster's server URL [2].
Citations:
- 1: https://man.archlinux.org/man/kubectl-config-set-cluster.1.en.txt
- 2: https://manpages.opensuse.org/Leap-15.6/kubernetes1.18-client-common/kubectl-config-set-cluster.1.en.html
- 3: https://kubernetes.co.id/en/docs/reference/kubectl/generated/kubectl_config/kubectl_config_set-cluster/
Keep kubeconfig verification enabled. oc config set-cluster supports --tls-server-name, so this can use the original API hostname for certificate validation and leave certificate-authority-data intact instead of setting --insecure-skip-tls-verify=true.
🤖 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/step-registry/dpf/hypervisor/load-kubeconfig/dpf-hypervisor-load-kubeconfig-commands.sh`
around lines 71 - 74, The kubeconfig setup in the dpf hypervisor load script is
disabling TLS verification and removing certificate-authority-data, which should
be avoided. Update the cluster configuration in the oc config set-cluster flow
to keep verification enabled by using --tls-server-name with the original API
hostname, and stop unsetting clusters.${CLUSTER_NAME}.certificate-authority-data
so the existing CA data remains intact.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: josecastillolema, linoyaslan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@josecastillolema: all tests passed! 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. |
2 participants
It would be better to run the conformance tests directly from Prow than from the bastion node.
This step will allow this pattern (even for other DPF tests, like the networking one, etc.).
Summary by CodeRabbit
Added a new DPF hypervisor
load-kubeconfigCI step so OpenShift CI can fetch and prepare a usable kubeconfig directly from Prow instead of relying on the bastion workflow.In practical terms, this updates the DPF CI infrastructure to:
openshift-dpfinstall directory,This lays the groundwork for running DPF conformance and similar downstream tests directly from the CI environment.