Edit

Cross-tenant customer-managed keys with transparent data encryption

  • Article

Applies to: Azure SQL Database Azure Synapse Analytics (dedicated SQL pools only)

Azure SQL now offers support for cross-tenant customer-managed keys (CMK) with transparent data encryption (TDE). Cross-tenant CMK expands on the Bring Your Own Key (BYOK) scenario for utilizing TDE without the need to have the logical server in Azure in the same Microsoft Entra tenant as the Azure Key Vault that stores the customer-managed key used to protect the server.

You can configure TDE with CMK for Azure SQL Database for keys stored in key vaults that are configured in different Microsoft Entra tenants. Microsoft Entra ID (formerly Azure Active Directory) introduces a feature called workload identity federation, and it allows Azure resources from one Microsoft Entra tenant the capability to access resources in another Microsoft Entra tenant.

For documentation on transparent data encryption for dedicated SQL pools inside Synapse workspaces, see Azure Synapse Analytics encryption.

Note

Microsoft Entra ID was previously known as Azure Active Directory (Azure AD).

Common use scenario

Cross-tenant CMK capabilities allow service providers or independent software vendors (ISV) building services on top of Azure SQL to extend Azure SQL's TDE with CMK capabilities to their respective customers. With cross-tenant CMK support enabled, ISV customers can own the key vault and encryption keys in their own subscription and Microsoft Entra tenant. The customer has full control over key management operations, while accessing Azure SQL resources in the ISV tenant.

Cross-tenant interactions

Cross-tenant interaction between Azure SQL and a key vault in another Microsoft Entra tenant is enabled with the Microsoft Entra feature, workload identity federation.

ISVs that deploy Azure SQL services can create a multi-tenant application in Microsoft Entra ID, and then configure a federated identity credential for this application using a user-assigned managed identity. With the appropriate application name and application ID, a client or ISV customer can install the ISV created application in their own tenant. The customer then grants the service principal associated with the application permissions (needed for Azure SQL) to their key vault in their tenant, and shares their key location with the ISV. Once the ISV assigns the managed identity and federated client identity to the Azure SQL resource, the Azure SQL resource in the ISV's tenant can access the customer's key vault.

For more information, see:

Setting up cross-tenant CMK

The following diagram represents the steps for a scenario that utilizes an Azure SQL logical server that uses TDE to encrypt the data at rest using a cross-tenant CMK with a user-assigned managed identity.

Diagram of setting up cross-tenant transparent data encryption with customer-managed keys.

Overview of the setup

On the ISV tenant

  1. Create a user-assigned managed identity

  2. Create a multi-tenant application

    1. Configure the user-assigned managed identity as a federated credential on the application

On the client tenant

  1. Install the multi-tenant application

  2. Create or use existing key vault and grant key permissions to the multi-tenant application

    1. Create a new or use an existing key

    2. Retrieve the key from Key Vault and record the Key Identifier

On the ISV tenant

  1. Assign the user-assigned managed identity created as the Primary identity in the Azure SQL resource Identity menu in the Azure portal

  2. Assign the Federated client identity in the same Identity menu, and use the application name

  3. In the Transparent data encryption menu of the Azure SQL resource, assign a Key identifier using the customer's Key Identifier obtained from the client tenant.

Remarks

Next steps

Create server configured with user-assigned managed identity and cross-tenant CMK for TDE

See also