Restrict volume mountpoint to /var/lib/kubelet/pods

[srranjan-sri]

What type of PR is this?

What this PR does / why we need it:
Restrict Azure File CSI driver mountpoint-dir to /var/lib/kubelet/pods

added a dedicated Kerberos path for managed identity authentication.

What changed:

• mountpoint-dir is now limited to /var/lib/kubelet/pods instead of broader kubelet paths.
• Added a new kerberos-dir hostPath volume mapped to /var/lib/kubelet/kerberos.
• Updated container mounts so:
  • azurefile uses both pods mount and kerberos mount.
  • azfilesrefresh and install-azurefile-proxy use kerberos-dir for identity-related files.

Which issue(s) this PR fixes:

Fixes #
Updated mountpoint-dir hostPath and mountPath from /var/lib/kubelet/ to /var/lib/kubelet/pods
Uses single kubelet variable with /pods suffix appended directly in templates

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:

Release note:

none

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: srranjan-ms / name: Srirajiv Ranjan (1dd14fa, e85d52b)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: srranjan-sri
Once this PR has been reviewed and has the lgtm label, please assign feiskyer for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @srranjan-sri!

It looks like this is your first PR to kubernetes-sigs/azurefile-csi-driver 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/azurefile-csi-driver has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @srranjan-sri. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[andyzhangx]

this csi driver mount different folders under /var/lib/kubelet/, e.g. plugins, kerberos, kubernetes/csi, and azfilesauth may create different folders under this dir, if we restrict all dirs in this csi driver, that would make this csi driver difficult to functional well and difficult to maintain

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mittachaitu]

LGTM!!

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mittachaitu, srranjan-sri
Once this PR has been reviewed and has the lgtm label, please assign feiskyer for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[srranjan-sri]

@andyzhangx i had added some new changes, can you plz review it??

[Copilot]

Pull request overview

This PR tightens the Azure File CSI node DaemonSet hostPath exposure by restricting the mountpoint directory to the kubelet pods subtree and introducing a dedicated hostPath for Kerberos cache/config files used by Managed Identity authentication.

Changes:

• Restricts mountpoint-dir hostPath usage from the kubelet root to /var/lib/kubelet/pods (and Helm equivalent).
• Adds a new kerberos-dir hostPath volume mapped to /var/lib/kubelet/kerberos and mounts it into relevant containers.
• Updates azfilesrefresh (and Helm template equivalents) to use kerberos-dir for identity-related files.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
deploy/csi-azurefile-node.yaml	Restricts the node DaemonSet’s kubelet mountpoint hostPath to /var/lib/kubelet/pods and adds a Kerberos hostPath.
charts/latest/azurefile-csi-driver/templates/csi-azurefile-node.yaml	Mirrors the mountpoint restriction and Kerberos hostPath additions in the Helm template.

Comments suppressed due to low confidence (4)

charts/latest/azurefile-csi-driver/templates/csi-azurefile-node.yaml:171

• kerberos-dir is a file directory hostPath and does not need mountPropagation: Bidirectional; keeping it bidirectional expands host-mount influence beyond what's required for kerberos cache files.

            - mountPath: /var/lib/kubelet/kerberos
              mountPropagation: Bidirectional
              name: kerberos-dir

charts/latest/azurefile-csi-driver/templates/csi-azurefile-node.yaml:252

• kerberos-dir is a file directory hostPath and does not need mountPropagation: Bidirectional; keeping it bidirectional expands host-mount influence beyond what's required for kerberos cache files.

            - mountPath: /var/lib/kubelet/kerberos
              mountPropagation: Bidirectional
              name: kerberos-dir

deploy/csi-azurefile-node.yaml:170

• kerberos-dir is a plain directory hostPath; mountPropagation: Bidirectional is unnecessary here and increases the pod's ability to affect host mounts. Consider dropping mountPropagation for this mount.

            - mountPath: /var/lib/kubelet/kerberos
              mountPropagation: Bidirectional
              name: kerberos-dir

deploy/csi-azurefile-node.yaml:200

• kerberos-dir is a plain directory hostPath; mountPropagation: Bidirectional is unnecessary here and increases the pod's ability to affect host mounts. Consider dropping mountPropagation for this mount.

            - mountPath: /var/lib/kubelet/kerberos
              mountPropagation: Bidirectional
              name: kerberos-dir

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[andyzhangx]

Thanks for the PR! The direction is right — restricting mountpoint-dir to /var/lib/kubelet/pods and separating kerberos paths is a good security hardening move. A few issues to address before this can merge:

1. Helm template: mountPath vs hostPath mismatch for azurefile container
   In csi-azurefile-node.yaml (Helm), the azurefile container still mounts mountpoint-dir at {{ .Values.linux.kubelet }} (line ~109), but the volume's hostPath was changed to {{ .Values.linux.kubelet }}/pods. This asymmetry means the container sees /var/lib/kubelet internally but it's actually backed by /var/lib/kubelet/pods on the host. The mountPath should also be updated to {{ .Values.linux.kubelet }}/pods for consistency.

2. kerberos-dir hostPath is hardcoded
   The new kerberos-dir volume uses a hardcoded /var/lib/kubelet/kerberos path. This doesn't respect the {{ .Values.linux.kubelet }} variable. If a user has a custom kubelet root (e.g. /data/kubelet), this will point to the wrong location. Please use {{ .Values.linux.kubelet }}/kerberos in the Helm template (and the corresponding variable in the static manifest if applicable).

3. azfilesrefresh container lost access to pods mount
   Previously azfilesrefresh mounted the entire kubelet dir. Now it only has kerberos-dir. Please confirm that the refresh logic doesn't need to traverse pod volume mounts (some Kerberos ticket refresh implementations do). If it doesn't, this is fine — just want to make sure.

4. Missing tests / upgrade validation
   Since this changes mount paths on the node DaemonSet, it would be good to at least run helm template render tests to confirm the output is correct. An upgrade from the previous version should also be validated (pods with existing mounts).

/kind cleanup

[srranjan-sri]

@andyzhangx , following up on your comment, i had addressed the comments and pushed the changes , also confirmed that the refresh logic doesn't need to traverse pod volume mounts. i had also validated the code changes working fine by first installing the driver from the master branch chart and brought up two pods — a normal account-key pod and a managed-identity pod. The MI pod mounted the Azure file share over SMB with Kerberos (sec=krb5), azfilesauthmanager list showed exactly one Kerberos ticket, and full file read/write/delete from inside the app pod worked fine.

I then upgraded the driver to my branch's chart (azureFilesMountPoint, which restricts kubelet mounts to /var/lib/kubelet/pods and adds the derived kerberos-dir for managed-identity auth) and confirmed the ticket and access persisted. For resiliency, I manually cleared the Kerberos ticket and rebooted the node — after it came back, the NodeStage flow automatically re-acquired a fresh ticket and the pod regained full read/write access to the share. Everything worked end-to-end.

[andyzhangx]

/ok-to-test

[andyzhangx]

the globalmount is under /var/lib/kubelet/plugins/kubernetes.io/csi/<driver>/<hash>/globalmount, we should keep that mount path, thus I would recommend keep /var/lib/kubelet/

your original test is not sufficient since node reboot just make remount happen again, does not test the refresh token functionality.

[srranjan-sri]

@andyzhangx, I addressed your comment and added a dedicated plugins-dir hostPath for /var/lib/kubelet/plugins (Bidirectional), keeping mountpoint-dir scoped to /var/lib/kubelet/pods. This preserves globalmount without exposing all of /var/lib/kubelet/.

Also to test the refresh token functionality, I used workload identity, which rotates the projected token roughly every hour. I first installed the driver from the main-branch helm chart, created the WI pod, and had it append the timestamp + current token to a file on the mounted share every minute. After confirming the token had refreshed once, I upgraded the driver to my branch's helm chart. The pod kept running fine across the upgrade with no disruption to the refresh flow — the token refreshed again ~1h after the previous refresh, and once more an hour later. So the refresh-token functionality works both before and after the upgrade, independent of any remount.

`# before upgrade (driver from main)
09:12:19Z  iat=09:11:33 exp=10:11:33  jti=643bf1d2…
10:00:29Z  iat=09:59:37 exp=10:59:37  jti=b73d009c…

--- driver upgraded to v0.0.1 (my branch) @ 10:40 ---

 after upgrade (my branch)
10:48:38Z  iat=10:47:43 exp=11:47:43  jti=555e1530…   (refresh #1)
11:36:48Z  iat=11:36:29 exp=12:36:29  jti=660cba17…   (refresh #2)`

[andyzhangx]

The workload identity token refresh test looks good, but I think there's a separate issue with the azfilesrefresh container for Managed Identity (MI) Kerberos auth specifically.

After this PR, azfilesrefresh only mounts kerberos-dir (/var/lib/kubelet/kerberos) — it no longer has mountpoint-dir. The problem is that azfilesrefresh discovers which CIFS mounts need ticket refresh by running mount -t cifs inside its own mount namespace (see AzFilesAuthenticator get_mount_options()):

def get_mount_options():
    result = subprocess.run(['mount', '-t', 'cifs'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    mount_output = result.stdout.decode('utf-8')
    # ... filters for sec=krb5 mounts

Without mountpoint-dir (which had mountPropagation: Bidirectional), CIFS mounts created by kubelet under /var/lib/kubelet/pods/<uid>/volumes/... are no longer propagated into the azfilesrefresh container's mount namespace. So mount -t cifs returns empty → no tickets get refreshed → Kerberos tickets expire → MI-authed Azure Files mounts break.

The WI token refresh test above works because WI uses a different code path (projected service account tokens, not Kerberos). MI Kerberos auth is the affected path.

Fix: add mountpoint-dir back to azfilesrefresh:

- name: azfilesrefresh
  volumeMounts:
    - mountPath: /var/lib/kubelet/pods
      mountPropagation: Bidirectional
      name: mountpoint-dir          # ← need this for mount -t cifs visibility
    - mountPath: /var/lib/kubelet/kerberos
      mountPropagation: Bidirectional
      name: kerberos-dir
    - name: azfilesauth
      mountPath: /etc/azfilesauth
    - name: log-dir
      mountPath: /var/log/

[andyzhangx]

also the token refresh could happen within one hour while the token expire may take ~1 day, so even it's not refreshed within a few hours, the existing cifs mount would be still valid

[srranjan-sri]

added the fix. Fix: add mountpoint-dir back to azfilesrefresh:

[andyzhangx]

I think it's better have plugins-dir mounted in the azfilesrefresh container

            - mountPath: /var/lib/kubelet/plugins
              mountPropagation: Bidirectional
              name: plugins-dir

[andyzhangx]

the globalmount is under /var/lib/kubelet/plugins/kubernetes.io/csi///globalmount, we should keep that mount path, thus I would recommend keep /var/lib/kubelet/

[srranjan-sri]

/retest