Configure uma identidade gerenciada pelo sistema (recomendada) ou gere o arquivo de autenticação da entidade de serviço.
Quando você está validando a comunicação com o Azure NetApp Files, a comunicação pode falhar ou acabar. Verifique se as regras de firewall não estão bloqueando o tráfego de saída do sistema que executa o AzAcSnap para os seguintes endereços e portas TCP/IP:
(https://)management.azure.com:443
(https://)login.microsoftonline.com:443
Você precisará gerar seu próprio certificado autoassinado e compartilhar o conteúdo do arquivo PEM (Privacy Enhanced Mail) com o Microsoft Operations para que ele possa ser instalado no back-end do Armazenamento para permitir que o AzAcSnap se autentique com segurança com o ONTAP.
Combine o PEM e o KEY em um único arquivo PKCS12 que é necessário pelo AzAcSnap para autenticação baseada em certificado para ONTAP.
Teste o arquivo PKCS12 usando curl para se conectar a um dos nós.
O Microsoft Operations fornece o nome de usuário de armazenamento e o endereço IP de armazenamento no momento do provisionamento.
Habilitar a comunicação com o armazenamento
Esta seção explica como habilitar a comunicação com o armazenamento. Use as guias a seguir para selecionar corretamente o back-end de armazenamento que você está usando.
Há duas maneiras de autenticar no Azure Resource Manager usando uma identidade gerenciada pelo sistema ou um arquivo de entidade de serviço. As opções são descritas aqui.
Identidade gerenciada pelo sistema do Azure
No AzAcSnap 9, é possível usar uma identidade gerenciada pelo sistema em vez de uma entidade de serviço para operação. Usar esse recurso evita a necessidade de armazenar credenciais de entidade de serviço em uma VM (máquina virtual). Para configurar uma identidade gerenciada do Azure usando o Azure Cloud Shell, siga estas etapas:
Em uma sessão do Cloud Shell com o Bash, use o exemplo a seguir para definir as variáveis de shell adequadamente e aplicá-las à assinatura em que você deseja criar a identidade gerenciada do Azure. Definir SUBSCRIPTION, VM_NAMEe RESOURCE_GROUP para os valores específicos do site.
Crie a identidade gerenciada para a máquina virtual. Os seguintes conjuntos de comandos (ou mostra se ele já está definido) a identidade gerenciada da VM do AzAcSnap:
az vm identity assign --name "${VM_NAME}" --resource-group "${RESOURCE_GROUP}"
Obtenha a ID da entidade de segurança para atribuir uma função:
PRINCIPAL_ID=$(az resource list -n ${VM_NAME} --query [*].identity.principalId --out tsv)
Atribua a função colaborador à ID da entidade de segurança:
az role assignment create --assignee "${PRINCIPAL_ID}" --role "${ROLE}" --scope "${SCOPE}"
RBAC opcional
É possível limitar as permissões para a identidade gerenciada usando uma definição de função personalizada no RBAC (controle de acesso baseado em função). Crie uma definição de função adequada para que a máquina virtual possa gerenciar instantâneos. Você pode encontrar configurações de permissões de exemplo em Dicas e truques para usar a ferramenta de Instantâneo Consistente do Aplicativo do Azure.
Em seguida, atribua a função à ID da entidade de segurança da VM do Azure (também exibida como SystemAssignedIdentity):
az role assignment create --assignee ${PRINCIPAL_ID} --role "AzAcSnap on ANF" --scope "${SCOPE}"
Gerar um arquivo de entidade de serviço
Em uma sessão do Cloud Shell, verifique se você está conectado na assinatura em que deseja ser associado à entidade de serviço por padrão:
az account show
Se a assinatura não estiver correta, use o comando az account set:
az account set -s <subscription name or id>
Crie uma entidade de serviço usando a CLI do Azure, conforme mostrado neste exemplo:
az ad sp create-for-rbac --name "AzAcSnap" --role Contributor --scopes /subscriptions/{subscription-id} --sdk-auth
Esse comando atribui automaticamente a função de Colaborador do RBAC à entidade de serviço no nível da assinatura. Você pode restringir o escopo ao grupo de recursos específico em que os testes criarão os recursos.
Recortar e colar o conteúdo de saída em um arquivo chamado azureauth.json armazenado no mesmo sistema que o comando azacsnap. Proteja o arquivo com as permissões apropriadas do sistema.
Verifique se o formato do arquivo JSON é exatamente como descrito na etapa anterior, com as URLs entre aspas duplas (").
Importante
No AzAcSnap 10, a comunicação com o armazenamento de Instâncias Grandes do Azure está usando a API REST via HTTPS. As versões anteriores ao AzAcSnap 10 usam a CLI por SSH.
API REST de Instância Grande do Azure por HTTPS
A comunicação com o back-end de armazenamento ocorre em um canal HTTPS criptografado usando a autenticação baseada em certificado. As etapas de exemplo a seguir fornecem diretrizes sobre a instalação do certificado PKCS12 para esta comunicação:
Gere os arquivos PEM e KEY.
O CN é igual ao nome de usuário SVM e solicita ao Microsoft Operations esse nome de usuário SVM.
Neste exemplo, estamos usando svmadmin01 como nosso nome de usuário SVM, modifique-o conforme necessário para sua instalação.
Generating a RSA private key
........................................................................................................+++++
....................................+++++
writing new private key to 'svmadmin01.key'
-----
Produza o conteúdo do arquivo PEM.
O conteúdo do arquivo PEM é usado para adicionar o client-ca à SVM.
! Envie o conteúdo do arquivo PEM para o administrador da Infraestrutura BareMetal da Microsoft (BMI).
O arquivo svmadmin01.p12 é usado como o valor de certificateFile na seção aliStorageResource do arquivo de configuração do AzAcSnap.
Teste o arquivo PKCS12 usando curl.
Depois de obter a confirmação do Microsoft Operations, eles aplicaram o certificado à SVM para permitir o logon baseado em certificado e testar a conectividade com a SVM.
Neste exemplo, estamos usando o arquivo PKCS12 chamado svmadmin01.p12 para se conectar ao host SVM "X.X.X.X" (esse endereço IP será fornecido pela Microsoft Operations).
Essas instruções são para versões anteriores ao AzAcSnap 10 e não estamos mais atualizando esta seção do conteúdo regularmente.
A comunicação com o back-end de armazenamento ocorre em um canal SSH criptografado. As etapas de exemplo a seguir fornecem diretrizes sobre a configuração do SSH para esta comunicação:
Modifique o arquivo /etc/ssh/ssh_config.
Consulte a seguinte saída, que inclui a linha 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
Use o comando de exemplo a seguir para gerar um par de chaves privada/pública. Não insira uma senha ao gerar uma chave.
ssh-keygen -t rsa –b 5120 -C ""
A saída do comando cat /root/.ssh/id_rsa.pub é a chave pública. Envie-o para o Microsoft Operations, para que as ferramentas de instantâneo possam se comunicar com o subsistema de armazenamento.