Oefening: toegang tot openbare databases beperken tot Azure-services

In deze les vervangt u de PostgreSQL-firewallregel die verbindingspogingen van alle openbare IPv4-adressen toestaat met de uitzondering Azure-services. De database behoudt het openbare eindpunt. Met de uitzondering kunnen Azure services en resources, waaronder deze Quarkus-toepassing, geverifieerde verbindingen proberen; de toegang tot deze toepassing of Container Apps-omgeving wordt niet beperkt.

Ga verder in dezelfde lokale Bash-shell of WSL op Windows, met de AZ_* variabelen uit de vorige oefeningen. Voer de databasecontroles uit vanuit een openbaar netwerk buiten Azure. Gebruik Azure CLI 2.87.0 of hoger en voer de instelling voor de resourcenaam of het wachtwoord niet opnieuw uit.

Toegang tot de PostgreSQL-server met behulp van de CLI

Controleer eerst of u een query kunt uitvoeren op de PostgreSQL-server vanuit uw huidige clientnetwerk:

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Controleer of de query de to-do items retourneert die u eerder hebt gemaakt. Dit bevestigt de connectiviteit vanaf het bronnetwerk van uw shell, niet vanaf elk clientnetwerk. Los een queryfout op voordat u de firewall wijzigt, zodat u een werkende basislijn hebt voor de latere tests.

De permissieve firewallregel verwijderen

Wanneer u de nieuwe PostgreSQL-server hebt gemaakt, hebt u --public-access All het openbare eindpunt ingeschakeld en één firewallregel gemaakt voor alle openbare IPv4-adressen.

Los alle mislukte firewallopdrachten op voordat u doorgaat; een geweigerde opdracht wijzigt de firewall niet. Vermeld de bestaande regels op de server die bij de oefening hoort:

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

Zoek de regel waarvan StartIpAddress0.0.0.0 is en EndIpAddress is 255.255.255.255. De gegenereerde naam in de Name kolom varieert. Dit moet de enige regel zijn die in deze module wordt gebruikt op de nieuwe server. Als het resultaat verschilt, controleer of u de server die bij de oefening hoort gebruikt en los de discrepantie op voordat u doorgaat. Verwijder geen niet-gerelateerde regels van een bestaande of gedeelde server.

Met dit bereik kan elk openbaar IPv4-bronadres proberen verbinding te maken met een database. Clients hebben nog steeds geldige PostgreSQL-inloggegevens nodig. Verwijder deze regel voordat u later in de oefening de uitzondering Azure-services toevoegt.

Het kan vijf minuten duren voordat postgreSQL-firewallupdates zijn toegepast. Wacht na elke geslaagde wijziging even voordat u de connectiviteit controleert. Herhaal de CLI-query in een nieuwe aanroep om een nieuwe databaseverbinding te testen; een HTTP-aanvraag voor de toepassing is een afzonderlijke controle op toepassingsniveau.

Vervang in de volgende opdracht <allow-all-rule-name> door de werkelijke Name van de regel 'all-addresses' die u zojuist hebt vermeld. Verwijder de punthaken, houd de aanhalingstekens en verwijder alleen die regel:

az postgres flexible-server firewall-rule delete \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --name "<allow-all-rule-name>" \
    --yes

Nadat het verwijderen is voltooid, kunt u de regels opnieuw weergeven:

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

De opdracht list moet nu geen regels retourneren. Als de opdracht mislukt of als er een rule overblijft, moet u dat eerst oplossen voordat u doorgaat. Een lege lijst bevestigt de geconfigureerde regels, maar niet dat de netwerkupdate is doorgevoerd.

Nadat u enige tijd voor propagatie hebt gewacht, maakt u een nieuwe directe databaseverbinding door de query opnieuw uit te voeren:

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Nadat de verwijdering is doorgevoerd, moet een nieuwe databaseverbinding worden geweigerd. Fouttekst is afhankelijk van de client en het netwerkpad; PostgreSQL kan bijvoorbeeld melden dat er geen overeenkomende pg_hba.conf vermelding is. Verwacht geen bepaald time-outbericht. Een geslaagde query direct na verwijdering kan betekenen dat de firewallwijziging nog steeds wordt doorgevoerd.

Deze no-rule-fase blokkeert opzettelijk nieuwe databaseverbindingen van de toepassing nadat de wijziging is doorgevoerd. Het HTTPS-eindpunt van de toepassing blijft openbaar. Quarkus maakt gebruik van gepoolde databaseverbindingen, dus een HTTP-aanvraag opent niet noodzakelijkerwijs een nieuwe databaseverbinding. Controleer de HTTP-status en -body, maar gebruik niet één onmiddellijke reactie als bewijs dat de propagatie van firewallregels is voltooid:

curl --include "https://$AZ_APP_URL/api/todos"

Met --include de optie worden de HTTP-antwoordheaders en de hoofdtekst weergegeven. Standaard behandelt curl een HTTP-foutstatus niet als een opdrachtfout, dus inspecteer de status in plaats van te vertrouwen op de afsluitcode. Zie de curl-handleiding voor meer informatie.

De uitzondering Azure-services toevoegen

Voeg de uitzondering Azure-services toe zodat de geïmplementeerde toepassing opnieuw verbinding kan maken met de database:

az postgres flexible-server firewall-rule create \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --name "Allow_Azure-services" \
    --start-ip-address "0.0.0.0" \
    --end-ip-address "0.0.0.0"

Met de begin- en eindwaarden 0.0.0.0 schakelt u Openbare toegang vanaf elke Azure-service binnen Azure naar deze server toestaan in, zoals beschreven in PostgreSQL-firewallregels. Dit is een door de service gedefinieerde uitzondering op het openbare eindpunt van de database, niet een privé-IP-adresbereik.

Nadat het aanmaken is geslaagd, kunt u de regels opnieuw weergeven:

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

De enige regel op deze nieuwe server moet nu zijn Allow_Azure-services, met beide StartIpAddress en EndIpAddress ingesteld op 0.0.0.0. Als de opdracht mislukt of de regels niet overeenkomen met dit resultaat, los de discrepantie op voordat u de connectiviteit test. Het duurt maximaal vijf minuten voordat de wijziging van kracht wordt.

Database- en applicatietoegang controleren

Nadat u enige tijd voor propagatie hebt gegeven, voert u de volgende opdracht uit in een nieuwe aanroep vanaf uw lokale ontwikkelcomputer op een niet-Azure openbaar bronnetwerk. Gebruik dezelfde werkende databasetoegangsgegevens als de eerste query. De databaseverbinding moet worden geweigerd wanneer geen andere firewallregel dat bronadres toestaat.

Firewallregels evalueren het bronadres, niet of de client Azure CLI is. Gebruik geen Azure Cloud Shell voor deze negatieve test: de uitzondering voor Azure-services kan de verbinding toestaan. Een geslaagde query van een Azure gehoste client met geldige referenties geeft niet aan dat de firewallupdate is mislukt.

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Nadat de Azure-services-uitzondering enige tijd heeft gehad om van kracht te worden, haalt u de to-do items op via de geïmplementeerde toepassing. Controleer op HTTP 200 en een JSON-array met de to-do items die u eerder hebt gemaakt:

curl --include "https://$AZ_APP_URL/api/todos"

Als een nieuwe databaseverbinding na het propagatievenster nog steeds een onverwacht resultaat oplevert, controleert u de werkelijke firewallregels en het bronnetwerk van de client voordat u referenties wijzigt. Een applicatierespons zonder HTTP 200 en de verwachte JSON-gegevens geeft de positieve controle niet door.

Directe PostgreSQL-verbindingen van niet-Azure bronadressen worden geblokkeerd wanneer geen andere regel deze toestaat. Azure-origin-clients met geldige databasereferenties kunnen nog steeds verbinding maken. De HTTPS-API van de toepassing blijft openbaar; met deze controles wordt geen database-isolatie alleen voor de toepassing tot stand gebracht.