Data security in modern cloud-native ecosystems is no longer confined to protecting static data residing on physical disks—it demands continuous, end-to-end cryptographic protection as data traverses internal networks and distributed service meshes. Within enterprise environments running on Azure Kubernetes Service (AKS), stateful applications frequently rely on Network File System (NFS) v4.1 shares for scalable, high-throughput, and multi-writer storage capabilities. However, traditional network file protocols historically lacked built-in payload encryption, leaving data vulnerable to internal eavesdropping or forcing architects to deploy complex custom VPNs and service meshes.

With the General Availability (GA) of Encryption in Transit (EiT) for Azure Files NFS v4.1 shares in AKS, Microsoft bridges this critical security gap. By natively embedding Transport Layer Security (TLS) encryption into the Azure File Container Storage Interface (CSI) driver stack, organizations can now enforce strict cryptographic controls for data-in-transit without modifying application code, managing custom certificates, or sacrificing the performance required by enterprise workloads.

Historically, standard NFSv4.1 protocol traffic across local networks or virtual networks (VNets) was transmitted in unencrypted plain text. While private endpoints and Virtual Network integration mitigate exposure to the public internet, internal lateral movement risks and strict regulatory mandates (such as PCI-DSS v4.0, HIPAA, ISO/IEC 27001, and GDPR) demand that all data-in-transit be encrypted using modern cryptographic standards.

+-----------------------------------------------------------------------------------+
| AKS Linux Node Host                                                               |
|                                                                                   |
|  +--------------------+        Unencrypted NFS Request                            |
|  | Pod (Application)  | ----------------------------+                             |
|  +--------------------+                             |                             |
|                                                     v                             |
|                                         +-----------------------+                 |
|                                         | Localhost Loopback    |                 |
|                                         | (127.0.0.1:Port)      |                 |
|                                         +-----------------------+                 |
|                                                     |                             |
|                                                     v                             |
|                                         +-----------------------+                 |
|                                         | AZNFS / Stunnel       |                 |
|                                         | Client Process Engine |                 |
|                                         +-----------------------+                 |
+-----------------------------------------------------|-----------------------------+
                                                      |
                                                      | Encrypted TLS Tunnel
                                                      | (AES-GCM / Port 2049)
                                                      v
                                  +---------------------------------------+
                                  | Azure Files NFS v4.1 Endpoint         |
                                  | (Storage Account / Premium SSD)       |
                                  +---------------------------------------+

When Encryption in Transit is enabled via the Azure File CSI Driver, the underlying node host does not establish a direct, raw TCP socket to port 2049 on the remote Azure Storage Account. Instead, it invokes a multi-layered client wrapper mechanism transparently beneath the Linux Kernel File System layer:

Before deploying Encryption in Transit across your AKS clusters, ensure your environment meets the following baseline technical parameters:

Dynamic provisioning allows Kubernetes to manage the lifecycle of the underlying Azure Storage Account and share automatically. Setting encryptInTransit: "true" within the StorageClass manifest forces the CSI driver to provision encrypted endpoints.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs-eit-premium
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS        # High-performance SSD tier
  encryptInTransit: "true"       # Enforces client-side TLS proxying
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - nconnect=4                  # Establishes multiple TCP connections for higher I/O throughput
  - noresvport                  # Prevents client-side port exhaustion during pod recycling
  - actimeo=30                  # Controls attribute caching timeouts in seconds

Corresponding PersistentVolumeClaim (PVC) manifest:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-eit-data-pvc
  namespace: production
spec:
  accessModes:
    - ReadWriteMany             # Allows concurrent read/write across multiple pods on different nodes
  storageClassName: azurefile-csi-nfs-eit-premium
  resources:
    requests:
      storage: 100Gi

For environments utilizing pre-provisioned Azure Storage Accounts and NFS shares, update or define the PersistentVolume (PV) spec to explicitly include encryptInTransit: "true" inside volumeAttributes:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azurefile-nfs-eit-static
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - nconnect=4
    - noresvport
    - actimeo=30
  csi:
    driver: file.csi.azure.com
    volumeHandle: "rg-prod-storage#staksprodnfs#share-analytics-data"
    volumeAttributes:
      protocol: nfs
      encryptInTransit: "true"   # Enables Stunnel wrapper for static volume mount
      resourceGroup: "rg-prod-storage"
      storageAccount: "staksprodnfs"
      shareName: "share-analytics-data"

To enforce compliance at the cloud management plane and guarantee that no unencrypted connections are accepted by Azure Files, configure infrastructure-level encryption policies via Azure CLI or Azure Policy:

# Enforce secure transit requirements on the Azure Storage Account level
az storage account update \
  --name staksprodnfs \
  --resource-group rg-prod-storage \
  --require-infrastructure-encryption true

To validate that traffic is actively passing through the local cryptographic tunnel and not leaving the node as unencrypted plain text, perform the following operational checks:

Execute a command inside the mounting pod or directly on the host worker node to verify the active target IP address using df -Th:

# Execute within the node or pod container
df -Th | grep nfs

Expected Output Breakdown:

Filesystem                               Type  Size  Used Avail Use% Mounted on
127.0.0.1:/staksprodnfs/share-analytics  nfs4  100G  1.2G  98.8G   2% /mnt/data

Diagnostic Note: The source target is bound to 127.0.0.1 (localhost). This confirms that the OS kernel filesystem calls are being routed through the local Stunnel loopback socket rather than directly to the remote Storage Account IP.

To conclusively verify payload encryption, run a packet capture utility (tcpdump) on the physical interface of the worker node while generating test file writes:

# Capture packets destined for port 2049 on the network interface
sudo tcpdump -i any dport 2049 -w /tmp/nfs_trace.pcap

Open /tmp/nfs_trace.pcap in Wireshark:

While client-side TLS proxying introduces cryptographic overhead, proper tuning ensures that high-throughput workloads maintain optimal performance:

In this article, you configured Encryption in Transit for Azure Files NFS v4.1 shares inside an Azure Kubernetes Service cluster. You explored the underlying architecture powered by the AZNFS mount helper and Stunnel client proxy, implemented both dynamic and static PVC provisioning configurations, and verified packet-level TLS encryption directly on the worker node.

You now have a production-ready blueprint for securing stateful file storage in compliance with Zero Trust principles and enterprise security mandates. From here, you can enforce storage-level encryption parameters across your entire organization using Azure Policy, fine-tune TCP performance using advanced nconnect mount parameters, or combine encrypted NFS storage with Private Endpoints for complete network isolation.

Thank you for taking the time to go through this post and making it to the end. Stay tuned, because we’ll keep continuing providing more content on topics like this in the future.