Question about User Namespace ID Mapping with hostPath in Azure VM

Kao
Tue, 29 Jul 2025 09:31:08 +0000
General Discussions

Asking for help? Comment out what you need so we can get more information to help you!

Cluster information:

Kubernetes version: 1.33.2
Cloud being used: (put bare-metal if not on a public cloud)
Installation method: kubeadm
Host OS: Azure VM, ubuntu24.04, azure-linux-kernel: 6.11.0-1018-azure
CRI: crio 1.33.1

Question about User Namespace ID Mapping with hostPath in Azure VM

I’m running a Kubernetes cluster on an Azure VM and encountering an issue with user namespace ID mapping. Here’s my setup:

Environment:

Platform: Azure VM (Standard_B2s)

Virtualization: Hyper-V with Secure Boot + vTPM enabled

Kernel: linux-azure (6.11.0-1018-azure)

Kubernetes setup with user namespaces enabled

Configuration:

I have a pod with user namespaces enabled

Using hostPath to mount a folder from the host into the pod

The pod is configured to run with a non-root user

Observed Behavior:
When I check /proc/{$pod_PID}/mountinfo on the host, I see:

1783 1815 8:1 /home/user_name/nfs /mnt/nfs rw,relatime,idmapped - ext4 /dev/root rw,discard,errors=remount-ro,commit=30

Notice the idmapped flag is present, suggesting ID mapping should be active.

Problem:
However, when I create files inside the mounted folder from within the pod, and then check the file ownership on the host, the files show uid=0 gid=0 (root:root) instead of the expected mapped user ID.

Questions:

1. Is this behavior normal/expected in Azure VM environments?

2. Could this be related to Azure’s Hyper-V virtualization limitations on idmapped mounts?

3. Are there known workarounds for achieving proper user ID mapping with hostPath mounts in Azure-based Kubernetes clusters?

Additional Context:
I’ve verified that:

User namespaces are properly configured (/proc/self/uid_map shows correct mappings)

The mount_setattr system call exists but returns EPERM when tested directly

Other namespace operations (network, PID) work correctly

This appears to be specific to Azure VM environment (Hyper-V with security features enabled)

Any insights on whether this is expected behavior or if there are alternative approaches would be greatly appreciated.

1 post - 1 participant