Introduction
Il y a quelques semaines, Azure a annoncé la disponibilité générale (GA) de l’utilisation des blobs avec le protocole NFS v3.Dans cet article, nous allons voir comment utiliser cette fonctionnalité pour monter un Azure Blob Storage en tant que volume Docker sous un point de montage en utilisant le protocole NFS v3.
1. NFS dans Azure
La premier chose à faire est de créer notre storage account en NFSv3. A savoir qu’il faut impérativement activer la fonctionnalité au moment de la création de notre SA (Storage Account).
Pour des raisons de sécuriter et pour se rapprocher au maximum d’une PRD nous allons le deployer en “private” pour qu’il soit uniquement accessible depuis notre subnet Azure.
On pensera bien à ajouter notre subnet pour qu’il soit autorisé à consommer notre storage en NFS
Ce qui nous donne en résumé ceci :
Maintenant que notre storage account a été créer nous allons ajouter notre container :
Attention par défaut, l’option n’est pas root squash. Ce qui nous donne la configuration suivante :
NFS in IaaS
Maintenant que notre partage NFS est disponible il nous reste plus qu’a le monter sur nos VMs avec la commande suivante :
mount -o sec=sys,vers=3,nolock,proto=tcp devnfs.blob.core.windows.net:/devnfs/docker /mnt/test
on oubliera pas d’installer les outils au préalable si ce n’est pas déjà fait :
sudo yum install nfs-utils
NFS in docker
Maintenant que nous avons testé que notre NFS fonctionne nous allons le monter dans notre container
Exemple d’un docker-compose.yml avec un volume NFS :
Si vous êtes sur centos est que vous rencontrez des problématiques autour de “cgroup”. Example
“WARNING: Your kernel does not support cgroup swap limit.”
Vous devez modifier votre grub de la facon suivante :
vi /etc/default/grub
Et on y ajoute la ligne suivante :
GRUB_CMDLINE_LINUX_DEFAULT="cgroup_enable=memory swapaccount=1"
Un petit sudo reboot est tout devrait rentrer dans l’ordre.
Sinon sans le reboot :
service docker stop
service containerd stop
cgroupfs-umount
cgroupfs-mount
service containerd start
service docker start
Conclusion
Azure Blob Storage est une solution qui offre une option peu coûteuse pour stocker des données dans le cloud. Attention tout de même le stockage comporte certaines limitations. L’utilisation de NFS sur le stockage Blob fonctionnera pour de nombreuses charges de travail qui ne nécessitent pas d’IOPS (opérations d’entrée/sortie par seconde). Pour des performances accrues on envisagera plus d’utiliser Azure NetApp.
Vous trouverez plus d’information sur la sécurité des blob ici : https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations#networking
Un article sur les performances : https://docs.microsoft.com/en-us/azure/storage/blobs/network-file-system-protocol-support-performance
Terraform
Vous trouverez un exemple de code TF pour créer notre storage account NFS en privée sur le blog d’Alexandre COMET. Alexandre COMET
Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome
NFSv4.1, chiffrement en transit (AZNFS) et Kubernetes CSI
Depuis 2021, l’utilisation du protocole NFS sur Azure s’est considérablement enrichie et structurée autour de trois offres complémentaires selon le profil d’IOPS et de conformité :
1. Azure Blob NFSv3 vs Azure Files NFSv4.1 vs Azure NetApp Files
| Critère | Azure Blob Storage (NFSv3) | Azure Files Premium (NFSv4.1) | Azure NetApp Files (NFSv3 / v4.1) |
|---|---|---|---|
| Cas d’usage idéal | Big Data, ingestion analytique, archives volumineuses, lecture séquentielle | Conteneurs (AKS/Docker), partages applicatifs POSIX, bases de fichiers | Workloads critiques à faible latence (< 1 ms), HPC, SAP HANA, BDD |
Verrouillage fichier (lockd) | Non (nolock obligatoire) | Oui (Verrouillage natif NFSv4.1) | Oui (NLM v3 & Locking v4.1) |
Attributs étendus (xattrs) | Non | Partiel | Oui |
2. Chiffrement en transit natif avec aznfs (Stunnel managé)
Historiquement, le trafic NFSv3 sur Azure circulait en clair à l’intérieur du VNet (Private Endpoint). En 2026, Microsoft fournit le helper de montage aznfs qui encapsule automatiquement le flux NFSv3/v4.1 dans un tunnel TLS 1.3 vers la passerelle Azure Storage :
# Montage NFS chiffré en transit (TLS) en 2026 via le mount helper aznfs
sudo mount -t aznfs -o vers=3,proto=tcp devnfs.blob.core.windows.net:/devnfs/docker /mnt/test
3. Intégration native avec Kubernetes (blob-csi-driver)
Sous AKS ou Docker/K8s, plus besoin de monter manuellement le partage sur chaque nœud hôte : le pilote blob.csi.azure.com (protocol: nfs) provisionne dynamiquement les PersistentVolumeClaims en mode ReadWriteMany (RWX) tout en gérant automatiquement les options de montage et la résilience réseau.
Hardening Maximal NFSv3 / Azure Files (Azure CLI az & Sources Officielles)
Comme le rappelle la documentation officielle Microsoft Learn : NFS 3.0 protocol support for Azure Blob Storage [1], le protocole NFSv3 ne chiffre pas nativement le trafic en transit et s’appuie sur l’isolation réseau. Le durcissement maximal exige donc :
- Désactivation totale de l’accès réseau public (
--Public-network-access Disabled+default-action Deny) [2]. - Exposition exclusive par Azure Private Endpoint ou Service Endpoint verrouillé sur un unique sous-réseau privé dédié.
- Montage Linux avec options restrictives (
nosuid,nodev,noexec,rolorsque applicable) et chiffrement en transit via tunnel WireGuard / stunnel (aznfsmount helper) [3].
Commandes Azure CLI (az) : Verrouillage Zero-Trust du Storage Account NFSv3
# 1. Créer le compte de stockage Premium BlockBlobStorage avec accès public coupé et TLS 1.2
az storage account create \
--name stprodnfshardened01 \
--resource-group rg-prod-storage \
--location francecentral \
--sku Premium_ZRS \
--kind BlockBlobStorage \
--enable-hierarchical-namespace true \
--enable-nfs-v3 true \
--min-tls-version TLS1_2 \
--allow-blob-public-access false \
--allow-shared-key-access false \
--https-only true \
--default-action Deny
# 2. Autoriser exclusivement le sous-réseau privé AKS/VMs via VNet Rule
az storage account network-rule add \
--resource-group rg-prod-storage \
--account-name stprodnfshardened01 \
--vnet-name vnet-prod-spoke \
--subnet snet-private-nodes
# 3. Montage Linux durci côté client (nosuid, nodev)
sudo mount -o sec=sys,vers=3,proto=tcp,nosuid,nodev,nolock \
stprodnfshardened01.blob.core.windows.net:/stprodnfshardened01/appdata /mnt/nfs_secure