Archivi categoria: azure resource manager

Come crittografare una VM su Azure utilizzando Key Vault e lo standard BitLocker

Microsoft Azure mette a disposizione nuovi strumenti per la sicurezza dei nostri dati. Utilizzando pochi comandi PowerShell e concetti base su Key Vault in questo articolo vedremo come crittografare il disco di una VM con lo standard BitLocker.

Prerequisiti:

  • Azure PowerShell
  • Configurazione di un Key Vault

Per soddisfare i prerequisiti potete consultare il precedente articolo https://www.ictpower.it/guide/configurare-microsoft-azure-keyvault.htm

Configurare la VM

Creiamo una nuova VM associata al resource group NewResourceGroup, che avevamo creato nel precedente articolo, utilizzando Resource Manager come modello di deployment.

Figura 1: Scelta del deployment model

Figura 2: parametri per la creazione della nuova VM

Assicuriamoci che tutte le configurazioni siano relative al resource group corretto, cioè quello dentro il quale abbiamo abilitato Key Vault.

Al termine della creazione della VM, cliccando su Disks è possibile constatare che il disco non è crittografato.

Figura 3: Verifica che il disco creato non è crittografato

Scarichiamo dal repository GitHub ufficiale di Azure lo script denominato Azure Disk Encryption Prerequisite Setup, che si occuperà di soddisfare i prerequisiti necessari.

Utilizzando PowerShell ISE, configuriamo il contesto nel quale lo script verrà eseguito con i comandi:

Login-AzureRmAccount

Set-AzureRmContext -SubscriptionId <SubscriptionID>

Eseguiamo lo script:

Figura 4: Esecuzione dello script che verifica i prerequisiti per Azure Disk Encryption

Durante l’esecuzione, lo script chiederà alcune informazioni:

  • Il resource group da utilizzare
  • Il nome di una chiave; se non presente sarà creata automaticamente
  • L’area geografica
  • Il nome di un’applicazione: questa verrà usata per scrivere il segreto nel Key Vault; se non presente, verrà anch’essa creata automaticamente.

Figura 5: Inserimento dei parametri nello script di verifica

Crittografare la VM

Per crittografare la VM è necessario alcuni comandi PowerShell. Dichiariamo qual è il resource group da utilizzare e il nome della VM interessata utilizzando i comandi:

$resourceGroupName ‘NewResourceGroup’

$vmName ‘VMtestKV’

Dopo aver configurato il contesto corretto, possiamo utilizzare il seguente comando per eseguire l’azione di crittografia:

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $resourceGroupName -VMName $vmName -AadClientID $aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $keyVaultResourceId -VolumeType All

Confermiamo per concludere l’operazione:

Figura 6: richiesta di conferma prima dell’abilitazione della crittografia del disco

Al termine dell’esecuzione, lo script ritorna il seguente output:

Figura 7: Crittografia del disco completata

Verificando nuovamente nei dettagli della macchina potremo constatare che l’operazione è avvenuta correttamente.

Figura 8: Il disco della VM risulta crittografato

Conclusioni

Azure fornisce diverse soluzioni in ambito crittografico e quella descritta in questo articolo è particolarmente utile soprattutto se il monitoraggio delle macchine viene effettuato tramite Azure Security Center. Inoltre, con pochi click è possibile applicare la stessa procedura agli storage account in merito a files e blob, rispettando lo standard BitLocker e aumentando la sicurezza delle nostre infrastrutture su cloud.

Creare una connessione Site-to-Site in Microsoft Azure

Microsoft Azure è la soluzione di cloud pubblico che permette di poter eseguire facilmente gran parte dei workload aziendali utilizzando le risorse hardware messe a disposizione online. Io sono dell’idea che un cloud ibrido, in cui alcuni workload sono online ed altri sono on-premises possa essere la soluzione più interessante per le aziende italiane.

In questo articolo voglio mostrarvi come connettere la rete aziendale on-premises con la rete virtuale di Azure (VNET), in modo tale che il cloud sia una naturale estensione della nostra infrastruttura. Per poterlo fare verrà creato un tunnel VPN IPsec/IKE (IKEv1 o IKEv2) tra due dispositivi: il primo dispositivo si troverà nella nostra infrastruttura (Local Network Gateway) e sarà raggiungibile dal cloud tramite un secondo dispositivo creato su Azure (Virtual Network Gateway).

Prerequisiti

Per poter realizzare una connessione Site-to-Site tra la vostra sede aziendale e Microsoft Azure è necessario che vengano rispettati alcuni prerequisiti:

  • Avere a disposizione in azienda un dispositivo VPN compatibile
  • Un indirizzo IP IPv4 pubblico esterno per il dispositivo VPN. L’indirizzo IP non può trovarsi dietro NAT

Figura 1: Schema di funzionamento di una connessione Site-to-Site

Configurazione della connessione

Per prima cosa è necessario avere una Virtual Network (VNET) all’interno della propria sottoscrizione Azure. Alla VNET verranno collegate tutte le macchine virtuali e i servizi che volete ospitare nel cloud. Scegliete di creare una nuova Virtual Network e indicate i parametri relativi al nome della rete, allo spazio di indirizzi da utilizzare e alle sottoreti ed ovviamente alla Regione di Azure dove volete crearla, come mostrato in figura:

Figura 2: Creazione della VNET

Figura 3: VNET creata – Visualizzazione Subnet

Una volta che è stata creata la VNET sarà necessario creare una subnet per il Gateway. In genere è sufficiente utilizzare una sottorete /27 o /28. Per poterlo fare vi basterà selezionare la VNET creata e scegliere il comando per aggiungere la Gateway Subnet. Il Nome per la subnet verrà compilato automaticamente con il valore ‘GatewaySubnet’. Questo valore è obbligatorio per consentire ad Azure di riconoscere la subnet come GatewaySubnet, quindi non modificatelo.

Figura 4: Aggiunta della Gateway Subnet

A questo punto siete pronti per la creazione del Gateway, che farà da Endpoint per la connessione VPN. Si tratta di due macchine virtuali messe in alta disponibilità e create da Microsoft che assicureranno la connessione con il dispositivo VPN che avere in casa.

Cliccate su Nuovo (+) à Networking à Virtual Network Gateway ed inserite i dati richiesti: nome, tipo di Gateway, SKU, Virtual Network a cui associarlo e indirizzo IP pubblico, come mostrato in figura:

Figura 5: Creazione del Virtual Network Gateway

Quando si crea il Virtual Network Gateway è necessario specificare un tipo di VPN. Il tipo di VPN scelto dipende dal tipo di connessione che si desidera creare. Ad esempio, una connessione Point-to-Site (P2S) richiede obbligatoriamente un tipo di VPN RouteBased. Dopo avere creato un gateway non è possibile modificare il tipo di VPN. È necessario eliminare il gateway e ricrearne uno nuovo. Lo SKU del Gateway VPN stabilisce il numero massimo di connessioni e la velocità effettiva aggregata. Attualmente sono disponibili le seguenti configurazioni:

SKU

Tunnel S2S/
rete virtuale-rete virtuale

Connessioni
P2S

Velocità effettiva
aggregata

VpnGw1

Max. 30

Max. 128

500 Mbps

VpnGw2

Max. 30

Max. 128

1 Gbps

VpnGw3

Max. 30

Max. 128

1,25 Gbps

Basic

Max. 10

Max. 128

100 Mbps

Per maggiori informazioni potete visitare la pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings#gwsku

La creazione del gateway può richiedere fino a 45 minuti. Nell’attesa potete procedere alla creazione del Local Network Gateway, che rappresenta il dispositivo VPN che avete in azienda e che volete usare per la connessione Site-to-Site. Per crearlo è sufficiente cliccare su Nuovo (+) à Networking à Local network gateway e compilare i campi indicando la rete (o le reti) presente in azienda e l’indirizzo IP pubblico del dispositivo VPN aziendale, come mostrato in figura:

Figura 6: Creazione del Local Network Gateway

Dopo aver atteso il completamento della creazione del Virtual Network Gateway, siamo pronti per creare la connessione Site-to-Site. Selezionate il Gateway e nel tab Settings cliccate su Connections, come mostrato in figura:

Figura 7: Scheda Connections del gateway VPN appena creato

Cliccando su Add avrete la possibilità di scegliere il Tipo di connessione, il Local Network Gateway e la Pre-Shared Key (PSK) necessaria a configurare la connessione IPSEC/IKE, come mostrato in figura:

Figura 8: Configurazione della connessione Site-To-Site

A questo punto il Gateway avrà lo Status Connecting fino a quando non avrete configurato il dispositivo in azienda.

Figura 9: Creazione VPN Site-to-Site completata

Configurazione del dispositivo VPN aziendale

Maggiori informazioni su come configurare i dispositivi VPN e sui parametri IPsec/IKE per le connessioni del Gateway VPN possono essere visualizzate alla pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices . Microsoft ha predisposto un elenco dei dispositivi VPN dei maggiori vendor con relativa configurazione.

Personalmente nei miei laboratori utilizzo come endpoint Microsoft RRAS installato su Windows Server 2012 R2. È possibile configurarlo manualmente per la connessione IKEv2 oppure potete trovare uno script di configurazione al link https://github.com/Azure/Azure-vpn-config-samples/tree/master/Microsoft

Conclusioni

La connessione VPN Site-to-Site ci permette di poterci collegare alle VNET create in Microsoft Azure ed utilizzare il cloud come estensione delle nostre reti aziendali, dandoci di fatto l’opportunità di accedere alle notevoli risorse di calcolo offerte, come se fossero disponibili in azienda.

Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3

Sono disponibili solo da un paio di giorni (e non in tutte le Regioni di Azure) le nuove macchine virtuali della Serie Dv3 ed Ev3. Queste macchine virtuali sono le prime ad essere ospitate su host Hyper-V basati su Windows Server 2016 e sono le prime che usano la tecnologia Hyper-Threading.

L’utilizzo dell’Hyper-Threading permetterà di creare macchine virtuali con più core e quindi migliorerà le performance e l’efficienza delle VM. I processori utilizzati sono Intel® Broadwell E5-2673 v4 2.3GHz e Intel® Haswell 2.4 GHz E5-2673 v3.

Grazie all’host Windows Server 2016 è adesso possibile abilitare la Nested Virtualization, che permette di poter eseguire il ruolo di Hyper-V anche in una macchina virtuale e di farci girare macchine virtuali annidate oppure Hyper-V Containers. Per maggiori informazioni su cosa sia la virtualizzazione annidata e come abilitarla in Windows Server 2016 vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Alla pagina https://azure.microsoft.com/it-it/blog/introducing-the-new-dv3-and-ev3-vm-sizes/ potrete trovare un elenco dettagliato delle nuove VM disponibili, dei tagli previsti e delle Regioni dove attualmente sono abilitate.

Creazione di una nuova VM di tipo Ev3 su Azure

Per poter sfruttare la Nested Virtualization è necessario creare una macchina virtuale di tipo Dv3 oppure Ev3 in una delle regioni abilitate. Io ho deciso di utilizzare una macchina E4s_v3 e l’ho creata in West Europe, scegliendo come sistema operativo Windows Server 2016.

Figura 1: Creazione della VM in West Europe

Figura 2: Scelta della dimensione della VM

Figura 3: Configurazione dello storage, della rete e dell’IP pubblico della VM

Figura 4: Schermata riassuntiva con le scelte selezionate

Al termine della creazione della VM potete collegarvi in desktop remoto per configurarla. Dal Server Manager aggiungete il ruolo di Hyper-V e vedrete che non riceverete nessun messaggio di errore, come mostrato in figura:

Figura 5: Abilitazione del ruolo Hyper-V nella nested VM in Azure

Abilitazione della Nested Virtualization

Per semplificare l’abilitazione e la creazione di macchine virtuali annidate, potete scaricare uno script in PowerShell realizzato da Charles Ding, ingegnere del gruppo di sviluppo Microsoft Azure, all’indirizzo https://aka.ms/azurenestedvirtualization. Lo script vi permetterà di configurare il ruolo di Hyper-V e tutte le altre caratteristiche necessarie alla creazione della Nested VM.

Eseguite lo script in PowerShell ISE (lanciato con privilegi elevati) e la prima volta lo script provvederà ad installare il ruolo di Hyper-V, come mostrato in figura:

Figura 6: Esecuzione dello script che installa Hyper-V e che crea la VM annidata

L’installazione di Hyper-V richiede un paio di riavvii, quindi verrete disconnessi dal desktop remoto. Dopo qualche minuto, potrete ricollegarvi e rilanciare lo script per creare la VM. Modificate il valore $VMName “NestedVM-Level2” scegliendo il nome che volete assegnare alla vostra Nested VM e rilanciate lo script. Lo script verificherà che i prerequisiti sia tutti rispettati e creerà la macchina virtuale, abilitando tutte le estensioni necessarie alla virtualizzazione annidata, come mostrato in figura:

Figura 7: Lo script ha creato la VM annidata

Dopo aver avviato la VM annidata, nel mio caso chiamata NestedVM-Level2, potete installare il sistema operativo, come mostrato in figura:

Figura 8: Accensione della nested VM e installazione del sistema operativo

Se volete permette alla macchina annidata di navigare, poiché il MAC Address spoofing non è abilitato su Azure per motivi di sicurezza, sarà necessario creare una rete NAT nell’hypervisor (la VM su Azure) e poi assegnare alla Nested VM un indirizzo statico oppure potete usare il DHCP.

Per prima cosa create nella macchina “host” (la VM su Azure) un nuovo internal switch chiamato NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione di uno switch di tipo Internal

New-VMSwitch -SwitchName “NAT” -SwitchType Internal

Con il comando Get-NetAdapter individuate l’indice assegnato alla nuova interfaccia di rete creata

Figura 9: Interfaccia di rete creata dallo switch di tipo Internal

A questo punto potete assegnare alla nuova scheda di rete un indirizzo IP statico (nel mio caso ho scelto 192.168.0.1), che poi verrà utilizzato dalla nested VM come gateway:

#Assegnazione dell’IP alla nuova interfaccia (sarà il gateway della rete)

New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13

Figura 10: Assegnazione dell’IP statico alla nuova interfaccia di rete

Create la rete di NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione della rete di NAT

New-NetNat -Name NATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24

Adesso che avete completato la configurazione della rete potete collegare la Nested VM al virtual switch NAT che avete creato in precedenza, come mostrato in figura:

Figura 11: La nested VM viene collegata al virtual switch chiamato NAT

Potete installare sulla macchina Azure il servizio DHCP e quindi fare in modo che gli indirizzi vengano assegnati automaticamente. In alternativa potete configurare la scheda di rete della Nested VM con un IP statico, come mostrato in figura:

Figura 12: Configurazione dell’IP statico nella Nested VM

Come è possibile vedere dalla figura sotto, adesso la Nested VM è in grado di navigare in Internet.

Figura 13: La nested VM è connessa ad Internet

Conclusioni

La Nested Virtualization su Azure permette di utilizzare la nuova funzionalità di Windows Server 2016 e di eseguire macchine virtuali annidate oppure gli Hyper-V Containers di Docker. Un possibile caso d’uso della virtualizzazione annidata potrebbe essere la configurazione di un laboratorio di Hyper-V in un ambiente virtualizzato e il test di scenari a più computer (come ad esempio un cluster) senza la necessità di avere dei server fisici.

Configurare Microsoft Azure KeyVault

Azure KeyVault è un sistema di gestione di chiavi crittografiche e relativi segreti adoperati da applicazioni e servizi su Azure.

Con KeyVault è possibile crittografare chiavi di autenticazione, certificati .pfx, password ecc., utilizzando anche HSM.

Questo piccolo articolo è un’introduzione al concetto di sicurezza su Cloud e analizzerà come far comunicare un’applicazione con un’infrastruttura su Azure, attraverso l’utilizzo di una chiave crittografata. Tale configurazione viene effettuata tramite Azure PowerShell.

Per informazioni sui costi: https://azure.microsoft.com/it-it/pricing/details/key-vault/

Per velocizzare le cose utilizzeremo un’applicazione d’esempio che Microsoft mette a disposizione: https://www.microsoft.com/en-us/download/details.aspx?id=45343

Installare Azure PowerShell da PowerShell Gallery

Verifichiamo l’installazione di PowerShellGet:

Get-Module PowerShellGet -list Select-Object Name,Version,Path

Se il risultato è quanto segue, abbiamo già cosa serve:

In caso contrario, installiamo il seguente update:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Eseguendo PowerShell come amministratore, lanciamo il comando:

Install-Module AzureRM

Nel caso in cui fosse la prima volta che utilizziamo PowerShell Gallery, ci verrà richiesta una conferma prima di installare il modulo.

Confermiamo quindi l’installazione e, una volta terminata, importiamo i nuovi moduli con il comando:

Import-Module AzureRM

A questo punto siamo pronti per iniziare!

Configurare il KeyVault

Il primo passo consiste nell’effettuare il login alla propria sottoscrizione su Azure:

Login-AzureRmAccount

Selezioniamo la specifica sottoscrizione con i comandi:

Get-AzureRmSubscription

Set-AzureRmContext -SubscriptionId <subscription ID>

Creiamo un nuovo Resource Group, che con molta poca fantasia chiameremo “NewResourceGroup”, nel quale effettuare le nostre configurazioni:

New-AzureRmResourceGroup –Name ‘NewResourceGroup’ –Location ‘West Europe’

A questo punto possiamo creare un nuovo KeyVault associato al resource group:

New-AzureRmKeyVault -VaultName ‘FKeyVault’ -ResourceGroupName ‘NewResourceGroup’ -Location ‘West Europe’


L’output di quest’ultimo comando mostra una delle proprietà più importanti: il Vault URI. Tutte le applicazioni che dovranno utilizzare il nuovo KeyVault attraverso le API Rest lo faranno attraverso questo URI.

Aggiungiamo una key al nostro KeyVault:

$key Add-AzureKeyVaultKey -VaultName ‘FKeyVault’ -Name ‘NewKey’ -Destination ‘Software’

Per verificare l’URI, utilizziamo il comando:

$Key.key.kid


Per configurare una stringa a questa chiave, ad esempio una password chiamata “Segreto” il cui valore è “123password”, è necessario effettuare due operazioni:

  • convertire la stringa in una stringa sicura;
  • associare la stringa sicura alla chiave.

$secretval ConvertTo-SecureString ‘123password’ -AsPlainText –Force

$secret Set-AzureKeyVaultSecret -VaultName ‘FKeyVault’ -Name ‘Segreto’ -SecretValue $secretval

Per verificarne l’URI:

$secret.Id


Per verificare quanto appena configurato:

Get-AzureKeyVaultKey –VaultName ‘NKeyVault’

Get-AzureKeyVaultSecret –VaultName ‘NKeyVault’

Configurare l’applicazione

Dopo aver scaricato l’applicazione d’esempio, apriamo la solution con Visual Studio


Contestualmente nella directory scripts troveremo lo script GetAppConfigSettings.ps1 da modificare ed eseguire.


È sufficiente modificare le prime righe configurando ciò che abbiamo appena creato:

  • Nome del KeyVault
  • Nome del Resurce Group
  • Nome dell’applicazione


Eseguiamo lo script.

Quando richiesto, inseriamo una password per il certificato.

Al termine dell’esecuzione dello script in output avremo delle chiavi da inserire all’interno del file app.config dell’applicazione.


Caricando lo snap-in dei certificati relativi all’account locale è possibile comprovare l’avvenuta creazione del certificato, senza il quale l’applicazione non sarà in grado di verificare le credenziali su Azure.


Le applicazioni che utilizzano KeyVault devono autenticarsi utilizzando un token generato da Active Directory, nel nostro caso Azure Active Directory.

Per farlo, clicchiamo su “Azure Active Directory”, successivamente su “App registrations” e cerchiamo la nostra applicazione HelloKeyVault.


Abilitiamo l’applicazione all’utilizzo della chiave copiando il clientID (Application ID) e utilizziamo il seguente comando:

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘FKeyVault’ -ServicePrincipalName 341efa38-faf5-459e-903a-05e9a5ad7309 -PermissionsToKeys all

Per verificare che tutto sia andato a buon fine proviamo a eseguire l’applicazione dal sistema in cui è installato il certificato. In questo modo vedremo come questa utilizzi il KeyVault generato e la relativa chiave, con la possibilità di eseguire tutte le operazioni che il KeyVault stesso mette a disposizione:


Conclusioni

La sicurezza è sempre una tematica attuale e, spesso, sottovalutata.

In questo contesto, Azure fornisce delle soluzioni pratiche anche per quei clienti spaventati dall’avere i propri dati sul Cloud.

Fornire agli sviluppatori delle chiavi crittografate, centralizzandone la gestione e mantenendo uno standard di sicurezza adeguato è solo uno dei pregi di questa soluzione, benché sia facilmente intuibile di aver trattato solo scalfito la superficie di quest’ampia tematica.

Configurare diversi indirizzi IP per la stessa scheda di rete nelle VM in Microsoft Azure

Una delle novità più interessanti in ambito Networking riguardo Microsoft Azure è stata presentata pochi giorni fa nell’annuncio General availability: Multiple IP addresses per network interface

Trovo questa funzionalità particolarmente interessante perché risolve diversi problemi che mi avevano posto alcuni clienti. Ad esempio una web agency che ha creato diversi web server in Microsoft Azure ha bisogno di far girare diversi siti web e servizi con differenti indirizzi IP e certificati digitali sulla stessa scheda di rete della VM.

Questo tipo di funzionalità è utilizzabile per poter creare dei bilanciatori di carico o dei firewall utilizzando macchine virtuali gestite da noi.

È anche disponibile da pochissimi giorni la possibilità di avere almeno due schede di rete in tutte le macchine virtuali (Windows e Linux) create in Azure, come annunciato in General availability: Dual network interfaces for all Azure VMs

Per poter assegnare alla stessa scheda di rete due indirizzi IP diversi è sufficiente collegarsi al portale di Azure, selezionare la VM da modificare e cliccare sulla scheda di rete utilizzata dalla VM, come mostrato in figura:

Figura 1: Selezione dell’interfaccia di rete da modificare per la VM

Dopo aver cliccato sull’interfaccia di rete interessata, nel nuovo blade che vi si aprirà selezionate IP Configurations e cliccate sul pulsante Add per aggiungere un nuovo indirizzo, come mostrato in figura:

Figura 2: Blade IP Configurations per la scheda da modificare

Nel Blade Add IP configuration scegliete un nome simbolico per l’indirizzo IP da aggiungere, scegliete se volete mantenere statico o dinamico l’indirizzo IP privato (vi consiglio di mantenerlo statico) e successivamente scegliete se volete abilitare l’indirizzo IP Pubblico, come mostrato in figura:

Figura 3: Aggiunta del secondo indirizzo IP pubblico

Una volta completata la procedura ed assegnato il nome al secondo indirizzo IP pubblico vi verrà mostrata la schermata con gli indirizzamenti per la vostra scheda di rete, come mostrato in figura:

Figura 4: Indirizzamenti IP privati e pubblici per la scheda di rete della VM

Avete un numero limitato di indirizzi IP privati e pubblici da assegnare, come documentato dall’articolo https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits

Per completare l’operazione è necessario collegarsi in desktop remoto alla macchina virtuale ed assegnare gli indirizzi privati manualmente. Se infatti eseguite il comando ipconfig /all all’interno della VM vedrete che verrà visualizzato solo l’indirizzo primario, come mostrato in figura:

Figura 5: Presenza solo dell’indirizzo Primario assegnato alla scheda di rete della VM

Modificate le proprietà della scheda di rete aggiungendo manualmente gli indirizzi IP interni che avete assegnato staticamente nel portale di Azure, come mostrato in figura:

Figura 6: Assegnazione statica degli indirizzi privati scelti

Dopo aver assegnato gli indirizzi (attenti a non sbagliare perché altrimenti non vi riconnetterete più alla VM) la connessione in desktop remoto potrebbe disconnettersi per un secondo, ma poi sarete nuovamente collegati.

Rilanciando il comando ipconfig /all potrete verificare che adesso la scheda di rete ha i due IP interni che avete assegnato, come mostrato in figura:

Figura 7: Scheda di rete con doppio indirizzo IP interno

La macchina virtuale sarà raggiungibile in Desktop remoto su tutti gli indirizzi pubblici che avete assegnato, in quanto le regole di firewall sono definite dallo stesso Network Security Group.

Volendo è possibile dare un’occhiata alle proprie configurazioni di rete utilizzando lo strumento Network Watcher, che è possibile abilitare per ogni regione. Cliccate su Monitor nella Dashboard e abilitate il Network Watcher per le regioni disponibili per la vostra sottoscrizione.

Figura 8: Abilitazione del Network Watcher

Tra le funzionalità messe a disposizione del Network Watcher c’è la visualizzazione della Topologia del proprio scenario di rete, che mostra le varie interconnessioni e le associazioni tra le risorse di rete in un gruppo di risorse. Dal menù a tendina in alto scegliete la vostra sottoscrizione, il resource group e la scheda di rete da monitorare e vi verrà creata automaticamente la topologia di rete, con le diverse connessioni, come mostrato in figura:

Figura 9: Topologia di rete creata col Network Watcher

Conclusioni

La possibilità di avere due schede di rete su tutte le macchine virtuali in Azure e assegnare alla stessa scheda di rete diversi indirizzi IP, sia pubblici che privati, ci permette di implementare degli scenari di networking anche complesso che finora non era possibile realizzare. Creare bilanciatori di carico e firewall con le macchine virtuali su Azure non è mai stato così facile!

Configurazione di macchine Linux su Azure tramite DSC

In un articolo precedente (https://www.ictpower.it/guide/installare-e-configurare-powershell-desired-state-configuration-for-linux.htm) abbiamo visto come configurare un ambiente per il deploy automatico di packages tramite Desired State Configuration for Linux su client e server nella nostra rete locale.

Vediamo cosa succede nel caso in cui l’esigenza è quella di configurare delle macchine linux che si trovano invece sul cloud di Microsoft, da tutti conosciuto con il nome di Azure. Per questo esempio utilizzeremo una macchina Debian, creandola utilizzando uno dei template disponibili; per creare le risorse su Azure è necessario possedere una sottoscrizione attiva.

Iniziamo proprio creando le risorse necessarie su Azure, effettuiamo quindi il login su https://portal.azure.com e selezioniamo dal menu:

Nuovo -> Calcolo -> Ubuntu Server 16.04 LTS

Quindi facciamo click su Crea per avviare la configurazione di una macchina virtuale Ubuntu.

Un semplice wizard richiederà di compilare tutte le informazioni necessarie, quali tecnologia dei dischi da utilizzare, nome macchina, modalità di autenticazione e gruppo di risorse a cui associare la VM. Sceglieremo poi le risorse hardware, la configurazione della rete ed eventuali servizi aggiuntivi. In pochi minuti una notifica sulla pagina web del portale ci informerà del completamento dell’operazione, e la nostra macchina sarà raggiungibile tramite collegamento ssh direttamente sull’ip pubblico assegnato.

Il wizard chiede di assegnare un nome al gruppo di risorse che conterrà la macchina Ubuntu e tutti i servizi correlati (storage, rete, ecc…); questo nome verrà utilizzato in seguito per creare altre risorse. Per il mio esempio il nome del gruppo di risorse è LinuxDSC.

Allo stato attuale le versioni di OMIserver e dell’agent DSC non permettono il deploy corretto delle configurazioni nel caso queste prevedano l’installazione di pacchetti software. Essendo il nostro scopo proprio quello di installare dei servizi sulla macchina linux remota, è neccessario procedere all’aggiornamento dei due pacchetti. L’operazione è molto semplice e possiamo effettuarla direttamente connettendoci via SSH alla macchina remota. Io ho utilizzato Windows Bash, ma possiamo utilizzare putty o un qualsiasi altri client ssh.

Connettiamoci via SSH quindi all’IP pubblico che troviamo sul portale Azure, relativo alla nostra VM, ed eseguiamo sulla macchina linux i seguenti comandi per scaricare nella cartella /tmp le versioni (ad oggi) più recenti di OMI server e PowerShell DSC:

sudo wget https://github.com/Microsoft/omi/releases/download/v1.1.0-0/omi-1.1.0.ssl_100.x64.deb -P /tmp

sudo wget https://github.com/Microsoft/PowerShell-DSC-for-Linux/releases/download/v1.1.1-294/dsc-1.1.1-294.ssl_100.x64.deb -P /tmp

e li installiamo con:

sudo dpkg -i /tmp/omi-1.1.0.ssl_100.x64.deb /tmp/dsc-1.1.1-294.ssl_100.x64.deb

Possiamo verificare di avere le versioni corrette con i comandi:

sudo dpkg -l | grep dscsudo dpkg -l | grep omi

 

E’ possibile anche avviare una sessione SSH utilizzando PowerShell, ma è necessario installare un modulo aggiuntivo chiamato Posh-SSH, per aggiungere il supporto a questo protocollo. Il modulo è eventualmente disponibile sul sito PowerShell Gallery a questo indirizzo:

https://www.powershellgallery.com/packages/Posh-SSH/1.7.7

Per l’installazione, in ogni caso, è sufficiente aprire PowerShell come amministratore ed eseguire:

Install-Module -Name Posh-SSH

Volendo utilizzare i cmd-let di PowerShell per gestire la nostra sottoscrizione Azure abbiamo bisogno di installare anche i moduli Azure PowerShell, scaricando ed installando il pacchetto disponibile a questo link:

http://aka.ms/webpi-azps

A questo punto possiamo effettuare il login su Azure utilizzando ilcomando

Add-AzureRmAccount

Dopo aver inserito le credenziali, PowerShell ci risponde con i dettagli della sottoscrizione:

Nel caso esistano più sottoscrizioni con lo stesso account possiamo selezionare quella da utilizzare con i seguenti comandi:

#Connessione ad Azure

Add-AzureRmAccount

#Selezione subscription

$subscription (Get-AzureRmSubscription  Out-GridView -Title ‘Select an Azure Subscription …’  -PassThru)

Set-AzureRmContext -SubscriptionId $subscription.subscriptionId -TenantId $subscription.TenantID

E’ necessario quindi creare un ulteriore “Account di archiviazione” o “Storage Account” per ospitare le configurazioni DSC. Utilizziamo anche qui Azure PowerShell specificando il nome del nostro Resource Group, il nome del nuovo storageaccount da creare e la location. I valori disponibili per la variabile $Location ad oggi sono i seguenti: eastus, eastus2, eastus2stage, westus, westeurope, eastasia, southeastasia, japaneast, japanwest, northcentralus, southcentralus, centralus, northeurope, brazilsouth, australiaeast, australiasoutheast, southindia, centralindia, westindia, canadaeast, canadacentral, westus2, westcentralus, uksouth, ukwest, koreacentral, koreasouth

$ResourceGroupName “LinuxDSC”

$storageaccountName “dscdisk”

$Location “westeurope”

New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $storageaccountName -Type Standard_LRS -Location $Location

Al termine dell’elaborazione ci verrà restituito un messaggio di conferma

Possiamo verificare che il nuovo storage account è disponibile sul portale Azure:

Creiamo ora un container all’interno dello storage account; per non appesantire la guida creiamo il container con “Permission -Off” rendendo accessibile il container solo al proprietario. Essendo le variabili già definite eseguiamo:

Set-AzureRmCurrentStorageAccount -ResourceGroupName $ResourceGroupName -Name $storageaccountName

New-AzureStorageContainer -Name linuxdsc -Permission Off

Il container è subito disponibile, e ce lo conferma la risposta nella PowerShell

Ora prepariamo la nostra macchina per eseguire il push della configurazione, nel mio caso sto utilizzando una macchina con Windows 10 Pro. Abbiamo bisogno di installare il modulo DSC for Linux, quindi eseguiamo da una PowerShell con diritti amministrativi il comando:

Install-Module –name nx

In alternativa è possibile effettuare il download del pacchetto MSI da:

https://www.microsoft.com/en-us/download/details.aspx?id=46919

ed installarlo utilizzando le opzioni predefinite. L’installazione provvederà ad aggiungere il modulo nx, necessario per l’utilizzo di DSC for Linux nella cartella

%USERPROFILE%\Documents\WindowsPowerShell\Modules

Tutto è pronto per la preparazione di uno script di configurazione, che per l’occasione consisterà nell’installazione automatizzata del servizio httpd sulla nostra macchina Azure con sistema operativo Ubuntu. Lo script è molto semplice, e va eseguito direttamente da PowerShell. Consiste in una prima parte di dichiarazione della configurazione ed una seconda in cui viene eseguito il comando per generare il file .mof che DSC utilizzerà per eseguire il push sulla macchina remota.

Personalmente ho avuto un po’ di problemi nell’incollare lo script nella finestra PowerShell poiché venivano stranamente aggiunti caratteri in modo casuale corrompendo il testo incollato. Non sapendo se il problema dipende da qualcosa di particolare nella mia situazione, mostro comunque il workaround utilizzato.

Ho incollato lo script direttamente nell’ISE e salvato in formato .ps1, quindi ho richiamato l’esecuzione dello script direttamente da PowerShell. Per aprire l’ISE è sufficiente cercare PowerShell ISE nella barra della ricerca di Windows, o lanciare il comando ISE da PowerShell.

Lo script utilizzato è il seguente:

Configuration
ubuntuconf {


Import-DscResource -Module nx


Node “localhost” {

    nxPackage
Apache {

        PackageManager ‘Apt’

        Ensure ‘Present’

        Name ‘apache2’

    }

}

}

ubuntuconf -OutputPath: “C:\temp”

Salviamo lo script ad esempio con il nome conf.ps1 e lo eseguiamo da PowerShell:

.\conf.ps1

Verrà creato un file chiamato <nomehost>.mof nella directory indicata nello script; questo file è il modello che DSC confronterà con lo stato attuale della macchina da configurare, effettuando in maniera automatizzata le eventuali operazioni di adeguamento. Nel nostro caso, ad esempio, si assicurerà che il pacchetto apache2 sia installato.

Trasferiamo questo file all’interno del container che abbiamo creato su Azure con il comando PowerShell:

Set-AzureStorageBlobContent -Container linuxdsc -File C:\temp\localhost.mof

Anche in questo caso possiamo verificare dal portale Azure che il nostro contenitore include il file .mof che abbiamo appena inviato

Ora è necessario configurare i privilegi di accesso su questo file per fare in modo che la nostra macchina Ubuntu sia in grado di leggerlo. A costo di complicare un po’ la procedura evitiamo di ottenere un link pubblico impostando l’accesso con autenticazione tramite Shared Access Signatures (SAS), creando un opportuno token. Possiamo impostare un limite di tempo per la validità di questo token, e per questo esempio imposteremo 1 mese.

$templateuri New-AzureStorageBlobSASToken -Container linuxdsc -Blob ‘localhost.mof’ -Permission -ExpiryTime (Get-Date).AddMonths(1) -FullUri

Il comando

echo $templateuri

ci restituirà il valore da utilizzare nello script DSC descritto successivamente. Infine otteniamo l’elenco delle chiavi disponibili con il commando:

Invoke-AzureRmResourceAction -ResourceGroupName $ResourceGroupName -ResourceType Microsoft.Storage/storageAccounts -ResourceName $StorageAccountname -Action listKeys -ApiVersion 2015-05-01-preview -Force -OutVariable keys

Essendo sufficiente al nostro scopo la key1, per ottenere la chiave da utilizzare nel prossimo script possiamo eseguire eseguire da PowerShell:

$keys[0].key1

Siamo pronti quindi ad effettuare il deploy della nostra configurazione eseguendo uno script PowerShell DSC; per personalizzare lo script abbiamo bisogno di tenere presente le variabili relative allo storage account ed alle chiavi che permettono la lettura del file mof. Le variabili sono:

StorageAccountName (il nome dell’account archivio creato nel primo step), StorageAccountKey (La key1 restituita dal comando precedente), FileUri (Il valore restituito dopo l’upload del file mof), vmname (il nome della risorsa della macchina virtuale su Azure)

Eseguiamo il cmd-let per conoscere l’ultima versione di DSCforLinux disponibile

$extensionName ‘DSCForLinux’

$publisher ‘Microsoft.OSTCExtensions’

Get-AzureRmVMExtensionImage -PublisherName Microsoft.OSTCExtensions -Location $location -Type DSCForLinux

E settiamo la variabile version utilizzando questa versione

$version ‘2.2’

Poi settiamo le variabili relative all’autenticazione:

$privateConfig 

‘{

“StorageAccountName”: “linuxdsc”,

“StorageAccountKey”: “//storageaccountkey//”

}’

$publicConfig ‘{

“Mode”: “Push”,

“FileUri”: “//fileuri//”

}’

E finalmente lanciamo il deploy del modello che avevamo creato sulla vm Linux su Azure, avendo cura di settare la variabile $vmName indicando il nome della VM su Azure, nel mio caso:

$vmName=“LNXClient01”

Set-AzureRmVMExtension -ResourceGroupName $ResourceGroupName -VMName $vmName -Location $location -Name $extensionName -Publisher $publisher -ExtensionType $extensionName -TypeHandlerVersion $version -SettingString $publicConfig -ProtectedSettingString $privateConfig

Un messaggio di OK ci conferma l’avvenuto deploy della configurazione. In questo caso abbiamo installato il pacchetto apache2 (Webserver apache) sulla nostra macchina di test.

Nel caso si verificassero degli errori è possibile analizzare i log direttamente sulla macchina Linux; possiamo trovare informazioni dettagliate sulle operazioni relative a DSC nel file /var/log/azure/DSCForLinux/<versione>/extension.log

Per verificare il funzionamento del servizio creiamo dal portale Azure una regola di firewall all’interno delle risorse di tipo “Gruppo sicurezza di rete” per consentire le connessioni sulla porta 80 (servizio http), e proviamo ad aprire un browser navigando direttamente sull’ip pubblico della nostra macchina.

Il webserver è attivo e raggiungibile dall’esterno

Possiamo ora divertirci a provare infinite configurazioni, ricordando che DSC è in grado di effettuare tantissime operazioni sulla macchina client, fra le quali gestione di file e cartelle, installazione e rimozione di pacchetti, gestione gruppi e utenti ed esecuzione di script.

Personalmente credo che questa funzionalità abbia un potenziale davvero enorme, e sembra quasi incredibile come su una infrastruttura proprietaria Microsoft sia possibile utilizzare servizi di automazione completamente Open Source.

Implementare il Single Sign-On (SSO) con Azure AD

La maggior parte degli utenti vuole utilizzare un’unica password per poter accedere sia all’Active Directory locale che ai servizi che usano Azure AD, come ad esempio Office 365. Abbiamo visto in un precedente articolo, Come funziona Azure AD Pass-through Authentication, come poter fare in modo che l’autenticazione avvenga utilizzando il domain controller locale, nel caso non vogliamo replicare le nostre password in Azure AD. Utilizzare la stessa username e password sia all’interno che all’esterno della propria infrastruttura aziendale prende il nome di SAME SIGN-ON.

In questo articolo vedremo invece come implementare il SINGLE SIGN-ON (SSO), un’opzione che consente agli utenti di non dover digitare la password, ma solo il nome utente, per accedere ad Azure Active Directory.

SSO è una funzionalità che viene abilitata tramite il tool Azure AD Connect e funziona sia con la sincronizzazione delle password sia con l’autenticazione pass-through. Questo tipo di funzionalità però è disponibile solo se il computer da cui effettuiamo la connessione è joinato al dominio.

Vantaggi del Single Sign-on con autenticazione Pass-through di Azure AD

Sicuramente tra i vantaggi più evidenti di questo tipo di autenticazione spicca quello di evitare l’uso dei Federation Services, che prevedono una farm di almeno 2 Server ADFS nel Backend e 2 Server Web Application Proxy nella DMZ, per un totale di 4 server! Per avere un’idea di quanto sia complicata l’infrastruttura che usa ADFS potete dare un’occhiata all’articolo Checklist: Use AD FS to implement and manage single sign-on.

Come funziona

Il principio di funzionamento del Single Sign-On con Azure AD è molto semplice. Quando l’utente tenta di accedere ad una risorsa che usa Azure AD per l’autenticazione, come ad esempio il portale di Office 365, gli vengono chieste le credenziali. L’utente viene reindirizzato al portale di autenticazione https://login.microsoftonline.com e dopo aver inserito la propria username, viene reindirizzato verso il proprio domain controller. Active Directory restituisce un ticket Kerberos al client. Il client invia il ticket Kerberos acquisito da Active Directory ad Azure AD. Azure AD decrittografa il ticket Kerberos e restituisce un token all’utente, che lo riutilizza per poter accedere alla risorsa, come ad esempio il portale di Office365.

Il tutto avviene in maniera completamente trasparente per l’utente, che dopo aver inserito la username si ritrova autenticato senza aver dovuto inserire la password.

Figura 1: Principio di funzionamento del Single Sign-On (SSO)

Abilitazione di SSO con autenticazione pass-through

Single Sign-On è un’opzione che può essere abilitata utilizzando il tool Azure AD Connect tramite sincronizzazione delle password o autenticazione pass-through.

In questo articolo ci occuperemo di implementare il SSO con l’autenticazione pass-through.

Procediamo all’installazione di Azure AD Connect scaricando l’eseguibile dal link http://go.microsoft.com/fwlink/?LinkId=615771 e lanciamo il setup

Figura 2: Setup di Azure AD Connect

Scegliamo di installare Azure AD Connect in modalità personalizzata, cliccando su Customize, e nella schermata successiva facciamo clic su Install.

Figura 3: Installazione dei prerequisiti di Azure AD Connect

Dopo l’installazione dei componenti necessari, viene richiesta la selezione del metodo di accesso degli utenti. Scegliamo quindi la modalità Pass-Through Authentication e mettiamo il segno di spunta su Enable single sign-on, come mostrato in figura:

Figura 4: Single Sign-On con autenticazione pass-through

Inseriamo a questo punto le credenziali da Global Admin del nostro Tenant di Azure AD. Usate un utente creato nel Cloud, possibilmente un account del dominio onmicrosoft.com.

Figura 5: Connessione ad Azure AD

Nella schermata successiva inseriamo le credenziali di Enterprise Admin del nostro dominio di Active Directory locale.

Per poter utilizzare le stesse credenziali sia per il login in Active Directory che per il login in Azure AD è necessario che gli username e i suffissi UPN (User Principal Name) coincidano. Per questo motivo nella schermata successiva vi verranno mostrati i domini che sono stati verificati nel vostro Tenant di Azure AD. Verificate che i domini siano corretti, altrimenti procedete alla regsitrazione dei suffisso UPN utilizzando la console di Active Directory Domains and Trusts.

Figura 6: Verifica dei suffissi UPN e del domini verificati in Azure AD

Di default vengono sincronizzati tutti i domini della foresta e tutte le unità organizzative (OU). Per escludere alcuni domini o unità organizzative dalla sincronizzazione con Azure AD, è possibile deselezionarli. Io ho deciso di sincronizzare solo la OU chiamata Office365.

Figura 7: Scelta dei domini e delle OU da sincronizzare

Nella schermata relativa all’Identificazione univoca degli utenti lasciamo le configurazioni predefinite e facciamo clic su Next. Lasciamo tutte le impostazioni di default anche per la schermata Filter Users and Devices.

Figura 8: Parametri per l’identificazione univoca degli utenti

Figura 9: Scelta degli utenti o del gruppo da sincronizzare

Nella schermata delle Optional Features, poiché abbiamo scelto l’autenticazione Pass-through, l’opzione di sincronizzazione delle password è abilitata di default. Questa opzione non è obbligatoria e per alcune aziende è importante che le password non vengano portate nel Cloud. Decidiamo quindi di non selezionarla, come mostrato in figura:

Figura 10: Optional features

Quando si abilita Single Sign-On in Azure AD Connect, viene creato un account computer denominato AZUREADSSOACCT nell’Active Directory locale e la chiave di decrittografia di Kerberos è condivisa con Azure AD. Inoltre vengono creati due Service Principal Name (SPN) Kerberos per indicare gli URL del cloud usati durante l’autenticazione tra il client e Azure AD. Inseriamo a questo punto le credenziali di Domain admin appropriate per il nostro dominio, in modo tale che venga creato l’account computer AZUREADSSOACCT , come mostrato in figura:

Figura 11: Inserimento delle credenziali per la configurazione del computer account nell’ Active Directory locale

Cliccando su Next avremo completato la configurazione e subito dopo inizierà il processo di sincronizzazione con il nostro Tenant di Azure AD.

Figura 12: Completamento del processo di configurazione

Figura 13: Installazione completata

Figura 14: Account computer AZUREADSSOACCT creato nell’Active Directory locale

Per poter testare il funzionamento del Single SIGN-On ci basterà loggarci su uno dei client del dominio e accedere al portale di autenticazione di Azure AD https://login.microsoftonline.com

Per poter garantire l’accesso automatico del client è prima necessario impostare nella Local Intranet del browser i due url:

Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per Azure AD.

Apriamo Internet Explorer, clicchiamo sul simbolo della rotellina per aprire le Internet Options, spostiamoci nella scheda Security e selezioniamo Local Intranet. Dopo aver cliccato su Sites, clicchiamo su Advanced e si aprirà la schermata dove potremo inserire i due URL, come mostrato in figura:

Figura 15: Aggiunti esplicita all’area Intranet del computer dei due siti di autenticazione

Figura 16: Particolare dei due URL aggiunti alla Local Intranet

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Facendo clic sul pulsante Show potremo inserire i due URL richiesti, come mostrato in figura:

Figura 17: URL e valori da inserire

Conclusioni

Il SINGLE SIGN-ON, in associazione all’autenticazione Pass-through, ci permette di avere le stesse funzionalità che fino ad ora erano possibili sono utilizzando gli Active Directory Federation Services, che richiedono diverse macchine per poter funzionare. Davvero una grossa novità ed un grosso vantaggio per autenticarsi in Azure AD senza dover sincronizzare le password in Azure AD.

Migrare una macchina fisica Linux verso Microsoft Azure

Al giorno d’oggi, nella gestione di infrastrutture, può capitare di dover effettuare migrazioni di macchine fisiche verso il cloud. Questa operazione richiede un’attenta analisi dello scenario e una procedura dettagliata che può variare in base al sistema operativo che si vuol migrare.

In questa guida analizzeremo tutti gli step necessari per migrare una macchina fisica Ubuntu 16.04 verso i servizi cloud di Azure.

La prima fase racchiude tutte le operazioni relative alla preparazione della macchina nel rispetto dei requisiti di Azure.

1. Nella macchina fisica è necessario aggiornare gli archivi con quelli di Azure in /etc/apt/sources.list

Per effettuare l’operazione basterà eseguire da terminale:

# sudo sed -i 's/[a-z][a-z].archive.ubuntu.com/azure.archive.ubuntu.com/g' /etc/apt/sources.list

# sudo apt-get update

2. È necessario aggiornare il sistema operativo al kernel più recente eseguendo i comandi seguenti:

# sudo apt-get update

# sudo apt-get install linux-generic-hwe-16.04 linux-cloud-tools-generic-hwe-16.04

# sudo apt-get dist-upgrade

# sudo reboot

3. Modificare la configurazione di avvio del kernel per Grub in modo da includere ulteriori parametri del kernel per Azure.

Per fare questo, editare il /etc/default/grub e modificare la stringa GRUB_CMDLINE_LINUX_DEFAULT nel seguente modo:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300"

4. Dopo la modifica lanciare sudo update-grub per aggiornare la configurazione.

5. Per poter interfacciare la macchina con i servizi di Azure è necessario installare l’Agente Linux di Azure. L’installazione di questa componente avviene attraverso i seguenti comandi:

# sudo apt-get update

# sudo apt-get install walinuxagent

6. Successivamente è necessario effettuare il deprovisioning della macchina e prepararla per il provisioning in Azure:

# sudo waagent -force -deprovision

# export HISTSIZE=0

# logout

La seconda fase racchiude tutte le operazioni necessarie per convertire la macchina fisica in un’immagine. In questa fase ci avvarremo dell’utilizzo di due strumenti:

  • DD è una componente di Linux comunemente usata per creare le immagini di un disco e produrne un file immagine
  • VHDTool è uno strumento per Windows utilizzato per manipolare i file VHD (Download: http://bit.ly/1FWQzVx)
1. Per creare l’immagine del disco della macchina bisogna lanciare il seguente comando:

dd if=/dev/sda of=/mnt/my_ubuntu_disk.img

dove sda fa riferimento all’intero disco della macchina e my_ubuntu_disk.img è il nome di dell’immagine che andremo a creare all’interno di un mount point che potrà essere un disco esterno oppure una share di rete.

N.B. L’operazione potrebbe durare molto tempo in caso di disco di grosse dimensioni. Il prompt non darà alcun feedback fino al termine dell’operazione. È possibile monitorare lo stato della creazione dell’immagine dalle variazioni della dimensione del file.

DD crea l’immagine includendo anche lo spazio vuoto. Eventualmente è possibile usare ulteriori tool per ridurre la dimensione dell’immagine. È pertanto necessario utilizzare uno spazio di appoggio sufficientemente grande.

2. Dal prompt dei comandi di Windows lanciare VHDTool /convert c:\my_ubuntu_disk.img

3. Rinominare il file my_ubuntu_disk.img con estensione .vhd

Nella terza fase si procederà all’upload del VHD su Azure e alla creazione della macchina virtuale.

1. Tramite l’interfaccia della riga di comando di Azure 2.0 accedere alla sottoscrizione attraverso il comando az login

2. Creare un gruppo di risorse. I gruppi di risorse riuniscono in modo logico tutte le risorse di Azure a supporto delle macchine virtuali. Per creare il gruppo eseguire: az group create –name myResourceGroup –location westus

3. Creare un account di archiviazione per il VHD nel gruppo di risorse appena creato con il comando:

az storage account create --resource-group myResourceGroup --location westus \

     --name mystorageaccount --kind Storage --sku Standard_LRS

4. Generare le chiavi di accesso per l’account di archiviazione:

az storage account keys list --resource-group myResourceGroup --account-name mystorageaccount

Al termine dell’esecuzione del comando, prendere nota del valore di key1 poiché verrà utilizzato per accedere all’account di archiviazione.

5. Creare un contenitore di archiviazione per organizzare i dischi in modo logico:

az storage container create --account-name mystorageaccount \

--account-key valoredikey1 --name mydisks

6. Il seguente passaggio permetterà l’effettivo caricamento del VHD su Azure:

az storage blob upload --account-name mystorageaccount \

--account-key key1 --container-name mydisks --type page \

--file /path/to/disk/my_ubuntu_disk.vhd --name myUbuntu.vhd

7. Per creare una macchina virtuale dal disco rigido virtuale, occorre convertire innanzitutto il disco rigido virtuale in un disco gestito con il comando:

az disk create --resource-group myResourceGroup --name myManagedDisk \

--source https://mystorageaccount.blob.core.windows.net/mydisks/myUbuntu.vhd

8. Una volta creato il disco gestito, lanciando il seguente comando, si otterrà il suo URI di cui prenderemo nota:

az disk list --resource-group myResourceGroup \

    --query '[].{Name:name,URI:creationData.sourceUri}' --output table

9. Infine, per creare la macchina virtuale:

az vm create --resource-group myResourceGroup --location westus \

--name myVirtualMachine --os-type linux \

--admin-username miouser --admin-password miapassword \

--attach-os-disk uri_del_disco

Una volta terminata la procedura, avremo riprodotto la macchina fisica sul cloud di Azure. Da questo momento del completamento del deploy, potremo gestire la macchina dal portale di Azure.


Bisognerà effettuare delle verifiche sull’apertura degli endpoint corrispondenti ad eventuali porte configurate sulla macchina fisica. Inoltre, grazie ai servizi cloud, sarà possibile completare la configurazione aggiungendo nuove funzionalità alla macchina come ad esempio un set di disponibilità.

PowerShell Desired State Configuration

Windows PowerShell è una interfaccia a riga di comando introdotta in Windows Server diversi anni fa. Tramite PowerShell è possibile configurare sia il sistema operativo sia gli applicativi. Microsoft Exchange Server e System Center Virtual Machine Manager sono stati i primi software ad essere basati interamente su PowerShell.

Col tempo Microsoft ha introdotto la possibilità di gestire anche tutte le funzioni del sistema operativo e anche altri importanti Vendor hanno iniziato ad implementare la gestione delle proprie applicazioni utilizzando PowerShell.

Questo tipo di approccio fa sì che dopo aver imparato ad utilizzare PowerShell siamo in grado di creare script complessi che ci permettono di interagire con software non Microsoft, di automatizzare alcune operazioni ripetitive utilizzando un unico tool e di eseguire operazioni che non sono disponibili dall’interfaccia grafica (GUI).

PowerShell Desired State Configuration

In questo articolo vi voglio descrivere la funzionalità Windows PowerShell DSC (Desired State Configuration), introdotta in PowerShell v4 e presente di default in Windows Server 2012 R2. DSC è una piattaforma di gestione di Windows PowerShell che consente di distribuire e gestire dati di configurazione per i software, nonché di gestire l’ambiente in cui vengono eseguiti questi software. DSC fornisce anche un set di estensioni di Windows PowerShell, nuovi cmdlet e risorse che è possibile usare per configurare le applicazioni o lo stato del sistema operativo.

Obiettivo di DSC è quello di configurare in modo automatico un insieme di computer ed in particolar modo:

  • Abilitare o disabilitare funzionalità e ruoli del server
  • Gestire il Registro di sistema
  • Gestire file e directory
  • Avviare, arrestare e gestire processi e servizi
  • Gestire gruppi e account utente
  • Distribuire nuovo software
  • Gestire le variabili di ambiente
  • Eseguire script di Windows PowerShell
  • Correggere una configurazione che non sia quella desiderata

Quando viene eseguita la configurazione DSC (e le risorse chiamate dalla configurazione), gli script si assicurano che il risultato sia quello desiderato, facendo in modo che lo stato del sistema corrisponda a quanto definito dalla configurazione.

Esiste anche una versione di DSC per Linux. Vi rimando all’articolo Installare e configurare PowerShell Desired State Configuration for Linux per maggiori approfondimenti.

Prerequisiti

Per poter utilizzare DSC avete bisogno dei seguenti prerequisiti:

  • Windows Management Framework 4.0
  • .Net Framework 4.5
  • Windows Server 2008 R2 SP1 e successivi
  • Windows 7 SP1 e successivi

È consigliabile utilizzare Windows Server 2012 e soprattutto se usate Windows 8.1 o Windows Server 2012 R2 assicuratevi di aver installato la KB2883200

È importante anche che PowerShell Remoting sia abilitato.

Componenti di Desired State Configuration

DSC è una piattaforma costituita da 3 componenti principali:

  • Configurazioni. Le configurazioni sono script di PowerShell che definiscono e configurano le istanze delle risorse. Quando viene eseguita la configurazione, DSC si assicura semplicemente che il risultato sia quello desiderato.
  • Risorse. Le risorse si trovano all’interno dei moduli di PowerShell e possono essere scritte per modellare un elemento generico, come un file o un processo di Windows, o un elemento specifico, come un server IIS o una VM in esecuzione in Azure.
  • Local Configuration Manager. È il motore usato da DSC per semplificare l’interazione tra risorse e configurazioni. Esegue regolarmente il polling del sistema per garantire che lo stato definito da una configurazione venga mantenuto.

Configurazioni DSC

Le configurazioni DSC sono script di PowerShell che definiscono una funzione. Per definire una configurazione bisogna usare la parola chiave Configuration. Nell’esempio sotto viene definito con Node il sistema target su cui fare la verifica della configurazione (presenza del ruolo IIS e della fuzionalità ASP.NET 4.5)

Dopo aver dichiarato la configurazione DSC è sufficiente creare un file MOF (Management Object Format) che potrà essere utilizzato per richiamare qualsiasi funzione PowerShell, utilizzando il comando:

ICTPowerWebsite –MachineName “Server01”

Dove Server01 è il nome della macchina da configurare.

Il comando non farà altro che creare una cartella con lo stesso nome della configurazione (nel nostro caso ICTPowerWebsite e un file MOF di output per OGNI blocco Node presente nella Configurazione.

Figura 1: Cartella di output del Configurazione

Figura 2: File MOF di output della Configurazione

Un Node DSC è qualsiasi computer in cui la configurazione è gestita da DSC. Può essere una macchina virtuale di Azure (con sistema operativo Windows o Linux), una macchina virtuale locale o un computer fisico. I nodi eseguono le configurazioni Node per diventare conformi e mantenere la conformità con lo stato desiderato.

Una volta che abbiamo ottenuto il file MOF abbiamo la possibilità di utilizzarlo applicando la cmdlet di PowerShell

Start-DscConfiguration –Path .\ICTPowerWebsite –Wait –Verbose

Il parametro Path può essere sia un percorso locale che un percorso di rete (UNC).

Figura 3: Applicazione della configurazione

Lanciando la cmdlet Start-DscConfiguration possiamo verificare in qualsiasi momento che Server01 abbia le configurazioni richieste e possiamo riutilizzarla per riapplicare le configurazioni tutte le volte che ci serve.

Figura 4: Riapplicazione della Configurazione usando la stessa cmdlet

Per verificare le configurazioni applicate potete usare la cmdlet Get-DscConfiguration, mentre per validare i parametri della configurazione potete usare la cmdlet Test-DscConfiguration, che vi restituirà il parametro True (se la configurazione del server è conforme con quello richiesto da DSC) oppure False (se non è conforme).

Interessante è anche la possibilità di fare roll-back ad una configurazione precedente, nel caso abbiate sbagliato, utilizzando la cmdlet Restore-DscConfiguration. Non è possibile invece tornare indietro ad uno stato precedente all’applicazione della configurazione DSC.

Figura 5: Verifica della configurazione

Utilizzo di DSC in Azure

Con Automation DSC (Desired State Configuration) per Azure è possibile distribuire in modo coerente, monitorare in modo affidabile e aggiornare automaticamente lo stato desiderato di tutte le risorse presenti nel Cloud.

Per poter utilizzare DSC è necessario installare nella VM un agent particolare chiamato Desired State Configuration extension.

Mentre di solito è necessario convertire gli script DSC di configurazione per il nodo in file MOF, compilandoli con una cmdlet PowerShell, Azure PowerShell gestisce automaticamente la compilazione quando distribuite l’estensione DSC alle VM di Azure.

Figura 6: Aggiunta dell’Estensione DSC ad una VM in Azure

Come esempio ci proponiamo di installare IIS all’interno della VM. Creiamo un file con estensione .ps1 con all’interno la configurazione di DSC:


Salviamo il file, lo comprimiamo in formato Zip e successivamente installiamo dal portale di Azure, dopo aver selezionato la macchina, l’estensione PowerShell Desired State Configuration

Carichiamo il file Zip nell’apposita casella Configuration Modules or Script e scriviamo la notazione corretta della configurazione da eseguire nella casella Module-qualified Name of Configuration. La notazione deve essere nella forma <ConfigurationFile>.ps1\<ConfigurationName>. Nel mio caso è DSC-Install-IIS.ps1\MyDscConfiguration. Inserite nel campo Version il valore 2.0 e mettere su Yes il valore Auto Upgrade Minor Version.

Confermiamo con Create e vedremo che l’estensione è stata aggiunta alla nostra VM ed è in esecuzione.

Figura 7: Script in esecuzione

Dopo il reboot della VM verrà applicato lo script che avete caricato e lo status dell’estensione diventerà Provisioning
Succeded!

Figura 8: Esecuzione dello script completata

Lo script viene eseguito però solo una volta. Se volete rieseguire dovete ricaricarlo dal portale di Azure. Il motivo è dovuto al fatto che il Local Configuration Manager è configurato di default nella modalità ApplyAndMonitor. Per poter controllare e rieseguire lo script ciclicamente dovete modificare il Local Configuration Manager.

Modifica del Local Configuration Manager

Come ho già scritto prima, il Local Configuration Manager è il motore usato da DSC che esegue regolarmente il polling del sistema per garantire che lo stato definito da una configurazione venga mantenuto. Per verificare la configurazione del Local Configuration Manager è sufficiente lanciare sulla macchina la cmdlet

Get-DscLocalConfigurationManager

Figura 9: Valori di default del Local Configuration Manager

Di default il Local Configuration Manager è settato nella modalità ApplyAndMonitor.

Per riapplicare continuamente le impostazioni del vostro script DSC dovete modificare il parametro di ConfigurationMode in ApplyAndAutoCorrect. Potete realizzare uno script DSC e inserire il contenuto:

Salvate il file con estensione .ps1 ed eseguitelo sulla macchina per creare il file MOF, come ho precedentemente spiegato. Una volta che abbiamo ottenuto il file MOF abbiamo la possibilità di utilizzarlo applicando la cmdlet di PowerShell

Set-DscLocalConfigurationManager –Path .\LCMConfig\ –Verbose

Figura 10: Modifica del Local Configuration Manager

Rilanciando la cmdlet

Get-DscLocalConfigurationManager

vedrete che la vostra configurazione sarà stata applicata.

Figura 11: Modifica dei parametri del Local Configuration Manager

Con la configurazione appena modificata, DSC controllerà ogni 30 minuti lo stato della macchina e riapplicherà automaticamente lo script!

Maggiori informazioni su come configurare Windows PowerShell 4.0 Desired State Configuration Local Configuration Manager (LCM) sono disponibili al link https://msdn.microsoft.com/en-us/powershell/dsc/metaconfig4

Conclusioni

PowerShell DSC permette di poter avere le nostre macchine nello stato in cui le riteniamo conformi e si può assicurare che lo rimangano poiché gli script possono essere continuamente riapplicati. Per cominciare a lavorare con DSC potete visitare la pagina Getting Started with PowerShell Desired State Configuration (DSC)

Buon lavoro!

Nic

Azure Resource Manager templates – Deployment con un clic!

I template in Microsoft Azure possono utilizzare un’ampia gamma di risorse oltre a quelle tipiche dell’ Infrastructure As A Service (IaaS), come ad esempio le Web App o i database SQL e permettono di distribuire automaticamente queste risorse in relazione tra loro.

Uno dei vantaggi dei template di Azure è quello di poter creare tutte le risorse necessarie alla creazione di una soluzione, anche complessa, semplicemente utilizzando un clic!

Sul sito web GitHub, all’indirizzo https://github.com/Azure/azure-quickstart-templates trovate centinaia di template in formato JavaScript Object Notation (JSON), che vi permettono di creare macchine virtuali, reti virtuali, applicazioni web, database SQL e di realizzare soluzioni e applicazioni già pronte all’uso.

Per poterlo fare basta dichiarare nel template di Azure quali risorse volete utilizzare e successivamente fornire i parametri necessari alla configurazione della soluzione scelta.

Moltissimi sono i template disponibili, visualizzabili alla pagina https://azure.microsoft.com/it-it/resources/templates/, che vi permettono di creare ad esempio un intero cluster, utilizzando diverse macchine virtuali.

Figura 1: Offerta dei template in Azure

Ovviamente potete creare template di Azure anche personalizzati. Trovate una serie di ottime guide al link https://docs.microsoft.com/it-it/azure/azure-resource-manager/resource-manager-template-best-practices , dove vi vengono illustrate le best practices per creare modelli di Resource Manager facili da usare.

Inoltre i template possono essere esportati anche da risorse che già avete nella vostra sottoscrizione Azure. Supponendo di aver creato una macchina virtuale e di volerla replicare, abbiamo la possibilità di visualizzare il file .json del template e di esportarlo per riutilizzarlo per ridistribuire la macchina virtuale in base alle nostre esigenze. Nella figura sotto, dopo essermi loggato al portale Azure, ho cliccato su una mia macchina virtuale e successivamente ho cliccato su Automation Script, in modo tale da visualizzare il template .json della Virtual Machine e poterlo scaricare.

Figura 2: Template .json esportabile dal portale di Azure

Cliccando su Download avrete la possibilità di scaricare i file Parameters.json e Template.json, oltre a file per poter distribuire il template utilizzando Powershell oppure Bash o Visual Studio.

Figura 3: File scaricati dal portale Azure

Figura 4: parte del file template.json

Figura 5: file parameters.json

Figura 6: File deploy.ps1

Ridistribuire i template diventa facilissimo perché possiamo usare il file deploy.ps1 dopo aver modificato i parametri dei file .json

Template pronti disponibili su GitHub

Dal repository GitHub potete partire dall’implementazione di modelli semplici, come ad esempio il template che permette di creare una nuova VM e promuoverla a domain controller di una nuova foresta Create an Azure VM with a new AD Forest

Figura 7: Template per la creazione di un nuovo domain controller

Trovo particolarmente interessanti alcuni template presenti su GitHub che ci danno la possibilità di creare soluzioni complesse di Clustering di VM.

In particolar modo è possibile utilizzare il template Windows Server 2016 Storage Spaces Direct (S2D) SOFS cluster per creare delle macchine virtuali da collegare ad una rete VNET esistente e poter creare un Windows Server 2016 Storage Spaces Direct (S2D) Scale-Out File Server (SOFS) cluster, il tutto con un semplice clic!

Figura 8: template per la creazione di uno Storage Spaces Direct (S2D) Scale-Out File Server (SOFS) cluster

Interessante anche il template Create a Storage Spaces Direct (S2D) SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions, che permette di creare due cluster Storage Spaces Direct (S2D) Scale-Out File Server (SOFS) utilizzando Windows Server 2016 in un ambiente realizzato tra due regioni diverse di Azure, in modo tale da poter utilizzare la nuova funzionalità di Storage Replica.

Figura 9: Schema di funzionamento di Storage Spaces Direct (S2D) in un ambiente realizzato tra due regioni diverse di Azure

Figura 10: template Create a Storage Spaces Direct (S2D) SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions

Per maggiori approfondimenti vi rimando anche all’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure.

Ci sono anche soluzioni più semplici che permettono di testare la nuova funzionalità di Storage Replica, di cui abbiamo parlato nell’articolo Implementare Storage Replica in Windows Server 2016 con Microsoft Azure. Trovate il template all’indirizzo Create a Storage Replica (SR) destination server with Windows Server 2016 on an existing VNET

Figura 11: Template Create a Storage Replica (SR) destination server with Windows Server 2016 on an existing VNET

Conclusioni

La facilità con cui i template di Azure ci permettono di realizzare soluzioni tecnologiche complesse, come Storage Replica, Storage Spaces Direcr oppure il Clustering, ci danno un’idea precisa della potenza del cloud pubblico di Microsoft e dell’evoluzione tecnologica dei nostri Datacenter.

E se volete cimentarvi con la creazione di vostri template potete cominciare visitando la pagina https://docs.microsoft.com/it-it/azure/azure-resource-manager/resource-group-authoring-templates

Buon lavoro!

Nic