Configurez une identité managée par le système (recommandée) ou générez le fichier d'authentification du principal de service.
Lorsque vous avez validé la communication avec Azure NetApp Files, la communication peut échouer ou expirer. Vérifiez que les règles de pare-feu ne bloquent pas le trafic sortant du système exécutant AzAcSnap vers les adresses et les ports TCP/IP suivants :
(https://)management.azure.com:443
(https://)login.microsoftonline.com:443
Vous devez générer votre propre certificat auto-signé, puis partager le contenu du fichier PEM (Privacy Enhanced Mail) avec Microsoft Operations afin qu'il puisse être installé sur le back-end de stockage pour permettre à AzAcSnap de s'authentifier en toute sécurité auprès d'ONTAP.
Combinez le PEM et KEY dans un seul fichier PKCS12 qui est nécessaire par AzAcSnap pour l'authentification basée sur les certificats auprès d'ONTAP.
Testez le fichier PKCS12 à l'aide de curl pour vous connecter à l'un des nœuds.
Microsoft Operations fournit le nom d'utilisateur de stockage et l'adresse IP de stockage au moment de l'approvisionnement.
Activer la communication avec le stockage
Cette section explique comment activer la communication avec le stockage. Utilisez les onglets suivants pour sélectionner correctement le back-end de stockage que vous utilisez.
Il existe deux façons de s'authentifier auprès d'Azure Resource Manager à l'aide d'une identité managée par le système ou d'un fichier de principal de service. Les options sont décrites ici.
Identité managée par le système Azure
À partir d'AzAcSnap 9, il est possible d'utiliser une identité managée par le système au lieu d'un principal de service pour l'opération. L'utilisation de cette fonctionnalité évite la nécessité de stocker les informations d'identification du principal de service sur une machine virtuelle. Pour configurer une identité managée Azure à l'aide d'Azure Cloud Shell, procédez comme suit :
Dans une session Cloud Shell avec Bash, utilisez l'exemple suivant pour définir les variables d'interpréteur de commandes de manière appropriée et les appliquer à l'abonnement dans lequel vous souhaitez créer l'identité managée Azure. Définissez SUBSCRIPTION, VM_NAME et RESOURCE_GROUP sur vos valeurs spécifiques au site.
Définissez Cloud Shell sur l'abonnement approprié :
az account set -s "${SUBSCRIPTION}"
Créez l'identité managée pour la machine virtuelle. La commande suivante définit (ou indique s'il est déjà défini) l'identité managée de la machine virtuelle AzAcSnap :
az vm identity assign --name "${VM_NAME}" --resource-group "${RESOURCE_GROUP}"
Obtenez l'ID de principal pour l'attribution d'un rôle :
PRINCIPAL_ID=$(az resource list -n ${VM_NAME} --query [*].identity.principalId --out tsv)
Attribuez le rôle Contributeur à l'identité principale :
az role assignment create --assignee "${PRINCIPAL_ID}" --role "${ROLE}" --scope "${SCOPE}"
RBAC facultatif
Il est possible de limiter les autorisations pour l'identité managée à l'aide d'une définition de rôle personnalisée dans le contrôle d'accès en fonction du rôle (RBAC). Créez une définition de rôle appropriée pour que la machine virtuelle puisse gérer les instantanés. Vous trouverez des exemples de paramètres d'autorisations dans conseils et astuces pour utiliser l'outil Azure Application Consistent Snapshot.
Ensuite, attribuez le rôle à l'ID du principal de machine virtuelle Azure (également affiché en tant que SystemAssignedIdentity) :
az role assignment create --assignee ${PRINCIPAL_ID} --role "AzAcSnap on ANF" --scope "${SCOPE}"
Générer un fichier de principal de service
Dans une session Cloud Shell, vérifiez que vous êtes connecté à l'abonnement dans lequel vous voulez être associé au principal de service par défaut :
az account show
Si l'abonnement n'est pas correct, utilisez la commande az account set :
az account set -s <subscription name or id>
Créez un principal de service à l'aide de l'interface de ligne de commande Azure, comme illustré dans cet exemple :
az ad sp create-for-rbac --name "AzAcSnap" --role Contributor --scopes /subscriptions/{subscription-id} --sdk-auth
La commande doit générer une sortie comme cet exemple :
Cette commande affecte automatiquement le rôle Contributeur RBAC au principal de service au niveau de l'abonnement. Vous pouvez limiter l'étendue au groupe de ressources spécifique dans lequel vos tests créent les ressources.
Coupez et collez le contenu de sortie dans un fichier appelé azureauth.json stocké sur le même système que la commande azacsnap. Sécurisez le fichier avec les autorisations système appropriées.
Assurez-vous que le format du fichier JSON est exactement comme décrit à l'étape précédente, avec les URL placées entre guillemets doubles (").
Important
À partir d'AzAcSnap 10, la communication avec stockage Azure Large Instance utilise l'API REST sur HTTPS. Les versions antérieures à AzAcSnap 10 utilisent l'interface CLI via SSH.
API REST Azure Large Instance sur HTTPS
La communication avec le serveur principal de stockage se produit sur un canal HTTPS chiffré à l'aide de l'authentification basée sur des certificats. Les exemples d'étapes suivants fournissent des conseils sur la configuration du certificat PKCS12 pour cette communication :
Générez les fichiers PEM et KEY.
Le CN est égal au nom d'utilisateur SVM, demandez à Microsoft Operations pour ce nom d'utilisateur SVM.
Dans cet exemple, nous utilisons svmadmin01 en tant que nom d'utilisateur SVM, modifiez-le si nécessaire pour votre installation.
Generating a RSA private key
........................................................................................................+++++
....................................+++++
writing new private key to 'svmadmin01.key'
-----
Affichez le contenu du fichier PEM.
Le contenu du fichier PEM est utilisé pour ajouter l'autorité de certification client du SVM.
! Envoyez le contenu du fichier PEM à l'administrateur BMI (Microsoft BareMetal Infrastructure).
Le fichier svmadmin01.p12 est utilisé comme valeur pour certificateFile dans la section aliStorageResource du fichier de configuration AzAcSnap.
Testez le fichier PKCS12 à l'aide de curl.
Après avoir obtenu la confirmation de Microsoft Operations, ils ont appliqué le certificat au SVM pour autoriser la connexion basée sur un certificat, puis tester la connectivité au SVM.
Dans cet exemple, nous utilisons le fichier PKCS12 appelé svmadmin01.p12 pour nous connecter à l'hôte SVM « X.X.X.X.X » (cette adresse IP sera fournie par Microsoft Operations).
Ces instructions concernent les versions antérieures à AzAcSnap 10 et nous ne mettons plus à jour cette section du contenu régulièrement.
La communication avec le serveur principal de stockage s'exécute sur un canal SSH chiffré. Les exemples d'étapes suivants fournissent des conseils sur la configuration de SSH pour cette communication :
Modifiez le fichier /etc/ssh/ssh_config.
Reportez-vous à la sortie suivante, qui inclut la ligne de MACs hmac-sha :
# 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,umac-64@openssh.com,hmac-ripemd
MACs hmac-sha
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
Utilisez l'exemple de commande suivant pour générer une paire de clés privée/publique. N'entrez pas de mot de passe lorsque vous générez une clé.
ssh-keygen -t rsa –b 5120 -C ""
La sortie de la commande cat /root/.ssh/id_rsa.pub est la clé publique. Envoyez-le à Microsoft Operations afin que les outils d'instantané puissent communiquer avec le sous-système de stockage.