[Bug]: DAB local container support for Entra ID to Azure databases

[croblesm]

Description

The official DAB container image (mcr.microsoft.com/azure-databases/data-api-builder:latest) does not include the Azure CLI or a method to authenticate users to Azure/Fabric. This means that when running DAB in a container with Authentication=Active Directory Default, DefaultAzureCredential cannot find any credential provider and authentication fails.

Active Directory Interactive authentication is also not viable in a container since there is no browser or interactive prompt available.

This effectively makes it impossible to connect DAB containers to SQL Database in Microsoft Fabric or Azure SQL Database using Entra ID authentication outside of Azure-hosted compute (where Managed Identity is available via IMDS at 169.254.169.254).

Fabric SQL authentication incompatibility

DAB running in a local Docker container only supports two authentication methods against Fabric SQL: System-Assigned Managed Identity (SAMI) and User-Assigned Managed Identity (UAMI). The default Entra ID connection mode used by the MSSQL extension (ActiveDirectoryInteractive) attempts to open a browser for the Azure AD login flow, which fails immediately inside a headless Linux container (0xlinux_xdg_open_failed). Fabric SQL does not support SQL authentication at all, so there is no fallback. Local DAB container deployment against Fabric SQL is not a viable scenario in its current form.

The root cause is that the official DAB container image does not include the Azure CLI, so DefaultAzureCredential has no way to authenticate inside the container. Managed Identity (UAMI/SAMI) does not work either since the IMDS endpoint (169.254.169.254) is only available inside Azure compute resources — not in local Docker containers.

It is worth noting this is not isolated to DAB. SQL Database in Fabric's Entra-only authentication model also blocks connectivity from popular tools like SQLAlchemy, Prisma, and other ORMs for the same reason. Developers are already running into this pattern across the ecosystem, and hitting it again through DAB will compound existing frustration.

Related upstream issue: microsoft/vscode-mssql#21517

Steps to reproduce

1. Pull the official DAB image:

   docker pull mcr.microsoft.com/azure-databases/data-api-builder:latest

2. Configure dab-config.json with a Fabric SQL (or Azure SQL) connection string using Azure AD:

   {
     "data-source": {
       "database-type": "mssql",
       "connection-string": "Server=tcp:<server>.msit-database.fabric.microsoft.com,1433;Initial Catalog=<database>;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Authentication=Active Directory Default"
     }
   }

3. Run the container:

   docker run -p 5001:5000 \
     -v $(pwd)/dab-config.json:/App/dab-config.json \
     mcr.microsoft.com/azure-databases/data-api-builder:latest

4. Authentication fails because DefaultAzureCredential exhausts all credential providers:

   • Environment variables — not set
   • Workload Identity — not available
   • Managed Identity (IMDS) — unreachable outside Azure compute
   • Azure CLI — not installed in the image

Expected behavior

The DAB container image should support Azure AD authentication out of the box, or the documentation should clearly state the limitation and provide a workaround.

Current workaround

Build a custom image that installs Azure CLI and mount the host's ~/.azure credentials into the container:

FROM mcr.microsoft.com/azure-databases/data-api-builder:latest
USER root
RUN tdnf install -y azure-cli && tdnf clean all

az login

docker build -t dab-fabric .

docker run -d --name dab-fabric -p 5001:5000 \
  -v ~/.azure:/root/.azure \
  -v $(pwd)/dab-config.json:/App/dab-config.json \
  -u root \
  dab-fabric

This works, but it is not a user-friendly experience:

• The custom container requires the user to mount the local ~/.azure folder into the container to pass down the cached MSAL tokens and refresh credentials.
• The container must run as root because the Azure CLI needs write access to its cache files (versionCheck.json, msal_token_cache.json) at runtime. The default app user in the DAB image does not have permission to write to the mounted directory.

Full example: https://github.com/croblesm/dab-fabric-container

Related issues and discussions

• #2328 — User tried connecting DAB in Azure Container Apps to a Fabric SQL endpoint; hit a Microsoft.Data.SqlClient bug causing connection failures.
• #2612 — A user acknowledged Active Directory Interactive is dev-only and "wouldn't be the correct choice" for deployed environments.
• #2318 — Covers using DAB with a Fabric SQL endpoint using Active Directory Default and database-type: dwsql.
• #1609 — Users found the base DAB container image is missing system-level components, requiring custom images to add dependencies.
• microsoft/vscode-mssql#21517 — Related Entra ID authentication failure when connecting to Fabric SQL from the MSSQL extension.

Suggested improvements

1. Include Azure CLI in the base DAB container image so AzureCliCredential works when users mount their ~/.azure directory.
2. Document the authentication options matrix — which auth modes work in which deployment scenarios (local CLI, local Docker, Azure Container Apps, AKS, etc.).
3. Add a Docker + Azure AD example to the container deployment guide.

Environment

• DAB image: mcr.microsoft.com/azure-databases/data-api-builder:latest
• Base OS: CBL-Mariner 2.0
• Target database: SQL Database in Microsoft Fabric (also affects Azure SQL Database)

Version

1.7.90

What database are you using?

Azure SQL

What hosting model are you using?

Local (including CLI)

Which API approach are you accessing DAB through?

REST

Relevant log output

Azure.DataApiBuilder.Service.Exceptions.DataApiBuilderException: Cannot obtain Schema for entity Customers with underlying database object source: dbo.Customers due to: Failed to authenticate the user in Active Directory (Authentication=ActiveDirectoryInteractive).

Code of Conduct

• I agree to follow this project's Code of Conduct