Not so long ago I was working on an internal project that required me to deploy Linux VMs that were hosting a workload that saved a copy of any number of video live feeds to blob storage for safeguard and for future replays. I also needed it to be mounted automatically when the VM was created.
I know that are several ways to map storage in a VM. You can:
I'm not sure... Could be because NFSv3 provides compatibility for existing applications, could be because of the scale it can support or maybe just because it's cost effective and easy to setup.
In any case, I followed the documentation here to create the virtual network, service endpoint to ensure that the storage account can only be accessed from the appropriate vnet and subnet, and the storage account.
To automate this at the time of deployment I added the following few lines to the Custom Script Extention script i use to deploy the workload on a new VM at deployment time.
Except that the workload on the VM could not write to the blob storage. I realized that when the custom Script extension creates the folder livefeed in /mnt it's done by the Azure Agent user context (Root) and therefore the permissions on that folder
Only provide read write to Root. For my test I added the following line to the end of my script, and it worked like a charme.
chmod 777 /mnt/livefeed
I do Not promote giving all rights to all users in a production environment.
My next step is to create a group that include the user context which the workload in running under and change the permissions so only the account needed have write access.
I really believe in the Least-Privilege Administrative Models when it comes to any environments (On-Prem, Hybrid and cloud native).
In any case, I hope this may give you some ideas on how you can leverage Azure services to address problems in your environment.