Either set up a system-managed identity (recommended) or generate the service principal's authentication file.
When you're validating communication with Azure NetApp Files, communication might fail or time out. Check that firewall rules aren't blocking outbound traffic from the system running AzAcSnap to the following addresses and TCP/IP ports:
(https://)management.azure.com:443
(https://)login.microsoftonline.com:443
You'll need to generate your own self-signed certificate and then share the contents of the PEM (Privacy Enhanced Mail) file with Microsoft Operations so it can be installed to the Storage back-end to allow AzAcSnap to securely authenticate with ONTAP.
Combine the PEM and KEY into a single PKCS12 file which is needed by AzAcSnap for certificate-based authentication to ONTAP.
Test the PKCS12 file by using curl to connect to one of the nodes.
Microsoft Operations provides the storage username and storage IP address at the time of provisioning.
Enable communication with storage
This section explains how to enable communication with storage. Use the following tabs to correctly select the storage back end that you're using.
There are two ways to authenticate to the Azure Resource Manager using either a system-managed identity or a service principal file. The options are described here.
Azure system-managed identity
From AzAcSnap 9, it's possible to use a system-managed identity instead of a service principal for operation. Using this feature avoids the need to store service principal credentials on a virtual machine (VM). To set up an Azure managed identity by using Azure Cloud Shell, follow these steps:
Within a Cloud Shell session with Bash, use the following example to set the shell variables appropriately and apply them to the subscription where you want to create the Azure managed identity. Set SUBSCRIPTION, VM_NAME, and RESOURCE_GROUP to your site-specific values.
Create the managed identity for the virtual machine. The following command sets (or shows if it's already set) the AzAcSnap VM's managed identity:
az vm identity assign --name "${VM_NAME}" --resource-group "${RESOURCE_GROUP}"
Get the principal ID for assigning a role:
PRINCIPAL_ID=$(az resource list -n ${VM_NAME} --query [*].identity.principalId --out tsv)
Assign the Contributor role to the principal ID:
az role assignment create --assignee "${PRINCIPAL_ID}" --role "${ROLE}" --scope "${SCOPE}"
Optional RBAC
It's possible to limit the permissions for the managed identity by using a custom role definition in role-based access control (RBAC). Create a suitable role definition for the virtual machine to be able to manage snapshots. You can find example permissions settings in Tips and tricks for using the Azure Application Consistent Snapshot tool.
Then assign the role to the Azure VM principal ID (also displayed as SystemAssignedIdentity):
az role assignment create --assignee ${PRINCIPAL_ID} --role "AzAcSnap on ANF" --scope "${SCOPE}"
Generate a service principal file
In a Cloud Shell session, make sure you're logged on at the subscription where you want to be associated with the service principal by default:
az account show
If the subscription isn't correct, use the az account set command:
az account set -s <subscription name or id>
Create a service principal by using the Azure CLI, as shown in this example:
az ad sp create-for-rbac --name "AzAcSnap" --role Contributor --scopes /subscriptions/{subscription-id} --sdk-auth
The command should generate output like this example:
This command automatically assigns the RBAC Contributor role to the service principal at the subscription level. You can narrow down the scope to the specific resource group where your tests will create the resources.
Cut and paste the output content into a file called azureauth.json that's stored on the same system as the azacsnap command. Secure the file with appropriate system permissions.
Make sure the format of the JSON file is exactly as described in the previous step, with the URLs enclosed in double quotation marks (").
Important
From AzAcSnap 10, communicatoin with Azure Large Instance storage is using the REST API over HTTPS. Versions prior to AzAcSnap 10 use the CLI over SSH.
Azure Large Instance REST API over HTTPS
Communication with the storage back end occurs over an encrypted HTTPS channel using certificate-based authentication. The following example steps provide guidance on setup of the PKCS12 certificate for this communication:
Generate the PEM and KEY files.
The CN equals the SVM username, ask Microsoft Operations for this SVM username.
In this example we are using svmadmin01 as our SVM username, modify this as necessary for your installation.
Generating a RSA private key
........................................................................................................+++++
....................................+++++
writing new private key to 'svmadmin01.key'
-----
Output the contents of the PEM file.
The contents of the PEM file are used for adding the client-ca to the SVM.
! Send the contents of the PEM file to the Microsoft BareMetal Infrastructure (BMI) administrator.
The file svmadmin01.p12 is used as the value for certificateFile in the aliStorageResource section of the AzAcSnap configuration file.
Test the PKCS12 file using curl.
After getting confirmation from Microsoft Operations they have applied the certificate to the SVM to allow certificate-based login, then test connectivity to the SVM.
In this example we are using the PKCS12 file called svmadmin01.p12 to connect to the SVM host "X.X.X.X" (this IP address will be provided by Microsoft Operations).
These instructions are for versions prior to AzAcSnap 10 and we are no longer updating this section of the content regularly.
Communication with the storage back end occurs over an encrypted SSH channel. The following example steps provide guidance on setup of SSH for this communication:
Modify the /etc/ssh/ssh_config file.
Refer to the following output, which includes the MACs hmac-sha line:
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
Protocol 2
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-
cbc
# MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd
MACs hmac-sha
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
Use the following example command to generate a private/public key pair. Don't enter a password when you're generating a key.
ssh-keygen -t rsa –b 5120 -C ""
The output of the cat /root/.ssh/id_rsa.pub command is the public key. Send it to Microsoft Operations, so that the snapshot tools can communicate with the storage subsystem.