STOR-2922: Rebase to upstream v1.20.1 for OCP 5.0#62
Open
dfajmon wants to merge 27 commits into
Open
Conversation
1e81e752e Merge pull request kubernetes-csi#293 from andyzhangx/patch-9 4dc185057 fix: upgrade to go1.25.7 to fix CVE-2025-61727 git-subtree-dir: release-tools git-subtree-split: 1e81e752e87e027311be882279eac9e292705aa5
…si-release-tools-1.20
…ease-tools-1.20 [release-1.20] chore: Update csi release tools
fix golint
…t/cherry-pick-1020-to-release-1.20 [release-1.20] chore: validate mount path
…ar5-1.20 [release-1.20] chore: upgrade CSI sidecar image versions
fix fix test: fix trivy failure fix fix
…t/cherry-pick-1026-to-release-1.20 [release-1.20] test: upgrade to golint2
…t/cherry-pick-1025-to-release-1.20 [release-1.20] fix: CVE-2026-24051
119a53c3c Merge pull request kubernetes-csi#294 from andyzhangx/patch-10 7c9aa9ba3 fix: upgrade to go1.25.7 to fix CVE-2026-25679 git-subtree-dir: release-tools git-subtree-split: 119a53c3cce0c04fd422514252ea62c6ff4e3548
…t/cherry-pick-1029-to-release-1.20 [release-1.20] test: fix CVE-2026-25679 in trivy action
…t/cherry-pick-1030-to-release-1.20 [release-1.20] fix: Update csi release tools to fix CVEs
…ak-win fix: SmbGlobalMapping leak due to wrong driverGlobalMountPath on Windows
doc: cut v1.20.1 release
openshift-ci-robot
added
the
jira/valid-reference
|
@dfajmon: This pull request references STOR-2922 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 only the "5.0.0" version, but multiple target versions were 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. |
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dfajmon 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 |
openshift-ci
Bot
added
the
approved
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (77)
📒 Files selected for processing (1)
WalkthroughThis PR releases SMB CSI driver v1.20.1 by adding path traversal validation to volume source and subDir fields, creating a versioned Helm chart and Kubernetes manifests, bumping container image tags, updating Go toolchain to 1.25.0, and providing installation documentation with updated compatibility information. ChangesSMB CSI v1.20.1 Release
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested reviewers
Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error, 2 warnings)
✅ Passed checks (12 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-ci
Bot
added
do-not-merge/invalid-owners-file
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
deploy/csi-smb-node-windows.yaml (1)
36-36:⚠️ Potential issue | 🟠 Major | ⚡ Quick winInconsistent sidecar versions in Windows node DaemonSet vs Linux node and Helm values.
The Windows node DaemonSet has livenessprobe (v2.16.0) and csi-node-driver-registrar (v2.15.0), but the Linux node DaemonSet and Helm values use v2.18.0 and v2.16.0 respectively. All deployment artifacts for a release should use consistent sidecar versions to ensure parity across platforms and avoid support fragmentation.
🔧 Proposed fix: Update Windows node sidecar versions to match Linux node and Helm values
- name: liveness-probe - image: registry.k8s.io/sig-storage/livenessprobe:v2.16.0 + image: registry.k8s.io/sig-storage/livenessprobe:v2.18.0 imagePullPolicy: IfNotPresent command: - "csi-node-driver-registrar.exe"- name: node-driver-registrar - image: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.15.0 + image: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.16.0 imagePullPolicy: IfNotPresentAlso applies to: 56-56
🤖 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 `@deploy/csi-smb-node-windows.yaml` at line 36, Update the Windows node DaemonSet sidecar versions to match the Linux node DaemonSet and Helm values for consistency across platforms. Change the livenessprobe image version from v2.16.0 to v2.18.0 at line 36, and update the csi-node-driver-registrar image version from v2.15.0 to v2.16.0 at line 56. These changes ensure version parity between Windows and Linux deployments as specified in the Helm values.hack/verify-helm-chart-index.sh (1)
29-37:⚠️ Potential issue | 🟠 Major | ⚡ Quick winRestore fail-fast verification and fix branch-agnostic local path mapping.
Line 36 suppresses real verification failures. Combined with Line 29’s
master-specific path rewrite, URLs onrelease-1.20won’t map to valid local files, and the script can pass when checks actually fail.Proposed fix
- local=${PKG_ROOT}${url#*master} + local_path="${PKG_ROOT}$(echo "$url" | sed -E 's#^https://raw\.githubusercontent\.com/kubernetes-csi/csi-driver-smb/[^/]+##')" - echo "check whether $local exists" - if [ -f "$local" ] + echo "check whether $local_path exists" + if [ -f "$local_path" ] then - echo "$local exists" + echo "$local_path exists" else - echo "$local does not exist" - `#exit` 1 + echo "$local_path does not exist" + exit 1 fi🤖 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 `@hack/verify-helm-chart-index.sh` around lines 29 - 37, The script has two related issues preventing proper verification: the `exit 1` statement on line 36 is commented out, suppressing actual verification failures, and the local path mapping on line 29 uses a hardcoded `master` branch reference that won't work for other branches like `release-1.20`. To fix this, uncomment the `exit 1` after the "does not exist" message to restore fail-fast verification, and replace the hardcoded `master` in the path rewriting logic with a branch-agnostic approach that dynamically extracts the correct path component regardless of which branch the URL references.
🟠 Major comments (16)
pkg/smb/controllerserver.go-501-506 (1)
501-506:⚠️ Potential issue | 🟠 Major | ⚡ Quick winValidate
volumeID-derived paths too, not only create-time params.Line 501 adds strong checks for CreateVolume inputs, but
DeleteVolumeandcopyFromVolumestill acceptsource/subDir/uuidfromgetSmbVolFromIDwithout equivalent validation. A craftedvolumeIDcontaining traversal segments can still flow intogetInternalMountPath/getInternalVolumePathand reach filesystem operations.Suggested hardening (centralized in
getSmbVolFromID)func getSmbVolFromID(id string) (*smbVolume, error) { segments := strings.Split(id, separator) if len(segments) < 2 { return nil, fmt.Errorf("could not split %q into server and subDir", id) } source := segments[0] if !strings.HasPrefix(segments[0], "//") { source = "//" + source } vol := &smbVolume{ id: id, source: source, subDir: segments[1], } + if err := validatePath(vol.source); err != nil { + return nil, fmt.Errorf("invalid source %q in volume id: %w", vol.source, err) + } + if err := validatePath(vol.subDir); err != nil { + return nil, fmt.Errorf("invalid subDir %q in volume id: %w", vol.subDir, err) + } if len(segments) >= 3 { vol.uuid = segments[2] + if err := validatePath(vol.uuid); err != nil { + return nil, fmt.Errorf("invalid uuid %q in volume id: %w", vol.uuid, err) + } } if len(segments) >= 4 { vol.onDelete = segments[3] } return vol, nil }As per coding guidelines, path traversal defenses must validate untrusted path-like input at trust boundaries (including
../rejection), which applies to parsedvolumeIDcomponents as well.🤖 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 `@pkg/smb/controllerserver.go` around lines 501 - 506, The path validation added for CreateVolume inputs (using validatePath for vol.source and vol.subDir) does not apply to volumeID-derived paths used in DeleteVolume and copyFromVolume operations. Add equivalent validation inside the getSmbVolFromID function to validate the source, subDir, and uuid components parsed from the volumeID before they are used by callers. Apply the same validatePath checks to reject traversal segments (like ../) in volumeID components at the trust boundary, ensuring getInternalMountPath and getInternalVolumePath only receive validated paths regardless of their origin.Source: Coding guidelines
deploy/v1.20.1/csi-smb-controller.yaml-17-19 (1)
17-19:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHarden controller pod: avoid
hostNetwork/privilegedand set explicit no-escalation controls.This deployment currently runs with
hostNetwork: trueand a privileged driver container. For the controller path, that is a large attack-surface increase. Also setallowPrivilegeEscalation: falseon non-privileged sidecars explicitly.As per coding guidelines: “No hostPID, hostNetwork, hostIPC, privileged: true” and “allowPrivilegeEscalation: false”.
Also applies to: 63-90, 135-139
🤖 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 `@deploy/v1.20.1/csi-smb-controller.yaml` around lines 17 - 19, The csi-smb-controller deployment currently has hostNetwork set to true, which creates unnecessary security risks. Remove the hostNetwork: true configuration from the pod spec in the csi-smb-controller-deployment (and other affected deployments at lines 63-90 and 135-139). Additionally, add securityContext with allowPrivilegeEscalation: false to all non-privileged container specifications within the controller pod to follow security hardening guidelines. Ensure that privileged containers are only used when absolutely necessary and document why they require elevated privileges.Sources: Coding guidelines, Linters/SAST tools
deploy/v1.20.1/csi-smb-node.yaml-48-51 (1)
48-51:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSet explicit
allowPrivilegeEscalation: falsefor non-privileged sidecars.
liveness-probeandnode-driver-registraralready drop capabilities; add explicit no-escalation to complete the hardening baseline.As per coding guidelines: “allowPrivilegeEscalation: false” for container security context in manifests.
Also applies to: 74-77
🤖 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 `@deploy/v1.20.1/csi-smb-node.yaml` around lines 48 - 51, The securityContext for the liveness-probe and node-driver-registrar containers in the CSI SMB node manifest is incomplete. Add the explicit security hardening directive allowPrivilegeEscalation: false to both containers' securityContext blocks (in addition to the existing capabilities drop configuration). This applies to both the liveness-probe and node-driver-registrar sidecars to fully comply with the security baseline requirements.Sources: Coding guidelines, Linters/SAST tools
deploy/v1.20.1/csi-smb-node-windows-hostprocess.yaml-28-35 (1)
28-35:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDocument and constrain the HostProcess
SYSTEM+hostNetworkexception explicitly.This is a high-privilege runtime profile. If it is intentionally required, add explicit justification and compensating controls (policy/namespace constraints) in-manifest or adjacent release docs.
As per coding guidelines: “No hostPID, hostNetwork, hostIPC, privileged: true” and “running as root without justification.”
🤖 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 `@deploy/v1.20.1/csi-smb-node-windows-hostprocess.yaml` around lines 28 - 35, The securityContext configuration in the csi-smb-node-windows-hostprocess.yaml file specifies a high-privilege runtime profile with hostProcess set to true, runAsUserName set to NT AUTHORITY\SYSTEM, and hostNetwork set to true, but provides no explicit justification or compensating controls. Add clear inline comments or documentation explaining the security rationale for this exception and implement compensating controls such as namespace constraints, RBAC policies, or pod security policy restrictions either directly in the manifest or in adjacent release documentation to justify and constrain this high-privilege configuration.Sources: Coding guidelines, Linters/SAST tools
deploy/v1.20.1/csi-smb-node-windows-hostprocess.yaml-43-95 (1)
43-95:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftAdd health checks for HostProcess node components.
This DaemonSet has no liveness/readiness checks (or liveness sidecar), so stuck registrar/plugin processes are harder for kubelet to detect and recover.
As per coding guidelines: “Liveness + readiness probes defined.” This also deviates from the health-check pattern already used in sibling node manifests.
🤖 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 `@deploy/v1.20.1/csi-smb-node-windows-hostprocess.yaml` around lines 43 - 95, Add livenessProbe and readinessProbe sections to both the node-driver-registrar and smb containers in the DaemonSet spec. For each container, define appropriate health checks that validate the process is healthy and responding. Use probes suitable for Windows HostProcess containers, such as HTTPGet probes pointing to the registration socket endpoint for node-driver-registrar and the CSI endpoint for the smb container, with reasonable initial delay, timeout, and period values. Ensure both containers have consistent probe configurations following the health-check pattern used in sibling node manifests.Source: Coding guidelines
deploy/v1.20.1/rbac-csi-smb.yaml-40-42 (1)
40-42:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftScope Secret access to least privilege instead of cluster-wide
get.Both controller and node service accounts receive cluster-scoped Secret read permissions. If either workload is compromised, this enables cross-namespace secret exfiltration.
As per coding guidelines: “RBAC: least privilege; no cluster-admin for workloads” and static-analysis warning “No ServiceAccount/Node should be able to read all secrets.”
Also applies to: 91-111
🤖 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 `@deploy/v1.20.1/rbac-csi-smb.yaml` around lines 40 - 42, The RBAC rule granting cluster-wide secret read permissions violates least privilege principles. Instead of allowing the "get" verb on all "secrets" resources across all namespaces, scope secret access to only what is necessary. Either restrict access to specific namespaces by adding a namespace field, limit to specific secret names by adding a resourceNames field, or remove secret access entirely if the service accounts do not actually require it. Apply the same least privilege scoping fix to all similar rules referenced in the range 91-111 where the same broad cluster-scoped secret access pattern appears.Sources: Coding guidelines, Linters/SAST tools
deploy/v1.20.1/csi-smb-node.yaml-29-30 (1)
29-30:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReplace wildcard toleration to avoid unintended arbiter/special-node scheduling.
operator: "Exists"tolerates every taint, which can place this DaemonSet onto resource-constrained or restricted nodes (including arbiter nodes).Suggested change
tolerations: - - operator: "Exists" + - key: "node-role.kubernetes.io/master" + operator: "Exists" + effect: "NoSchedule" + - key: "node-role.kubernetes.io/control-plane" + operator: "Exists" + effect: "NoSchedule" + - key: "CriticalAddonsOnly" + operator: "Exists" + effect: "NoSchedule"As per coding guidelines: “Flag broad or wildcard tolerations … may inadvertently schedule to resource-constrained TNA arbiter nodes.”
🤖 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 `@deploy/v1.20.1/csi-smb-node.yaml` around lines 29 - 30, The tolerations section currently uses a wildcard toleration with operator: "Exists" which tolerates all taints and can inadvertently schedule the CSI SMB node DaemonSet onto arbiter nodes or resource-constrained nodes. Replace this broad toleration with specific tolerations that target only the intended node types by specifying the exact key and effect combinations (such as specific node-role taints) rather than using the wildcard Exists operator. This ensures the DaemonSet only schedules on appropriate worker nodes and avoids restricted or special-purpose nodes.Source: Coding guidelines
charts/v1.20.1/csi-driver-smb/templates/csi-smb-controller.yaml-48-49 (1)
48-49:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHarden controller defaults: avoid host networking and privileged mode.
Line 48 and Line 171 enable high-risk defaults (
hostNetwork: true,privileged: true) for the controller deployment. These should be opt-in with explicit justification, not defaults.Suggested patch
- hostNetwork: true + hostNetwork: false @@ securityContext: - privileged: true + allowPrivilegeEscalation: false + privileged: false capabilities: drop: - ALLAs per coding guidelines: “Flag privileged: true, hostNetwork … in container/K8s manifests” and “securityContext … allowPrivilegeEscalation: false.”
Also applies to: 170-174
🤖 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 `@charts/v1.20.1/csi-driver-smb/templates/csi-smb-controller.yaml` around lines 48 - 49, The csi-smb-controller deployment has insecure security defaults with hostNetwork set to true on line 48 and privileged set to true on line 171. These high-risk settings should not be enabled by default. Change hostNetwork and privileged to false (or configurable via .Values) to follow the principle of least privilege, and add securityContext with allowPrivilegeEscalation: false to prevent privilege escalation. Make these restrictive settings the default, allowing users to opt-in to elevated privileges only when explicitly needed.Source: Coding guidelines
charts/v1.20.1/csi-driver-smb/values.yaml-112-113 (1)
112-113:⚠️ Potential issue | 🟠 Major | ⚡ Quick winNarrow the default Linux toleration; wildcard toleration is too broad for TNA.
Line 113 (
operator: "Exists") tolerates all taints and can place this workload on arbiter nodes. That conflicts with topology constraints for arbiter usage.Suggested patch
tolerations: - - operator: "Exists" + - key: "node-role.kubernetes.io/master" + operator: "Exists" + effect: "NoSchedule" + - key: "node-role.kubernetes.io/control-plane" + operator: "Exists" + effect: "NoSchedule" + - key: "CriticalAddonsOnly" + operator: "Exists"As per coding guidelines: “Flag broad or wildcard tolerations (tolerating all NoSchedule taints) in operator code and manifests that may inadvertently schedule to resource-constrained TNA arbiter nodes.”
🤖 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 `@charts/v1.20.1/csi-driver-smb/values.yaml` around lines 112 - 113, The tolerations configuration in the values.yaml file uses operator "Exists" in the Linux toleration block, which is a wildcard that tolerates all taints and can inadvertently schedule the workload on resource-constrained arbiter nodes. Instead of using the broad operator "Exists" toleration, specify explicit taint keys and values that the workload should tolerate, ensuring that arbiter-related taints are not included in the toleration list. This will restrict pod placement to appropriate nodes only and prevent scheduling conflicts with topology constraints.Source: Coding guidelines
charts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows-hostprocess.yaml-52-56 (1)
52-56:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHardcoded kubelet path breaks custom configurations.
The initContainer hardcodes
C:\\var\\lib\\kubeletwhile thesmbcontainer'sCSI_ENDPOINTat line 110 uses{{ .Values.windows.kubelet }}. If a user customizes.Values.windows.kubelet, the directory will be created at the wrong path, causing the CSI socket to be missing.🐛 Proposed fix
command: - "powershell.exe" - "-c" - - "New-Item -ItemType Directory -Path C:\\var\\lib\\kubelet\\plugins\\{{ .Values.driver.name }}\\ -Force" + - "New-Item -ItemType Directory -Path {{ .Values.windows.kubelet | replace "\\" "\\\\" }}\\plugins\\{{ .Values.driver.name }}\\ -Force"🤖 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 `@charts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows-hostprocess.yaml` around lines 52 - 56, The initContainer command hardcodes the kubelet path as C:\\var\\lib\\kubelet in the New-Item PowerShell command, but the smb container uses {{ .Values.windows.kubelet }} for its CSI_ENDPOINT, creating inconsistency when users customize the kubelet path. Replace the hardcoded C:\\var\\lib\\kubelet path in the New-Item -Path parameter with {{ .Values.windows.kubelet }} to ensure the directory is created at the correct location matching the CSI_ENDPOINT configuration.charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml-38-39 (1)
38-39:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing
serviceAccountNamein pod spec.Other templates in this chart (e.g.,
csi-smb-node.yamlline 34,csi-smb-node-windows-hostprocess.yamlline 35) setserviceAccountName: {{ .Values.serviceAccount.node }}. This template is missing it, which will cause the pod to use thedefaultServiceAccount and potentially lack required permissions.🐛 Proposed fix
priorityClassName: {{ .Values.priorityClassName | quote }} + serviceAccountName: {{ .Values.serviceAccount.node }} {{- include "smb.pullSecrets" . | indent 6 }}🤖 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 `@charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml` around lines 38 - 39, The csi-proxy-windows.yaml template is missing the serviceAccountName field in its pod specification, which causes the pod to default to using the default ServiceAccount and potentially lack required permissions. Add the serviceAccountName field with the value {{ .Values.serviceAccount.node }} to the pod spec in the csi-proxy-windows.yaml template, following the same pattern used in the csi-smb-node.yaml and csi-smb-node-windows-hostprocess.yaml templates. This field should be added alongside the existing priorityClassName field to ensure the pod uses the correct service account with appropriate permissions.charts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows-hostprocess.yaml-74-80 (1)
74-80:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdditional hardcoded paths inconsistent with templated values.
Lines 78 and 80 hardcode
C:\\var\\lib\\kubeletwhile line 76 uses{{ .Values.windows.kubelet }}. This inconsistency will cause registration failures if the kubelet path is customized.🐛 Proposed fix
env: - name: CSI_ENDPOINT value: unix://{{ .Values.windows.kubelet }}\plugins\{{ .Values.driver.name }}\csi.sock - name: DRIVER_REG_SOCK_PATH - value: C:\\var\\lib\\kubelet\\plugins\\{{ .Values.driver.name }}\\csi.sock + value: {{ .Values.windows.kubelet | replace "\\" "\\\\" }}\\plugins\\{{ .Values.driver.name }}\\csi.sock - name: PLUGIN_REG_DIR - value: C:\\var\\lib\\kubelet\\plugins_registry\\ + value: {{ .Values.windows.kubelet | replace "\\" "\\\\" }}\\plugins_registry\\🤖 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 `@charts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows-hostprocess.yaml` around lines 74 - 80, The environment variables DRIVER_REG_SOCK_PATH and PLUGIN_REG_DIR contain hardcoded kubelet paths (C:\\var\\lib\\kubelet) that are inconsistent with the templated value used in CSI_ENDPOINT ({{ .Values.windows.kubelet }}). Replace the hardcoded C:\\var\\lib\\kubelet prefixes in both DRIVER_REG_SOCK_PATH and PLUGIN_REG_DIR with the same {{ .Values.windows.kubelet }} template variable used in CSI_ENDPOINT, ensuring that all kubelet path references remain consistent and respond to customization through the values configuration..github/workflows/trivy.yaml-2-2 (1)
2-2:⚠️ Potential issue | 🟠 MajorFix mutable action reference and harden workflow permissions and checkout settings.
Line 22 uses a mutable action reference (
aquasecurity/trivy-action@master) which should be pinned to a specific SHA. Additionally, theactions/checkoutstep should setpersist-credentials: false, and the workflow should define an explicitpermissionsblock with least-privilege GITHUB_TOKEN scoping.🤖 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 @.github/workflows/trivy.yaml at line 2, The workflow file has three security issues that need to be addressed: the aquasecurity/trivy-action reference uses a mutable `@master` tag which should be pinned to a specific SHA for reproducibility, the actions/checkout step is missing the persist-credentials: false setting to reduce credential exposure, and the workflow lacks an explicit permissions block at the top level to implement least-privilege access control for the GITHUB_TOKEN. Add a permissions block after the on trigger section with minimal required scopes, update the actions/checkout step to include persist-credentials: false, and replace the `@master` reference in the aquasecurity/trivy-action with a pinned SHA version.Sources: Coding guidelines, Linters/SAST tools
.github/workflows/linux.yaml-42-43 (1)
42-43:⚠️ Potential issue | 🟠 MajorPin goveralls to an exact version instead of
@latest.Line 43 uses
go install github.com/mattn/goveralls@latest, which is non-reproducible and increases supply-chain risk. Pinning to an exact version ensures build consistency and reduces exposure to unexpected upstream changes.Suggested patch
- - name: Install goveralls - run: go install github.com/mattn/goveralls@latest + - name: Install goveralls + run: go install github.com/mattn/goveralls@v2.1.0🤖 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 @.github/workflows/linux.yaml around lines 42 - 43, In the "Install goveralls" step, replace the `@latest` version specifier in the go install command with a specific pinned version number. Change the command from `go install github.com/mattn/goveralls@latest` to `go install github.com/mattn/goveralls@<specific-version>` where the specific version should be replaced with an exact version tag of the goveralls project to ensure reproducible builds and reduce supply-chain risk..github/workflows/ubuntu-e2e.yml-19-19 (1)
19-19:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUpdate Go version to match project target.
The workflow specifies
go-version: ^1.16, which is outdated. Based on the project's current go.mod configuration (Go 1.25), update this to use the current project version.📦 Proposed fix for Go version
- name: Set up Go 1.x uses: actions/setup-go@... with: - go-version: ^1.16 + go-version: "1.25" id: go🤖 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 @.github/workflows/ubuntu-e2e.yml at line 19, Update the go-version parameter in the Ubuntu E2E workflow to match the project's current Go target version. In the ubuntu-e2e.yml file, change the go-version value from the outdated ^1.16 to ^1.25 to align with the Go version specified in the project's go.mod configuration.go.mod-95-95 (1)
95-95:⚠️ Potential issue | 🟠 MajorUpgrade OpenTelemetry packages to address known HIGH severity vulnerabilities.
The current go.mod specifies OpenTelemetry v1.40.0 packages, which are vulnerable to two security advisories:
- GHSA-mh2q-q3fh-2475: DoS amplification in W3C baggage header extraction (fixed in v1.41.0). An attacker can send multiple
baggage:header fields to trigger excessive CPU and memory allocations.- GHSA-hfvc-g4fc-pqhx: PATH hijacking in OpenTelemetry SDK on BSD/Solaris platforms when reading host ID (fixed in v1.43.0). The
kenvcommand is invoked without an absolute path, allowing local attackers to inject a malicious binary.Upgrade
go.opentelemetry.io/otel/*packages to v1.43.0 or later (v1.43.0 addresses both vulnerabilities) or at minimum v1.41.0 for the baggage fix.🤖 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 `@go.mod` at line 95, The go.mod file currently specifies OpenTelemetry packages at v1.40.0, which contain two HIGH severity vulnerabilities. Locate all go.opentelemetry.io/otel/* package entries in go.mod and upgrade them to v1.43.0 or later to address both security issues (GHSA-mh2q-q3fh-2475 and GHSA-hfvc-g4fc-pqhx). At minimum, upgrade to v1.41.0 if v1.43.0 is not feasible, though v1.43.0 is recommended as it fixes both vulnerabilities. Use go get to update these dependencies or manually edit the version constraints in go.mod to reflect the new version across all OpenTelemetry packages.
🟡 Minor comments (3)
deploy/v1.20.1/csi-smb-node-windows.yaml-46-50 (1)
46-50:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd CPU limits for each container to satisfy manifest resource policy.
This manifest sets memory limits but omits CPU limits across all three containers.
As per coding guidelines: “Resource limits (cpu, memory) on every container.”
Also applies to: 78-82, 131-135
🤖 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 `@deploy/v1.20.1/csi-smb-node-windows.yaml` around lines 46 - 50, Add CPU limits to the resource limits specification for all three containers in the manifest. For each container's resources.limits section (appearing at lines 46-50, 78-82, and 131-135), add a cpu field with an appropriate limit value alongside the existing memory limit. This ensures compliance with the resource policy requirement that every container must have both cpu and memory limits defined.Source: Coding guidelines
charts/v1.20.1/csi-driver-smb/templates/NOTES.txt-5-5 (1)
5-5:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix the NOTES pod selector label key/value pairing.
Line 5 uses
app.kubernetes.io/name={{ .Release.Name }}, butapp.kubernetes.io/nameis chart-name based in this chart, so this watch command can return no pods for the release.Suggested patch
- kubectl --namespace={{ .Release.Namespace }} get pods --selector="app.kubernetes.io/name={{ .Release.Name }}" --watch + kubectl --namespace={{ .Release.Namespace }} get pods --selector="app.kubernetes.io/instance={{ .Release.Name }}" --watch🤖 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 `@charts/v1.20.1/csi-driver-smb/templates/NOTES.txt` at line 5, The kubectl command in the NOTES.txt file uses an incorrect label selector. The selector `app.kubernetes.io/name={{ .Release.Name }}` does not match the actual pod labels in this chart, as `app.kubernetes.io/name` is set to the chart name, not the release name. Replace the label selector in the kubectl watch command to use the correct label key that actually matches the release instance, such as using `app.kubernetes.io/instance` with the release name value, so the command will correctly watch pods deployed for this specific release..github/workflows/ubuntu-e2e.yml-11-11 (1)
11-11:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRemove the disabled workflow or document its future use.
The
if: falsecondition disables this entire job. If the E2E workflow is not ready, remove the file entirely rather than committing disabled code. If it is intended for future use, add a clear comment explaining why it's disabled and when it will be enabled.🤖 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 @.github/workflows/ubuntu-e2e.yml at line 11, The ubuntu-e2e.yml workflow is disabled with the `if: false` condition. Either remove this workflow file entirely if it is not currently needed for the project, or if it is intended for future use, replace the `if: false` condition with a descriptive comment explaining why the workflow is disabled and the expected timeline for when it will be re-enabled.Source: Coding guidelines
🧹 Nitpick comments (2)
docs/install-csi-driver-v1.20.1.md (1)
26-31: 💤 Low valueAdd language specification to code fence for example output.
The fenced code block starting at line 26 should include a language identifier (e.g.,
textorconsole) to comply with markdown linting standards and improve readability.✏️ Proposed fix: Add language to code fence
example output: -``` +```text NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES🤖 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 `@docs/install-csi-driver-v1.20.1.md` around lines 26 - 31, The markdown code fence starting at line 26 is missing a language identifier after the opening triple backticks. Add a language specification (such as `text` or `console`) immediately after the opening triple backticks of the code fence that displays the kubectl output example. This will ensure compliance with markdown linting standards and improve readability of the documentation.charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml (1)
40-48: ⚡ Quick winContainer missing
resourcesandsecurityContext.Other containers in this chart define resource limits and drop all capabilities. This container is missing both, which is inconsistent with the security posture of the other templates.
♻️ Proposed enhancement
containers: - name: csi-proxy {{- if hasPrefix "/" .Values.image.csiproxy.repository }} image: "{{ .Values.image.baseRepo }}{{ .Values.image.csiproxy.repository }}:{{ .Values.image.csiproxy.tag }}" {{- else }} image: "{{ .Values.image.csiproxy.repository }}:{{ .Values.image.csiproxy.tag }}" {{- end }} imagePullPolicy: {{ .Values.image.csiproxy.pullPolicy }} + resources: {{- toYaml .Values.windows.csiproxy.resources | nindent 12 }} + securityContext: + capabilities: + drop: + - ALL {{- end -}}Note: This requires adding a
resourcessection under.Values.windows.csiproxyinvalues.yaml.🤖 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 `@charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml` around lines 40 - 48, The csi-proxy container in the csi-proxy-windows.yaml template is missing resource limits and security context configurations that are present in other containers throughout the chart. Add a resources section that references values from .Values.windows.csiproxy for CPU and memory limits and requests, and add a securityContext section that drops all capabilities to maintain consistency with the security posture of other templates in this chart. This will also require adding a corresponding resources configuration block under .Values.windows.csiproxy in the values.yaml file.
🤖 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 @.github/workflows/codespell.yml:
- Line 5: Replace the mutable action references with full commit SHAs for
improved security. On the `actions/checkout@v6` action, replace the version tag
with a full commit SHA and add `persist-credentials: false` to prevent
credential persistence. On the `codespell-project/actions-codespell@master`
action, replace the `@master` mutable ref with a full commit SHA. Additionally,
add an explicit minimal `permissions` block to the job containing `contents:
read` to declare the minimum required permissions following the principle of
least privilege.
In @.github/workflows/pluto.yaml:
- Line 14: The actions/checkout action is pinned to a version tag (`@v6`) instead
of a full commit SHA, which creates a security vulnerability. Replace the `@v6`
tag with the full commit SHA from the actions/checkout releases page.
Additionally, add the persist-credentials: false option to the uses
configuration to limit GitHub token exposure. Apply this fix to all occurrences
of the actions/checkout action in the workflow file.
In @.github/workflows/ubuntu-e2e.yml:
- Line 17: Replace the version tag v6 in the actions/setup-go action with its
full commit SHA. Additionally, add persist-credentials: false to restrict token
exposure. Apply the same changes to the other GitHub Action reference mentioned
at line 23. Ensure both actions are pinned to specific commit SHAs rather than
version tags to comply with CI/CD security guidelines.
In @.golangci.yml:
- Around line 22-37: The exclusions section containing generated, presets, and
rules is incorrectly indented and nested under the linters key in the
`.golangci.yml` file. Move the entire exclusions block (starting with
"generated: lax" and including all the presets and rules) to the root level of
the configuration file so it sits at the same indentation level as the linters
section, not nested within it.
- Around line 3-27: The depguard configuration is incorrectly nested under
linters.settings.staticcheck when it should have its own section at
linters.settings.depguard. Additionally, depguard needs to be explicitly added
to the linters.enable list alongside staticcheck to be activated. Move the
depguard rules block from its current location under staticcheck to
linters.settings.depguard, add depguard to linters.enable, move the exclusions
block to the root level of the configuration (not nested under linters), and
consider adding additional linters such as errcheck, gosimple, and govet to the
linters.enable list to improve code quality checks for this production CSI
driver project.
In `@charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml`:
- Around line 30-33: The nodeSelector configuration in the
csi-proxy-windows.yaml template is missing the mandatory kubernetes.io/os:
windows selector that ensures pods run on Windows nodes. Update the nodeSelector
block to include both the mandatory kubernetes.io/os: windows selector and merge
it with the optional nodeSelector values from
.Values.windows.csiproxy.nodeSelector, similar to how it's implemented in
csi-smb-node-windows.yaml. This ensures the DaemonSet will only schedule on
Windows nodes regardless of what optional selectors are provided in the values.
In `@go.mod`:
- Line 120: The go.mod file contains go.opentelemetry.io packages
(go.opentelemetry.io/otel, go.opentelemetry.io/otel/metric,
go.opentelemetry.io/otel/sdk, and go.opentelemetry.io/otel/trace) at v1.40.0
which have unpatched HIGH severity security vulnerabilities. Upgrade all of
these opentelemetry packages to v1.43.0 or later to address both
GHSA-mh2q-q3fh-2475 and GHSA-hfvc-g4fc-pqhx vulnerabilities. Run go get to
update these dependencies and ensure all transitive dependencies are also
resolved to compatible versions.
---
Outside diff comments:
In `@deploy/csi-smb-node-windows.yaml`:
- Line 36: Update the Windows node DaemonSet sidecar versions to match the Linux
node DaemonSet and Helm values for consistency across platforms. Change the
livenessprobe image version from v2.16.0 to v2.18.0 at line 36, and update the
csi-node-driver-registrar image version from v2.15.0 to v2.16.0 at line 56.
These changes ensure version parity between Windows and Linux deployments as
specified in the Helm values.
In `@hack/verify-helm-chart-index.sh`:
- Around line 29-37: The script has two related issues preventing proper
verification: the `exit 1` statement on line 36 is commented out, suppressing
actual verification failures, and the local path mapping on line 29 uses a
hardcoded `master` branch reference that won't work for other branches like
`release-1.20`. To fix this, uncomment the `exit 1` after the "does not exist"
message to restore fail-fast verification, and replace the hardcoded `master` in
the path rewriting logic with a branch-agnostic approach that dynamically
extracts the correct path component regardless of which branch the URL
references.
---
Major comments:
In @.github/workflows/linux.yaml:
- Around line 42-43: In the "Install goveralls" step, replace the `@latest`
version specifier in the go install command with a specific pinned version
number. Change the command from `go install github.com/mattn/goveralls@latest`
to `go install github.com/mattn/goveralls@<specific-version>` where the specific
version should be replaced with an exact version tag of the goveralls project to
ensure reproducible builds and reduce supply-chain risk.
In @.github/workflows/trivy.yaml:
- Line 2: The workflow file has three security issues that need to be addressed:
the aquasecurity/trivy-action reference uses a mutable `@master` tag which should
be pinned to a specific SHA for reproducibility, the actions/checkout step is
missing the persist-credentials: false setting to reduce credential exposure,
and the workflow lacks an explicit permissions block at the top level to
implement least-privilege access control for the GITHUB_TOKEN. Add a permissions
block after the on trigger section with minimal required scopes, update the
actions/checkout step to include persist-credentials: false, and replace the
`@master` reference in the aquasecurity/trivy-action with a pinned SHA version.
In @.github/workflows/ubuntu-e2e.yml:
- Line 19: Update the go-version parameter in the Ubuntu E2E workflow to match
the project's current Go target version. In the ubuntu-e2e.yml file, change the
go-version value from the outdated ^1.16 to ^1.25 to align with the Go version
specified in the project's go.mod configuration.
In `@charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml`:
- Around line 38-39: The csi-proxy-windows.yaml template is missing the
serviceAccountName field in its pod specification, which causes the pod to
default to using the default ServiceAccount and potentially lack required
permissions. Add the serviceAccountName field with the value {{
.Values.serviceAccount.node }} to the pod spec in the csi-proxy-windows.yaml
template, following the same pattern used in the csi-smb-node.yaml and
csi-smb-node-windows-hostprocess.yaml templates. This field should be added
alongside the existing priorityClassName field to ensure the pod uses the
correct service account with appropriate permissions.
In `@charts/v1.20.1/csi-driver-smb/templates/csi-smb-controller.yaml`:
- Around line 48-49: The csi-smb-controller deployment has insecure security
defaults with hostNetwork set to true on line 48 and privileged set to true on
line 171. These high-risk settings should not be enabled by default. Change
hostNetwork and privileged to false (or configurable via .Values) to follow the
principle of least privilege, and add securityContext with
allowPrivilegeEscalation: false to prevent privilege escalation. Make these
restrictive settings the default, allowing users to opt-in to elevated
privileges only when explicitly needed.
In
`@charts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows-hostprocess.yaml`:
- Around line 52-56: The initContainer command hardcodes the kubelet path as
C:\\var\\lib\\kubelet in the New-Item PowerShell command, but the smb container
uses {{ .Values.windows.kubelet }} for its CSI_ENDPOINT, creating inconsistency
when users customize the kubelet path. Replace the hardcoded
C:\\var\\lib\\kubelet path in the New-Item -Path parameter with {{
.Values.windows.kubelet }} to ensure the directory is created at the correct
location matching the CSI_ENDPOINT configuration.
- Around line 74-80: The environment variables DRIVER_REG_SOCK_PATH and
PLUGIN_REG_DIR contain hardcoded kubelet paths (C:\\var\\lib\\kubelet) that are
inconsistent with the templated value used in CSI_ENDPOINT ({{
.Values.windows.kubelet }}). Replace the hardcoded C:\\var\\lib\\kubelet
prefixes in both DRIVER_REG_SOCK_PATH and PLUGIN_REG_DIR with the same {{
.Values.windows.kubelet }} template variable used in CSI_ENDPOINT, ensuring that
all kubelet path references remain consistent and respond to customization
through the values configuration.
In `@charts/v1.20.1/csi-driver-smb/values.yaml`:
- Around line 112-113: The tolerations configuration in the values.yaml file
uses operator "Exists" in the Linux toleration block, which is a wildcard that
tolerates all taints and can inadvertently schedule the workload on
resource-constrained arbiter nodes. Instead of using the broad operator "Exists"
toleration, specify explicit taint keys and values that the workload should
tolerate, ensuring that arbiter-related taints are not included in the
toleration list. This will restrict pod placement to appropriate nodes only and
prevent scheduling conflicts with topology constraints.
In `@deploy/v1.20.1/csi-smb-controller.yaml`:
- Around line 17-19: The csi-smb-controller deployment currently has hostNetwork
set to true, which creates unnecessary security risks. Remove the hostNetwork:
true configuration from the pod spec in the csi-smb-controller-deployment (and
other affected deployments at lines 63-90 and 135-139). Additionally, add
securityContext with allowPrivilegeEscalation: false to all non-privileged
container specifications within the controller pod to follow security hardening
guidelines. Ensure that privileged containers are only used when absolutely
necessary and document why they require elevated privileges.
In `@deploy/v1.20.1/csi-smb-node-windows-hostprocess.yaml`:
- Around line 28-35: The securityContext configuration in the
csi-smb-node-windows-hostprocess.yaml file specifies a high-privilege runtime
profile with hostProcess set to true, runAsUserName set to NT AUTHORITY\SYSTEM,
and hostNetwork set to true, but provides no explicit justification or
compensating controls. Add clear inline comments or documentation explaining the
security rationale for this exception and implement compensating controls such
as namespace constraints, RBAC policies, or pod security policy restrictions
either directly in the manifest or in adjacent release documentation to justify
and constrain this high-privilege configuration.
- Around line 43-95: Add livenessProbe and readinessProbe sections to both the
node-driver-registrar and smb containers in the DaemonSet spec. For each
container, define appropriate health checks that validate the process is healthy
and responding. Use probes suitable for Windows HostProcess containers, such as
HTTPGet probes pointing to the registration socket endpoint for
node-driver-registrar and the CSI endpoint for the smb container, with
reasonable initial delay, timeout, and period values. Ensure both containers
have consistent probe configurations following the health-check pattern used in
sibling node manifests.
In `@deploy/v1.20.1/csi-smb-node.yaml`:
- Around line 48-51: The securityContext for the liveness-probe and
node-driver-registrar containers in the CSI SMB node manifest is incomplete. Add
the explicit security hardening directive allowPrivilegeEscalation: false to
both containers' securityContext blocks (in addition to the existing
capabilities drop configuration). This applies to both the liveness-probe and
node-driver-registrar sidecars to fully comply with the security baseline
requirements.
- Around line 29-30: The tolerations section currently uses a wildcard
toleration with operator: "Exists" which tolerates all taints and can
inadvertently schedule the CSI SMB node DaemonSet onto arbiter nodes or
resource-constrained nodes. Replace this broad toleration with specific
tolerations that target only the intended node types by specifying the exact key
and effect combinations (such as specific node-role taints) rather than using
the wildcard Exists operator. This ensures the DaemonSet only schedules on
appropriate worker nodes and avoids restricted or special-purpose nodes.
In `@deploy/v1.20.1/rbac-csi-smb.yaml`:
- Around line 40-42: The RBAC rule granting cluster-wide secret read permissions
violates least privilege principles. Instead of allowing the "get" verb on all
"secrets" resources across all namespaces, scope secret access to only what is
necessary. Either restrict access to specific namespaces by adding a namespace
field, limit to specific secret names by adding a resourceNames field, or remove
secret access entirely if the service accounts do not actually require it. Apply
the same least privilege scoping fix to all similar rules referenced in the
range 91-111 where the same broad cluster-scoped secret access pattern appears.
In `@go.mod`:
- Line 95: The go.mod file currently specifies OpenTelemetry packages at
v1.40.0, which contain two HIGH severity vulnerabilities. Locate all
go.opentelemetry.io/otel/* package entries in go.mod and upgrade them to v1.43.0
or later to address both security issues (GHSA-mh2q-q3fh-2475 and
GHSA-hfvc-g4fc-pqhx). At minimum, upgrade to v1.41.0 if v1.43.0 is not feasible,
though v1.43.0 is recommended as it fixes both vulnerabilities. Use go get to
update these dependencies or manually edit the version constraints in go.mod to
reflect the new version across all OpenTelemetry packages.
In `@pkg/smb/controllerserver.go`:
- Around line 501-506: The path validation added for CreateVolume inputs (using
validatePath for vol.source and vol.subDir) does not apply to volumeID-derived
paths used in DeleteVolume and copyFromVolume operations. Add equivalent
validation inside the getSmbVolFromID function to validate the source, subDir,
and uuid components parsed from the volumeID before they are used by callers.
Apply the same validatePath checks to reject traversal segments (like ../) in
volumeID components at the trust boundary, ensuring getInternalMountPath and
getInternalVolumePath only receive validated paths regardless of their origin.
---
Minor comments:
In @.github/workflows/ubuntu-e2e.yml:
- Line 11: The ubuntu-e2e.yml workflow is disabled with the `if: false`
condition. Either remove this workflow file entirely if it is not currently
needed for the project, or if it is intended for future use, replace the `if:
false` condition with a descriptive comment explaining why the workflow is
disabled and the expected timeline for when it will be re-enabled.
In `@charts/v1.20.1/csi-driver-smb/templates/NOTES.txt`:
- Line 5: The kubectl command in the NOTES.txt file uses an incorrect label
selector. The selector `app.kubernetes.io/name={{ .Release.Name }}` does not
match the actual pod labels in this chart, as `app.kubernetes.io/name` is set to
the chart name, not the release name. Replace the label selector in the kubectl
watch command to use the correct label key that actually matches the release
instance, such as using `app.kubernetes.io/instance` with the release name
value, so the command will correctly watch pods deployed for this specific
release.
In `@deploy/v1.20.1/csi-smb-node-windows.yaml`:
- Around line 46-50: Add CPU limits to the resource limits specification for all
three containers in the manifest. For each container's resources.limits section
(appearing at lines 46-50, 78-82, and 131-135), add a cpu field with an
appropriate limit value alongside the existing memory limit. This ensures
compliance with the resource policy requirement that every container must have
both cpu and memory limits defined.
---
Nitpick comments:
In `@charts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yaml`:
- Around line 40-48: The csi-proxy container in the csi-proxy-windows.yaml
template is missing resource limits and security context configurations that are
present in other containers throughout the chart. Add a resources section that
references values from .Values.windows.csiproxy for CPU and memory limits and
requests, and add a securityContext section that drops all capabilities to
maintain consistency with the security posture of other templates in this chart.
This will also require adding a corresponding resources configuration block
under .Values.windows.csiproxy in the values.yaml file.
In `@docs/install-csi-driver-v1.20.1.md`:
- Around line 26-31: The markdown code fence starting at line 26 is missing a
language identifier after the opening triple backticks. Add a language
specification (such as `text` or `console`) immediately after the opening triple
backticks of the code fence that displays the kubectl output example. This will
ensure compliance with markdown linting standards and improve readability of the
documentation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 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 `@deploy/v1.20.1/csi-smb-node-windows.yaml`:
- Around line 31-55: The liveness-probe, node-driver-registrar, and third
container in the Windows node deployment are missing the
allowPrivilegeEscalation security context setting. For each of these three
containers, add allowPrivilegeEscalation: false to their existing
securityContext field (where the capabilities.drop.ALL is currently defined).
This should be added at the same level as the capabilities field within
securityContext to explicitly prevent privilege escalation on all Windows node
containers.
In `@deploy/v1.20.1/csi-smb-node.yaml`:
- Around line 48-51: The securityContext configuration in the CSI SMB node
manifest is missing the allowPrivilegeEscalation: false setting for the
non-privileged sidecars. Add allowPrivilegeEscalation: false to the
securityContext blocks in both the liveness-probe and node-driver-registrar
containers (at lines 48-51 and 74-77) to ensure these sidecars cannot escalate
privileges, reducing the attack surface as per Kubernetes security best
practices.
- Around line 29-31: The tolerations section in the csi-smb-node.yaml DaemonSet
uses a wildcard `operator: "Exists"` which tolerates all taints on all nodes,
potentially causing the pod to be scheduled on unintended nodes like TNA arbiter
nodes. Replace this overly permissive wildcard toleration with specific
tolerations that explicitly target only the taints this DaemonSet should
tolerate, specifying both the key and the taint value to restrict scheduling to
appropriate nodes.
- Around line 20-21: Add an inline comment to the hostNetwork: true setting
explaining that it is required for bidirectional mount propagation in CSI
operations, and ensure there is a similar comment documenting the necessity of
privileged: true in the securityContext (for mount operations). Review the
tolerations section in the spec and narrow them from operator: Exists (which
tolerates all taints) to only the specific required taints for the SMB node
driver. Verify the container image reference uses registry.k8s.io as the
official source and document the security exception rationale either through
inline comments or by adding an annotation explaining the compensating controls
and why this configuration is necessary.
In `@docs/install-csi-driver-v1.20.1.md`:
- Line 7: The curl command disables TLS verification with the -k flag and pipes
directly to bash, which is a security risk. Remove the -k flag from the curl
command and replace the direct pipe-to-shell pattern with a two-step
download-then-run approach where you first download the install-driver.sh script
to a temporary location, verify it if needed, and then execute it. Apply this
same fix to both occurrences of this pattern in the file (line 7 and line 36).
- Around line 26-31: The fenced code block containing the kubectl output showing
the CSI SMB pod status is missing a language identifier. Add a language
specifier (either `text` or `console`) immediately after the opening triple
backticks on the fenced code block to satisfy markdown linting requirements and
maintain consistent rendering throughout the documentation.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 38a417fb-484c-4e40-baf1-804d39087e53
⛔ Files ignored due to path filters (193)
go.sumis excluded by!**/*.sumvendor/github.com/go-logr/logr/.golangci.yamlis excluded by!**/vendor/**,!vendor/**vendor/github.com/go-logr/logr/funcr/funcr.gois excluded by!**/vendor/**,!vendor/**vendor/github.com/google/go-cmp/cmp/cmpopts/sort.gois excluded by!**/vendor/**,!vendor/**vendor/github.com/google/go-cmp/cmp/internal/function/func.gois excluded by!**/vendor/**,!vendor/**vendor/github.com/google/go-cmp/cmp/options.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/CONTRIBUTING.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/LICENSEis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/VERSIONING.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/attr.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/id.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/number.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/resource.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/scope.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/span.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/status.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/traces.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/internal/telemetry/value.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/limit.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/span.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/tracer.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/auto/sdk/tracer_provider.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/.clomonitor.ymlis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/.codespellignoreis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/.gitignoreis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/.golangci.ymlis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/.lycheeignoreis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/CHANGELOG.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/CODEOWNERSis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/CONTRIBUTING.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/LICENSEis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/Makefileis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/README.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/RELEASING.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/SECURITY-INSIGHTS.ymlis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/VERSIONING.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/encoder.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/filter.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/hash.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/internal/attribute.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/internal/xxhash/xxhash.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/iterator.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/key.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/kv.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/rawhelpers.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/set.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/type_string.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/attribute/value.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/baggage/baggage.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/codes/codes.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/dependencies.Dockerfileis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/get_main_pkgs.shis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/attribute/attribute.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/gen.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/global/handler.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/global/instruments.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/global/internal_logging.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/global/meter.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/global/trace.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/internal/rawhelpers.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/LICENSEis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/asyncfloat64.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/asyncint64.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/config.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/instrument.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/meter.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/noop/noop.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/syncfloat64.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/metric/syncint64.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/propagation/baggage.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/propagation/propagation.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/propagation/trace_context.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/renovate.jsonis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/requirements.txtis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/LICENSEis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/instrumentation/library.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/instrumentation/scope.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/internal/x/features.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/internal/x/x.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/auto.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/builtin.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/container.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/env.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/host_id.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/host_id_bsd.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/host_id_linux.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/host_id_unsupported.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/host_id_windows.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/os.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/os_release_darwin.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/os_release_unix.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/os_unix.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/os_unsupported.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/os_windows.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/process.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/resource/resource.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/batch_span_processor.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/evictedqueue.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/id_generator.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/internal/env/env.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/internal/observ/batch_span_processor.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/internal/observ/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/internal/observ/simple_span_processor.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/internal/observ/tracer.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/provider.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/sampler_env.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/sampling.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/simple_span_processor.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/snapshot.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/span.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/span_limits.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/tracer.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/trace/version.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/sdk/version.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/internal/http.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.26.0/README.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.26.0/attribute_group.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.26.0/metric.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/MIGRATION.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/README.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/attribute_group.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/error_type.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/exception.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.37.0/schema.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/MIGRATION.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/README.mdis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/attribute_group.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/error_type.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/exception.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/otelconv/metric.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/semconv/v1.39.0/schema.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/LICENSEis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/auto.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/config.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/context.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/hex.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/attr.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/doc.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/id.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/number.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/resource.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/scope.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/span.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/status.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/traces.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/internal/telemetry/value.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/noop.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/noop/noop.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/provider.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/span.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/trace.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/tracer.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/trace/tracestate.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/verify_examples.shis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/verify_readmes.shis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/verify_released_changelog.shis excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/version.gois excluded by!**/vendor/**,!vendor/**vendor/go.opentelemetry.io/otel/versions.yamlis excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_arm64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_arm64.sis excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_gc_arm64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_gccgo_arm64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_netbsd_arm64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_openbsd_arm64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/cpu/cpu_x86.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/mkerrors.shis excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_386.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_amd64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_arm.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_arm64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_loong64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_mips.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_mips64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_mips64le.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_mipsle.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_ppc.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_ppc64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_ppc64le.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_riscv64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_s390x.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/zerrors_linux_sparc64.gois excluded by!**/vendor/**,!vendor/**vendor/golang.org/x/sys/unix/ztypes_netbsd_arm.gois excluded by!**/vendor/**,!vendor/**vendor/modules.txtis excluded by!**/vendor/**,!vendor/**
📒 Files selected for processing (44)
.golangci.ymlMakefileREADME.mdcharts/README.mdcharts/index.yamlcharts/latest/csi-driver-smb-1.20.0.tgzcharts/latest/csi-driver-smb-1.20.1.tgzcharts/latest/csi-driver-smb/Chart.yamlcharts/latest/csi-driver-smb/values.yamlcharts/v1.20.1/csi-driver-smb-1.20.1.tgzcharts/v1.20.1/csi-driver-smb/Chart.yamlcharts/v1.20.1/csi-driver-smb/templates/NOTES.txtcharts/v1.20.1/csi-driver-smb/templates/_helpers.tplcharts/v1.20.1/csi-driver-smb/templates/csi-proxy-windows.yamlcharts/v1.20.1/csi-driver-smb/templates/csi-smb-controller.yamlcharts/v1.20.1/csi-driver-smb/templates/csi-smb-driver.yamlcharts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows-hostprocess.yamlcharts/v1.20.1/csi-driver-smb/templates/csi-smb-node-windows.yamlcharts/v1.20.1/csi-driver-smb/templates/csi-smb-node.yamlcharts/v1.20.1/csi-driver-smb/templates/rbac-csi-smb.yamlcharts/v1.20.1/csi-driver-smb/templates/storageclass.yamlcharts/v1.20.1/csi-driver-smb/values.yamldeploy/csi-smb-controller.yamldeploy/csi-smb-node-windows-hostprocess.yamldeploy/csi-smb-node-windows.yamldeploy/csi-smb-node.yamldeploy/v1.20.1/csi-smb-controller.yamldeploy/v1.20.1/csi-smb-driver.yamldeploy/v1.20.1/csi-smb-node-windows-hostprocess.yamldeploy/v1.20.1/csi-smb-node-windows.yamldeploy/v1.20.1/csi-smb-node.yamldeploy/v1.20.1/rbac-csi-smb.yamldocs/install-csi-driver-v1.20.1.mddocs/install-smb-csi-driver.mdgo.modhack/verify-helm-chart-index.shpkg/mounter/safe_mounter_host_process_windows.gopkg/smb/controllerserver.gopkg/smb/controllerserver_test.gopkg/smb/nodeserver.gopkg/smb/nodeserver_test.gopkg/smb/smb.gopkg/smb/smb_test.gorelease-tools/prow.sh
✅ Files skipped from review due to trivial changes (9)
- charts/v1.20.1/csi-driver-smb/templates/NOTES.txt
- charts/README.md
- README.md
- docs/install-smb-csi-driver.md
- Makefile
- deploy/csi-smb-controller.yaml
- deploy/csi-smb-node-windows.yaml
- deploy/csi-smb-node.yaml
- deploy/v1.20.1/csi-smb-driver.yaml
🚧 Files skipped from review as they are similar to previous changes (16)
- pkg/mounter/safe_mounter_host_process_windows.go
- hack/verify-helm-chart-index.sh
- pkg/smb/nodeserver.go
- pkg/smb/controllerserver.go
- charts/v1.20.1/csi-driver-smb/Chart.yaml
- pkg/smb/nodeserver_test.go
- charts/v1.20.1/csi-driver-smb/templates/_helpers.tpl
- .golangci.yml
- deploy/csi-smb-node-windows-hostprocess.yaml
- charts/latest/csi-driver-smb/Chart.yaml
- release-tools/prow.sh
- charts/index.yaml
- charts/v1.20.1/csi-driver-smb/values.yaml
- charts/latest/csi-driver-smb/values.yaml
- pkg/smb/smb.go
- pkg/smb/controllerserver_test.go
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
and remove .github
Update github.com/moby/spdystream from v0.5.0 to v0.5.1 to address CVE-2026-35469 (Denial of Service via SPDY streaming code). This CVE affects kubelet, CRI-O, and kube-apiserver SPDY streaming code used for attach, exec, and port forwarding. The fix patches a DOS vulnerability in the SPDY streaming implementation. Upstream PR: kubernetes-csi#1103 Related: OCPBUGS-84460 Signed-off-by: Jaspreet Kaur <jkaur@redhat.com>
|
@dfajmon: 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. |
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
5 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.
STOR-2954: Rebase to upstream v1.20.1 for OCP 5.0
Issue link
https://redhat.atlassian.net/browse/STOR-2954
Diff to upstream v1.20.1
kubernetes-csi/csi-driver-smb@v1.20.1...dfajmon:rebase-v1.20.1
Notes for reviewers
Summary of changes
Notable Bug Fixes
CVE Fixes
CVE-2026-24051
Cherry-picked commits
Upstream changelogs
Full changelog
kubernetes-csi/csi-driver-smb@v1.20.0...v1.20.1
Last rebase
#40
@openshift/storage
Summary by CodeRabbit
New Features
Bug Fixes
Chores