Azure Synapse access control

  • Article

This article provides an overview of the mechanisms available to control access to Azure Synapse compute resources and data.

Overview

Azure Synapse provides a comprehensive and fine-grained access control system, that integrates:

  • Azure roles for resource management and access to data in storage
  • Synapse roles for managing live access to code and execution
  • SQL roles for data plane access to data in SQL pools

Azure Synapse roles provide sets of permissions that can be applied at different scopes. This granularity makes it easy to grant appropriate access to administrators, developers, security personnel, and operators to compute resources and data.

Access control can be simplified by using security groups that are aligned with people's job roles. You only need to add and remove users from appropriate security groups to manage access.

Access control elements

Create and manage Azure Synapse compute resources

Azure roles are used to control management of:

  • Dedicated SQL pools
  • Apache Spark pools
  • Integration runtimes

To create these resources, you need to be an Azure Owner or Contributor on the resource group. To manage them once created, you need to be an Azure Owner or Contributor on either the resource group or the individual resources.

An Azure Owner or Contributor can enable or disable Microsoft Entra-only authentication for Azure Synapse workspaces. For more information on Microsoft Entra-only authentication, see Disabling local authentication in Azure Synapse Analytics.

Develop and execute code in Azure Synapse

You develop and debug code in Synapse Studio and then publish it to save and execute. The Synapse service is the source of truth for code editing and execution. Any unpublished work is lost when you close Synapse Studio.

Any user with access to Synapse Studio can create code artifacts. However, you need additional permissions to publish artifacts to the service, read published artifacts, to execute code, and to access linked data protected by credentials.

Azure Synapse roles

Azure Synapse roles are used to control access to the Synapse service. Different roles can permit you to:

  • List published code artifacts,
  • Publish code artifacts, linked services, and credential definitions,
  • Execute code or pipelines that use Synapse compute resources,
  • Execute code or pipelines that access linked data protected by credentials,
  • View outputs associated with published code artifacts,
  • Monitor compute resource status, and view runtime logs.

Azure Synapse roles can be assigned at the workspace scope or at finer-grained scopes to limit the permissions granted to specific Azure Synapse resources.

Access data in SQL

When working with dedicated and serverless SQL pools, data plane access is controlled using SQL permissions.

The creator of a workspace is assigned as the Active Directory Admin on the workspace. After creation, this role can be assigned to a different user or to a security group in the Azure portal.

Serverless SQL pools: Synapse Administrators are granted db_owner (DBO) permissions on the serverless SQL pool, 'Built-in'. To grant other users access to the serverless SQL pool, Synapse administrators need to run SQL scripts on the serverless pool.

Dedicated SQL pools: Synapse Administrators have full access to data in dedicated SQL pools, and the ability to grant access to other users. Synapse Administrators can also perform configuration and maintenance activities on dedicated pools, except for dropping databases. Active Directory Admin permission is granted to the creator of the workspace and the workspace MSI. Permission to access dedicated SQL pools isn't otherwise granted automatically. To grant other users or groups access to dedicated SQL pools, the Active Directory Admin or Synapse Administrator must run SQL scripts against each dedicated SQL pool.

See How to set up Synapse Access Control for examples of SQL scripts for granting SQL permissions in SQL pools.

Accessing system-managed data in storage

Serverless SQL pools and Apache Spark tables store their data in an ADLS Gen2 container associated with the workspace. User-installed Apache Spark libraries are also managed in the same storage account. To enable these use cases, users and the workspace MSI must be granted Storage Blob Data Contributor access to this workspace ADLS Gen2 storage container.

Using security groups as a best practice

To simplify managing access control, you can use security groups to assign roles to individuals and groups. Security groups can be created to mirror personas or job functions in your organization that need access to Synapse resources or artifacts. These persona-based security groups can then be assigned one or more Azure roles, Synapse roles, SQL permissions. With well-chosen security groups, it's easy to assign a user the required permissions by adding them to the appropriate security group.

Note

If using security groups to manage access, there is additional latency introduced by Microsoft Entra ID before changes take effect.

Access control enforcement in Synapse Studio

Synapse Studio will behave differently based on your permissions: Synapse Studio will prevent you from seeing published content, publishing content, or taking other actions if you don't have the required permission. In some cases, you'll be prevented from creating code artifacts that you can't use or save.

In some cases, you're allowed to create code artifacts even without permission to publish or commit. This allows you to execute code (with the required execution permissions). For more information on the roles required for common tasks, see Understand the roles required to perform common tasks in Azure Synapse.

If a feature is disabled in Synapse Studio, a tooltip will indicate the required permission. Use the Synapse RBAC roles guide to look up which role is required to provide the missing permission.

Next steps