Eseguire la migrazione di un'applicazione per usare connessioni senza password con Database di Azure per PostgreSQL

Questo articolo illustra come eseguire la migrazione da metodi di autenticazione tradizionali a connessioni senza password più sicure con Database di Azure per PostgreSQL.

Le richieste dell'applicazione a Database di Azure per PostgreSQL devono essere autenticate. Database di Azure per PostgreSQL offre diversi modi per consentire alle app di connettersi in modo sicuro. Uno dei modi consiste nell'usare le password. Tuttavia, è consigliabile assegnare priorità alle connessioni senza password nelle applicazioni, quando possibile.

Confrontare le opzioni di autenticazione

Quando l'applicazione esegue l'autenticazione con Database di Azure per PostgreSQL, fornisce una coppia nome utente e password per connettere il database. A seconda della posizione in cui sono archiviate le identità, esistono due tipi di autenticazione: autenticazione di Microsoft Entra e autenticazione PostgreSQL.

Autenticazione Microsoft Entra

L'autenticazione di Microsoft Entra è un meccanismo per la connessione a Database di Azure per PostgreSQL usando le identità definite in Microsoft Entra ID. Con l'autenticazione di Microsoft Entra, è possibile gestire le identità utente del database e altre servizi Microsoft in una posizione centrale, semplificando la gestione delle autorizzazioni.

L'uso di Microsoft Entra ID per l'autenticazione offre i vantaggi seguenti:

• Autenticazione degli utenti nei servizi di Azure in modo uniforme.
• Gestione dei criteri password e della rotazione delle password in un'unica posizione.
• Più forme di autenticazione supportate da Microsoft Entra ID, che possono eliminare la necessità di archiviare le password.
• I clienti possono gestire le autorizzazioni del database usando gruppi esterni (Microsoft Entra ID).
• L'autenticazione di Microsoft Entra usa gli utenti del database PostgreSQL per autenticare le identità a livello di database.
• Supporto dell'autenticazione basata su token per le applicazioni che si connettono a Database di Azure per PostgreSQL.

Autenticazione PostgreSQL

È possibile creare account in PostgreSQL. Se si sceglie di usare le password come credenziali per gli account, queste credenziali verranno archiviate nella user tabella. Poiché queste password vengono archiviate in PostgreSQL, è necessario gestire manualmente la rotazione delle password.

Anche se è possibile connettersi a Database di Azure per PostgreSQL con le password, è consigliabile usarle con cautela. È necessario essere diligenti per non esporre mai le password in una posizione non sicura. Chiunque possa accedere alle password è in grado di eseguire l'autenticazione. Ad esempio, esiste il rischio che un utente malintenzionato possa accedere all'applicazione se un stringa di connessione viene accidentalmente archiviato nel controllo del codice sorgente, inviato tramite un messaggio di posta elettronica non sicuro, incollato nella chat sbagliata o visualizzato da un utente che non deve avere l'autorizzazione. Prendere invece in considerazione l'aggiornamento dell'applicazione per usare connessioni senza password.

Introduzione alle connessioni senza password

Con una connessione senza password, è possibile connettersi ai servizi di Azure senza archiviare credenziali nel codice dell'applicazione, nei relativi file di configurazione o nelle variabili di ambiente.

Molti servizi di Azure supportano connessioni senza password, ad esempio tramite Identità gestita di Azure. Queste tecniche forniscono funzionalità di sicurezza affidabili che è possibile implementare usando DefaultAzureCredential dalle librerie client di Identità di Azure. In questa esercitazione si apprenderà come aggiornare un'applicazione esistente da usare DefaultAzureCredential invece di alternative, ad esempio stringa di connessione.

DefaultAzureCredential supporta più metodi di autenticazione e determina automaticamente quali devono essere usati in fase di esecuzione. Questo approccio consente all'app di usare metodi di autenticazione diversi in ambienti diversi (sviluppo locale e produzione) senza implementare codice specifico dell'ambiente.

L'ordine e le posizioni in cui DefaultAzureCredential cercare le credenziali sono disponibili nella panoramica della libreria di identità di Azure. Ad esempio, quando si lavora in locale, DefaultAzureCredential in genere si esegue l'autenticazione usando l'account usato dallo sviluppatore per accedere a Visual Studio. Quando l'app viene distribuita in Azure, DefaultAzureCredential passerà automaticamente all'uso di un'identità gestita. Per questa transizione non sono necessarie modifiche al codice.

Per garantire che le connessioni siano senza password, è necessario prendere in considerazione sia lo sviluppo locale che l'ambiente di produzione. Se una stringa di connessione è necessaria in entrambe le posizioni, l'applicazione non è senza password.

Nell'ambiente di sviluppo locale è possibile eseguire l'autenticazione con l'interfaccia della riga di comando di Azure, Azure PowerShell, Visual Studio o plug-in di Azure per Visual Studio Code o IntelliJ. In questo caso, è possibile usare tali credenziali nell'applicazione anziché configurare le proprietà.

Quando si distribuiscono applicazioni in un ambiente di hosting di Azure, ad esempio una macchina virtuale, è possibile assegnare un'identità gestita in tale ambiente. Non sarà quindi necessario fornire le credenziali per connettersi ai servizi di Azure.

Eseguire la migrazione di un'applicazione esistente per usare connessioni senza password

La procedura seguente illustra come eseguire la migrazione di un'applicazione esistente per usare connessioni senza password anziché una soluzione basata su password.

0) Preparare l'ambiente di lavoro

Usare prima di tutto il comando seguente per configurare alcune variabili di ambiente.

export AZ_RESOURCE_GROUP=<YOUR_RESOURCE_GROUP>
export AZ_DATABASE_SERVER_NAME=<YOUR_DATABASE_SERVER_NAME>
export AZ_DATABASE_NAME=demo
export AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME=<YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>
export AZ_LOCAL_IP_ADDRESS=<YOUR_LOCAL_IP_ADDRESS>
export CURRENT_USERNAME=$(az ad signed-in-user show --query userPrincipalName --output tsv)

Sostituire i segnaposto con i valori seguenti, che vengono usati nell'intero articolo:

• <YOUR_RESOURCE_GROUP>: nome del gruppo di risorse in cui si trovano le risorse.
• <YOUR_DATABASE_SERVER_NAME>: nome del server PostgreSQL. Deve essere univoco in Azure.
• <YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: nome visualizzato dell'utente non amministratore di Microsoft Entra. Assicurarsi che il nome sia un utente valido nel tenant di Microsoft Entra.
• <YOUR_LOCAL_IP_ADDRESS>: indirizzo IP del computer locale, da cui si eseguirà l'applicazione Spring Boot. Un modo pratico per trovare è aprire whatismyip.akamai.com.

1) Configurare Database di Azure per PostgreSQL

1.1) Abilitare l'autenticazione basata su ID di Microsoft Entra

Per usare l'accesso a Microsoft Entra ID con Database di Azure per PostgreSQL, è necessario impostare prima l'utente amministratore di Microsoft Entra. Solo un utente di Microsoft Entra Admin può creare/abilitare gli utenti per l'autenticazione basata su ID di Microsoft Entra.

Per configurare un amministratore di Microsoft Entra dopo aver creato il server, seguire la procedura descritta in Gestire i ruoli di Microsoft Entra in Database di Azure per PostgreSQL - Server flessibile.

2) Configurare Database di Azure per PostgreSQL per lo sviluppo locale

2.1) Configurare una regola del firewall per l'INDIRIZZO IP locale

Le istanze di Database di Azure per PostgreSQL sono protette per impostazione predefinita. Includono un firewall che non consente alcuna connessione in ingresso. Per poter usare il database, è necessario aggiungere una regola del firewall che consenta all'indirizzo IP locale di accedere al server di database.

Poiché all'inizio di questo articolo è stato configurato un indirizzo IP locale, è possibile aprire il firewall del server eseguendo questo comando:

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_LOCAL_IP_ADDRESS \
    --end-ip-address $AZ_LOCAL_IP_ADDRESS \
    --output tsv

Se ci si connette al server PostgreSQL da sottosistema Windows per Linux (WSL) in un computer Windows, è necessario aggiungere l'ID host WSL al firewall.

Ottenere l'indirizzo IP del computer host eseguendo il comando seguente in WSL:

cat /etc/resolv.conf

Copiare l'indirizzo IP seguendo il termine nameserver, quindi usare il comando seguente per impostare una variabile di ambiente per l'indirizzo IP WSL:

export AZ_WSL_IP_ADDRESS=<the-copied-IP-address>

Usare quindi il comando seguente per aprire il firewall del server all'app basata su WSL:

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_WSL_IP_ADDRESS \
    --end-ip-address $AZ_WSL_IP_ADDRESS \
    --output tsv

2.2) Creare un utente non amministratore di PostgreSQL e concedere l'autorizzazione

Creare quindi un utente Microsoft Entra non amministratore e concedere tutte le autorizzazioni per il $AZ_DATABASE_NAME database. È possibile modificare il nome $AZ_DATABASE_NAME del database in base alle proprie esigenze.

Creare uno script SQL denominato create_ad_user_local.sql per la creazione di un utente non amministratore. Aggiungere il contenuto seguente e salvarlo in locale:

cat << EOF > create_ad_user_local.sql
select * from pgaadauth_create_principal('$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME', false, false);
EOF

Usare quindi il comando seguente per eseguire lo script SQL per creare l'utente non amministratore di Microsoft Entra:

psql "host=$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com user=$CURRENT_USERNAME dbname=postgres port=5432 password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) sslmode=require" < create_ad_user_local.sql

Usare ora il comando seguente per rimuovere il file di script SQL temporaneo:

rm create_ad_user_local.sql

3) Accedere ed eseguire la migrazione del codice dell'app per usare connessioni senza password

Per lo sviluppo locale, assicurarsi di essere autenticati con lo stesso account Microsoft Entra a cui è stato assegnato il ruolo in PostgreSQL. È possibile eseguire l'autenticazione tramite l'interfaccia della riga di comando di Azure, Visual Studio, Azure PowerShell o altri strumenti come IntelliJ.

az login

Connect-AzAccount

Usare quindi la procedura seguente per aggiornare il codice per usare connessioni senza password. Anche se concettualmente simile, ogni linguaggio usa dettagli di implementazione diversi.

Eseguire l'app in locale

Dopo aver apportato queste modifiche al codice, eseguire l'applicazione in locale. La nuova configurazione deve raccogliere le credenziali locali se si è connessi a un IDE compatibile o a uno strumento da riga di comando, ad esempio l'interfaccia della riga di comando di Azure, Visual Studio o IntelliJ. I ruoli assegnati all'utente di sviluppo locale in Azure consentiranno all'app di connettersi al servizio di Azure in locale.

4) Configurare l'ambiente di hosting di Azure

Dopo che l'applicazione è configurata per l'uso di connessioni senza password e viene eseguita in locale, lo stesso codice può eseguire l'autenticazione ai servizi di Azure dopo la distribuzione in Azure. Ad esempio, un'applicazione distribuita in un'istanza del servizio app Azure con un'identità gestita assegnata può connettersi a Archiviazione di Azure.

In questa sezione verranno eseguiti due passaggi per consentire l'esecuzione dell'applicazione in un ambiente di hosting di Azure in modo senza password:

• Assegnare l'identità gestita per l'ambiente di hosting di Azure.
• Assegnare ruoli all'identità gestita.

Assegnare l'identità gestita usando il portale di Azure

I passaggi seguenti illustrano come assegnare un'identità gestita assegnata dal sistema per vari servizi di hosting Web. L'identità gestita può connettersi in modo sicuro ad altri servizi di Azure usando le configurazioni dell'app configurate in precedenza.

È anche possibile assegnare un'identità gestita in un ambiente di hosting di Azure usando l'interfaccia della riga di comando di Azure.

export AZ_MI_OBJECT_ID=$(az webapp identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --query principalId \
    --output tsv)

az extension add --name serviceconnector-passwordless --upgrade

az webapp connection create postgres-flexible \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <app-service-name>
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

az spring connection create postgres-flexible \
    --resource-group $AZ_RESOURCE_GROUP \
    --service <service-name> \
    --app <service-instance-name> \
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

az containerapp connection create postgres-flexible \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <app-service-name>
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

export AZ_MI_OBJECT_ID=$(az containerapp identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --query principalId \
    --output tsv)

export AZ_MI_OBJECT_ID=$(az spring app identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --service <service-name> \
    --query identity.principalId \
    --output tsv)

export AZ_MI_OBJECT_ID=$(az vm identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --query principalId \
    --output tsv)

export AZ_MI_OBJECT_ID=$(az aks update \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <AKS-cluster-name> \
    --enable-managed-identity \
    --query identityProfile.kubeletidentity.objectId \
    --output tsv)

Assegnare ruoli all'identità gestita

Concedere quindi le autorizzazioni all'identità gestita assegnata per accedere all'istanza di PostgreSQL.

export AZ_POSTGRESQL_AD_MI_USERNAME=$(az ad sp show \
    --id $AZ_MI_OBJECT_ID \
    --query displayName \
    --output tsv)

cat << EOF > create_ad_user_mi.sql
select * from pgaadauth_create_principal_with_oid('$AZ_POSTGRESQL_AD_MI_USERNAME', '$AZ_MI_OBJECT_ID', 'service', false, false);
EOF

psql "host=$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com user=$CURRENT_USERNAME dbname=postgres port=5432 password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) sslmode=require" < create_ad_user_mi.sql

rm create_ad_user_mi.sql

Testare l'app

Prima di distribuire l'app nell'ambiente di hosting, è necessario apportare un'altra modifica al codice perché l'applicazione si connetterà a PostgreSQL usando l'utente creato per l'identità gestita.

properties.put("user", "$AZ_POSTGRESQL_AD_MI_USERNAME");

spring:
  datasource:
    url: jdbc:postgresql://${AZ_DATABASE_SERVER_NAME}.postgres.database.azure.com:5432/$AZ_DATABASE_NAME?sslmode=require
    username: ${AZ_POSTGRESQL_AD_MI_USERNAME}
    azure:
      passwordless-enabled: true

spring:
  datasource:
    azure:
      passwordless-enabled: true

Dopo aver apportato queste modifiche al codice, è possibile compilare e ridistribuire l'applicazione. Passare quindi all'applicazione ospitata nel browser. L'app dovrebbe essere in grado di connettersi correttamente al database PostgreSQL. Tenere presente che la propagazione delle assegnazioni di ruolo nell'ambiente di Azure potrebbe richiedere alcuni minuti. L'applicazione è ora configurata per l'esecuzione sia in locale che in un ambiente di produzione senza che gli sviluppatori debbano gestire i segreti nell'applicazione stessa.

Passaggi successivi

In questa esercitazione si è appreso come eseguire la migrazione di un'applicazione a connessioni senza password.

È possibile leggere le risorse seguenti per esplorare i concetti illustrati in questo articolo in modo più approfondito:

• Autorizzare l'accesso ai dati BLOB con identità gestite per le risorse di Azure.
• Autorizzare l'accesso ai BLOB usando Microsoft Entra ID