Il servizio Azure Databricks è un cluster Apache Spark totalmente gestito ed ottimizzato in esecuzione nel datacenter pubblico di Microsoft. Viene implementato per l’elaborazione dei cosiddetti Big Data, in scenari di analisi approfondita del dato (analytics), tramite l’utilizzo di metodi statistici e scientifici (data science) e di machine learning.
In questo articolo vengono indicate quali sono le operazioni necessarie per migliorare la gestione ed aumentare il livello di sicurezza di Azure Databricks, utilizzando la funzionalità di secure cluster connectivity (SCC), la propria vNet (vNet injection) e vincolando i flussi esterni verso Azure Firewall o una Network Virtual Appliance (NVA).
Secure cluster connectivity (SCC)
La configurazione di Azure Databricks in modalità secure cluster connectivity o NPIP (no public IP) permette di attivare i nodi del cluster Apache Spark senza l’assegnazione di un indirizzo IP pubblico come sarebbe invece previsto nella configurazione di default.
Ad oggi risulta possibile attivare la modalità SCC non solo tramite ARM template ma anche eseguendo il deploy da portale Azure. Sarà necessario selezionare, nel tab Networking, la modalità Deploy Azure Databricks workspace with Secure Cluster Connectivity (No Public IP) a Yes.
Per quanto riguarda il deploy tramite ARM template occorrerà impostare il parametro enableNoPublicIp a Yes nella creazione della risorsa Microsoft.Databricks/workspaces.
Integrazione con rete virtuale Azure (vNet injection)
Tramite la funzionalità di vNet injection, ossia l’esecuzione del deploy di Azure Databricks workspace nella propria vNet Azure, viene garantita la possibilità di mettere in sicurezza le comunicazioni del cluster Apache Spark.
Come per SCC ad oggi risulta possibile eseguire il deploy sia tramite ARM template che tramite portale Azure.
Il deploy del cluster, che avverrà in questo modo all’interno della propria vNet gestita, potrà sfruttare le seguenti configurazioni:
- Possibilità di utilizzare service endpoint e private endpoint per le comunicazioni tra Azure Databricks e gli altri servizi Azure.
- Possibilità di comunicazione verso servizi, presenti all’interno del datacenter privato, tramite l’utilizzo di rotte statiche (user-defined route).
- Possibilità di vincolare e controllare tutte le comunicazioni da Azure Databricks verso l’esterno utilizzando Azure Firewall o un Network Virtual Appliance.
- Possibilità da Azure Databricks di utilizzare le configurazioni dei custom DNS configurati a livello di vNet.
Requisiti di rete
Un aspetto basilare, prima ancora di procedere con il deploy di Azure Databricks all’interno della propria vNet, sono i requisiti di rete da dover rispettare.
Regione e Sottoscrizione
La vNet deve essere presente nella stessa regione e nella stessa sottoscrizione di Azure Databricks.
Virtual Network
Azure Databricks workspace necessita di due subnet, una identificata come privata (container) e una identificata come pubblica (host), entrambe con un indirizzamento (CIDR) massimo /26.
Se non già possible all’interno di una vNet esistente dovrà quindi essere previsto l’indirizzamento necessario, per le due subnet di Azure Databricks, andando a prevendere un nuovo address space all’interno della propria vNet.
L’indirizzamento scelto per le subnet risulta importante in quanto definisce il numero massimo di nodi che possono formare il cluster Apache Spark. Tenendo quindi in considerazione i 5 IP riservati da Microsoft possiamo utilizzare la tabella indicata per fare le giuste considerazioni in fase di architettura.
Flussi di comunicazione
Per la gestione dei flussi, necessari per le comunicazioni da (egress) e verso (ingress) il cluster Databricks, sarà significativa la configurazione da effettuare tramite route table e le rispettive user-defined route da applicare alle subnet del cluster.
Come riportato nel documento occorre definire delle rotte statiche sia per la comunicazione verso il nostro Network Virtual Appliance e sia direttamente verso Internet tenendo però in considerazione le regole differenti a seconda dell’utilizzo della vNet injection e/o SCC.
Per il corretto avvio del cluster Databricks fondamentale sarà anche definire tutte le aperture richieste (network e application rule) su Azure Firewall o NVA per permettere la comunicazione verso Internet.
Suggerimenti per il deploy
Risulta necessario spesso avere un controllo a livello di naming delle risorse che vengono attivate in ambiente Azure sia per una questione di Governance che di Azure Policy che ne identificano la compliance. Il deploy tramite portale Azure, in modo particolare per Azure Databricks, non aiuta in questo. Occorre in questi casi procedere con il deploy in modo automatizzato utilizzando i template di Azure Resource Manager. In questo modo riusciamo a definire la naming per alcune risorse che altrimenti non sarebbe stato possible come:
- Il managed Databricks resource group.
- I Network Security Groups applicati alle due subnet del Databricks.
- Lo storage account utilizzato per il DBFS (Databricks File System).
Prima di procedere con il deploy tramite ARM template, in modalità vNet injection, occorre:
- Delegare su entrambe le subnet definite per Azure Databricks il servizio Databricks/workspaces;
- Creare e associare i due network Security Groups da applicare alle due subnet di Azure Databricks;
- Creare il resource group su cui eseguire il deploy di Azure Databricks workspace;
- Non occorre creare il managed resource group che sarà definito all’interno del template ARM;
Per poter applicare i tags a livello di risorsa managed Databricks resource group occorrerà applicarli prima a livello di risorsa Azure Databricks workspace. Tramite processo automatico di sync gli stessi tags e valori verranno applicati sul managed resource group su cui altrimenti non sarebbe possibile a causa dei lock e policy che ne inibiscono operazioni in modalità di scrittura.
Riferimenti
Si riportano alcuni riferimenti utili:
- Distribuire Azure Databricks nella rete virtuale di Azure (VNet Injection)
- Azure Databricks e Network Virtual Appliance
- Impostazioni di route definite dall’utente per Azure Databricks
Conclusioni
Risulta necessario nei deploy del servizio di piattaforma (PaaS) Azure Databricks prendere in considerazione le nuove funzionalità di utilizzo della propria vNet e No Public IP, in modo da mettere in sicurezza tutte le comunicazioni dei nodi del cluster Apache Spark. Questo permetterà, non solo di gestire tramite un firewall le comunicazioni in uscita verso Internet, ma anche di permettere l’integrazione con gli atri servizi Azure, spesso utilizzati nelle architetture Azure in cui è presente Azure Databricks, come Azure Data Factory, Azure SQL Database, Azure Storage Account ed Azure Data Lake, sfruttando le comunicazioni private tramite i service endpoint o private endpoint.