For the complete documentation index, see llms.txt. This page is also available as Markdown.

Azure SQL Server: Managed Identity Authentication

Authenticate to Azure SQL Database using a Microsoft Entra managed identity, with no stored password or secret.

Telmai can authenticate to your Azure SQL Database using a Microsoft Entra managed identity that you provide and register, so no password or secret is ever stored. Each connection authenticates as a specific identity you choose — for example, one identity per database, each with only the access it needs.

This guide walks through the one-time setup for each managed identity you want Telmai to use.

For username and password (SQL Authentication) setup, see SQL Server.

How it works

Telmai's pods run under an Azure Kubernetes workload identity. That workload identity only obtains tokens — it is never itself used to read your data. For each managed identity you register, you allow Telmai's pods to obtain that identity's token; each connection then authenticates as the identity you selected for it. When a scan runs, Telmai requests a short-lived Microsoft Entra token for that identity and connects with it.

There is no shared or default identity for data access — every connection uses one of the identities you set up and registered.

Two identifiers you will use. Creating a managed identity gives you two different ids, and each is used in exactly one place. Keep them straight:

  • Client ID → used when the identity is registered in Telmai (Step 4).

  • Object ID (also shown as Principal ID / Object (principal) ID) → used in the SQL grant (Step 2).

Before you begin

  • Your Telmai instance is deployed on Azure (see the warning above).

  • The Azure administrator can create identities and federated credentials (the az CLI examples below, or the Azure portal).

  • The Azure SQL server already has a Microsoft Entra admin configured. The grant in Step 2 must be run as that admin (a SQL-authenticated login cannot create Entra users).

  • Telmai will provide three values for the federation in Step 3: the ServiceAccount name, its namespace, and the cluster OIDC issuer URL.

Who does what

This setup spans up to three roles, which may be different people in your organization:

Step
Task
Owner

1

Create the managed identity

Azure administrator

2

Grant the identity read access on the database

Database administrator

3

Federate the identity to Telmai's ServiceAccount

Azure administrator

4

Register the identity in Telmai

Telmai administrator

5

Create the connection and select the identity

Telmai user

6

Verify the connection

Telmai user

Step 1: Create the managed identity

The Azure administrator creates a user-assigned managed identity (UAMI). Do this in the Managed Identities blade of the portal, or with the CLI:

Then read the two identifiers needed later:

Note both values now:

  • Client ID — used in Telmai in Step 4.

  • Object ID (the CLI calls it principalId) — used in the SQL grant in Step 2.

Step 2: Grant access on the SQL Database

The Database administrator creates a database user mapped to the managed identity and grants it read access, in the target database. Run this via a SQL client (SSMS, Azure Data Studio, or the portal Query editor), connected with Microsoft Entra authentication as the server's Entra admin (or a db_owner).

  • <identity-name> is the name given to the identity in Step 1.

  • <object-id> is the Object ID from Step 1 (not the Client ID).

Read access (db_datareader) is all a data-quality scan needs. Grant each identity only what its databases require — registering a separate identity per database keeps permissions least-privilege.

Step 3: Allow Telmai's pods to use the identity (federation)

The Azure administrator adds a federated credential on the identity that trusts Telmai's Kubernetes ServiceAccount. Telmai provides the ServiceAccount name, namespace, and OIDC issuer URL.

The federated-credential name (federated-<identity-name> above) is only a label — any name works. What establishes trust is the combination of issuer, subject, and audience. No ServiceAccount setting is changed; each identity simply adds its own federated credential trusting the same ServiceAccount.

Step 4: Register the identity in Telmai

The Telmai administrator adds the identity so it can be selected on connections.

  1. Go to Administration → Managed Identities.

  2. Select Add Identity.

  3. Enter a Name (how it appears when creating a connection), the identity's Client ID (from Step 1), and optionally a Description.

  4. Save.

The Managed Identities section under Administration, listing registered identities with Name, Client ID, Status and Description columns
Administration → Managed Identities. Use the Client ID here, not the Object ID.

At least one identity must be registered before a managed-identity connection can be created. Registered identities appear as Active; you can Revoke an identity to stop it being used (reversible) or Remove it entirely.

Step 5: Create the connection

The Telmai user creates (or edits) an MS SQL Server connection and chooses the registered managed identity.

  1. Connection Type — MS SQL Server.

  2. Name — a name for the connection.

  3. Schema — the schema to connect to, for example SalesLT.

  4. Server — your Azure SQL server, e.g. your-server.database.windows.net.

  5. Database — the target database.

  6. Port1433.

  7. Authentication Scheme — select Managed Identity (connection).

  8. Managed Identity — pick one of the registered identities from the list.

The Authentication Scheme list offers three options:

Scheme
What it uses

SQL Server Authentication

A SQL Server username and password, stored on the connection

Microsoft Entra Password

A Microsoft Entra username and password, stored on the connection

Managed Identity (connection)

A managed identity registered in Step 4 — no user or password is stored

Select Managed Identity (connection). The form then replaces the User and Password fields with the Managed Identity picker.

The Create Connection panel for MS SQL Server with the Authentication Scheme dropdown open, showing SQL Server Authentication, Microsoft Entra Password and Managed Identity (connection)
The three authentication schemes available on an MS SQL Server connection.

Once the scheme is set, choose the identity to authenticate as:

An MS SQL Server connection with Authentication Scheme set to Managed Identity (connection) and a registered identity selected
With Managed Identity (connection) selected, no user or password is required.

Only identities registered for your tenant (Step 4) can be chosen — there is no free-text entry, so a connection can never point at an unregistered identity. The list shows each identity's name alongside the tail of its client id so you can confirm which one you are selecting.

Step 6: Verify

Select Test Connection. A successful test confirms the identity was granted on the database and the federation is in place. You can then create assets from this connection as usual.

Last updated