AzureFeeds

Azure Files NFS volumes now support encryption in-transit  via TLS. With this enhancement, Azure Files NFS v4.1 offers the robust security that modern enterprises require, without compromising performance by ensuring all traffic between clients and servers is fully encrypted. Now Azure Files NFS data can be encrypted end-to-end: at rest, in transit, and across the network.

Using Stunnel, an open-source TLS wrapper, Azure Files encrypts the TCP stream between the NFS client and Azure Files with strong encryption using AES-GCM, without needing Kerberos. This ensures data confidentiality while eliminating the need for complex setups or external authentication systems like Active Directory.

The AZNFS utility package simplifies encrypted mounts by installing and setting up Stunnel on the client (Azure VMs). The AZNFS mount helper mounts the NFS shares with TLS support. The mount helper initializes dedicated stunnel client process for each storage account’s IP address. The stunnel client process listens on a local port for inbound traffic and then redirects encrypted nfs client traffic to the 2049 port where NFS server is listening on.

The AZNFS package runs a background job called aznfswatchdog. It ensures that stunnel processes are running for each storage account and cleans up after all shares from the storage account are unmounted. If for some reason a stunnel process is terminated unexpectedly, the watchdog process restarts it.

For more details, refer to the following document: How to encrypt data in transit for NFS shares

Availability in Azure Regions

All regions that support Azure Premium Files now support encryption in transit.

Supported Linux releases

For SAP on Azure environment, Azure Files NFS Encryption in Transit (EiT) is available for the following Operating System releases.

• SLES for SAP 15 SP4 onwards


• RHEL for SAP 8.6 onwards (EiT is currently not supported for file systems managed by Pacemaker clusters on RHEL.)

Refer to SAP Note 1928533 for Operating system supportability for SAP on Azure systems.

How to deploy Encryption in Transit (EiT) for Azure Files NFS Shares

1. Refer to the SAP on Azure deployment planning guide about Using Azure Premium Files NFS and SMB for SAP workload

As described in the planning guide, for SAP workloads, following are the supported uses of Azure Files NFS shares and EiT can be used for all the scenarios:

• 
  
  
  
  • sapmnt volume for a distributed SAP systems
  
  
  • transport directory for SAP landscape
  
  
  • /hana/shared for HANA scale-out. Review carefully the considerations for sizing /hana/shared, as appropriately sized /hana/shared volume contributes to system’s stability
  
  
  • file interface between your SAP landscape and other applications
  
  
  
  

2. Deploy the Azure File NFS storage account. Refer to the standard documentation for creating the Azure Files storage account, file share and private endpoint.

    Create an NFS Azure file share

    Note : We can enforce EiT for all the file shares in the Azure Storage account by enabling ‘secure transfer required’ option.

3. Deploy the mount helper (AZNFS) package on the Linux VM.

Follow the instructions for your Linux distribution to install the package.

4. Create the directories to mount the file shares.

mkdir -p

5. Mount the NFS File share.

Refer to the section for mounting the Azure Files NFS EiT file share in Linux VMs.

To mount the file share permanently by adding the mount commands in ‘/etc/fstab’.

sapnfs.file.core.windows.net:/sapnfsafs/sapnw1/sapmntNW1 /sapmnt/NW1 aznfs noresvport,vers=4,minorversion=1,sec=sys,_netdev 0 0

# Mount the file systems

mount -a

o    File systems mentioned above are an example to explain the mount command syntax.

o   When adding nfs mount entry to /etc/fstab, the fstype is “nfs”. However, to use AZNFS mount helper and EiT, we need to use the fstype as “aznfs” which is not known to the Operating System, so at boot time the server tries to mount these entries before the watchdog is active, and they may fail. Users should always add “_netdev” option to their /etc/fstab entries to make sure shares are mounted on reboot only after the required services (like network) are active.

o   We can add “notls” option in the mount command, if we don’t want to use the EiT but just want to use AZNFS mount helper to mount the file system. Also , we cannot mix EiT and no-EiT methods for different file systems using Azure Files NFS in the same Azure VM. Mount commands may fail to mount the file systems if EiT and no-EiT methods are used in the same VM

o   Mount helper supports private-endpoint based connections for Azure Files NFS EiT.

o   If SAP VM is custom domain joined, then we can use custom DNS FQDN OR  short names for file share in the ‘/etc/fstab’ as its defined in the DNS. To verify the hostname resolution, check using ‘nslookup ’ and ‘getent host ’ commands.

6. Mount the NFS File share as pacemaker cluster resource for SAP Central Services.

In high availability setup of SAP Central Services, we may use file system as a resource in pacemaker cluster and it needs to be mounted using pacemaker cluster command. In the pacemaker commands to setup file system as cluster resource, we need to change the mount type to ‘aznfs’ from ‘nfs’. Also it’s recommended to use ‘_netdev’ in the options parameter.

Following are the SAP Central Services setup scenarios in which Azure Files NFS is used as pacemaker resource agent, and we can use Azure Files NFS EiT. 

• 
  
  
  
  • Azure VMs high availability for SAP NW on SLES with NFS on Azure Files
  
  
  • Azure VMs high availability for SAP NW on RHEL with NFS on Azure Files
  
  
  
  

For SUSE Linux:

SUSE 15 SP4 (for SAP) and higher releases recognise the ‘aznfs’ as file system type in the pacemaker resource agent.

SUSE recommends using simple mount approach for high availability setup of SAP Central services, in which all file systems are mounted using ‘/etc/fstab’ only.

For RHEL Linux:

RHEL 8.6 (for SAP) and higher releases will be recognising ‘aznfs’ as file system type in pacemaker resource agent.

At the time of writing the blog, ‘aznfs’ as file system type is not yet recognised by the FileSystem resource agent(RS) on RHEL, hence this setup can’t be used at this moment. 

7. For SAP HANA scale-out with HSR setup

We can use Azure Files NFS EiT for SAP HANA scale-out with HSR setup as described in the below docs.

• 
  
  
  
  • SAP HANA scale-out with HSR and Pacemaker on SLES
  
  
  • SAP HANA scale-out with HSR and Pacemaker on RHEL
  
  
  
  

We need to mount ‘/hana/shared’ File system with EiT by defining the filesystem type as ‘aznfs’ in ‘/etc/fstab’. Also it’s recommended to use ‘_netdev’ in the options parameter.

For SUSE Linux:

In the Create File system resource section with SAP HANA high availability  “SAPHanaSR-ScaleOut” package, in which we create a dummy file system cluster resource, which will monitor and report failures for ‘/hana/shared’ file system, we can continue to follow the steps as it is in the above document with ‘fstype=nfs4’. ‘/hana/shared’ file system will still be using EiT as defined in ‘/etc/fstab’.

For SAP HANA high availability “SAPHanaSR-angi”, there are no further actions needed to use Azure File NFS EiT.

For RHEL Linux:

In the Create File system resource section, we can replace the file system type to ‘aznfs’ from ‘nfs’ in the pacemaker resource configuration for ‘/hana/shared’  file systems.

8. Validation of in-transit data Encryption for Azure Files NFS.

Refer to Verify that the in-transit data encryption succeeded section to check and confirm if EiT is successfully working.

Summary

Go ahead with EiT!! Simplified deployment of Encryption in Transit of Azure Files Premium NFS (Locally redundant Storage / Zonal redundant Storage) will strengthen the security footprint of Production and non-Production SAP on Azure environments.