Private connectivity and Entra identity for a bank's database estate

The two services need different mechanisms:

• Azure SQL Database: create a private endpoint in the VNet where the AKS nodes run and link a private DNS zone named privatelink.database.windows.net to that VNet. Only then set the logical server's public network access to Deny - doing it first breaks the deployment.
• Managed Instance: it is already VNet-injected, so there is no private endpoint to create. Peer the hub VNet to the instance's VNet and confirm NSG rules allow 1433 and 3342.

What breaks first is name resolution, not connectivity. The pods and the analysts' laptops will keep resolving the public gateway name and the connection will be refused or routed to a blocked public endpoint. Fixes:

• AKS: the cluster's DNS must forward the privatelink.database.windows.net zone to Azure (168.63.129.16) or to a DNS Private Resolver inbound endpoint.
• Analysts on VPN: the corporate DNS forwards only to public resolvers, so add conditional forwarders for the privatelink zone to the resolver's inbound endpoint.

Verify from a pod and from a laptop that nslookup returns the 10.x private address. Until it does, treat connectivity as unproven.

Give the AKS workload a user-assigned managed identity federated to the Kubernetes service account, then create a contained user in the database:

CREATE USER [mi-portal] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [mi-portal];
ALTER ROLE db_datawriter ADD MEMBER [mi-portal];
GRANT EXECUTE ON SCHEMA::dbo TO [mi-portal];

Prerequisites that fail silently if missed: a Microsoft Entra admin must be set on the logical server, the identity must live in the same tenant, and the connection string must change to Authentication=Active Directory Managed Identity;User Id=<client-id>.

Avoid over-privileging: do not add db_owner because the deployment "needs it" - grant a custom role for the specific DDL the app performs. Delete the Kubernetes secret and its history afterward.

For the Managed Instance, the same identity can be a server-level Entra login (CREATE LOGIN ... FROM EXTERNAL PROVIDER), which Azure SQL Database does not support. That matters if the lending app uses cross-database queries; contained users alone will not cover them.

Customer-managed keys for TDE: create the key vault with soft delete and purge protection enabled first - Azure SQL refuses a vault without them, because deleting the key would render the database unrecoverable. Use an RSA 2048/3072/4096 key, and grant the server's and the instance's system-assigned managed identity get, wrapKey, unwrapKey (Key Vault RBAC role Key Vault Crypto Service Encryption User).

Accepted risks to document: if the key is disabled, deleted, or the vault firewall blocks the SQL service, the database goes offline. Keep the "allow trusted Microsoft services" bypass on, and rehearse key rotation.

Auditing: enable it at server and instance level so it covers every database including future ones, writing to a storage account configured with immutable blob storage using a time-based retention policy of at least 7 years (legal hold is the alternative). A mutable container fails the requirement even though the audit records are there.

Add Log Analytics as a second sink only if you need alerting on failed logins; the immutable storage account is the compliance record and should not be the alerting path.