Access control overview

Azure Data Explorer access control is based on authentication and authorization. Each query and command on an Azure Data Explorer resource, such as a cluster or database, must pass both authentication and authorization checks.

  • Authentication: Validates the identity of the security principal making a request
  • Authorization: Validates the security principal making a request is permitted to make that request on the target resource

Authentication

To programmatically authenticate with your cluster, a client must communicate with Microsoft Entra ID and request an access token specific to Azure Data Explorer. Then, the client can use the acquired access token as proof of identity when issuing requests to your cluster.

The main authentication scenarios are as follows:

Note

For user and application authentication, we recommend using the Kusto client libraries. If you require On-behalf-of (OBO) or Single-Page Application (SPA) authentication, you'll need to use MSAL directly as these flows aren't supported by the client libraries. For more information, see Authenticate with Microsoft Authentication Library (MSAL).

User authentication

User authentication happens when a user presents credentials to Microsoft Entra ID or an identity provider that federates with Microsoft Entra ID, such as Active Directory Federation Services. The user gets back a security token that can be presented to the Azure Data Explorer service. Azure Data Explorer determines whether the token is valid, whether the token is issued by a trusted issuer, and what security claims the token contains.

Azure Data Explorer supports the following methods of user authentication, including through the Kusto client libraries:

  • Interactive user authentication with sign-in through the user interface.
  • User authentication with a Microsoft Entra token issued for Azure Data Explorer.
  • User authentication with a Microsoft Entra token issued for another resource that can be exchanged for an Azure Data Explorer token using On-behalf-of (OBO) authentication.

Application authentication

Application authentication is needed when requests aren't associated with a specific user or when no user is available to provide credentials. In this case, the application authenticates to Microsoft Entra ID or the federated IdP by presenting secret information.

Azure Data Explorer supports the following methods of application authentication, including through the Kusto client libraries:

  • Application authentication with an Azure managed identity.
  • Application authentication with an X.509v2 certificate installed locally.
  • Application authentication with an X.509v2 certificate given to the client library as a byte stream.
  • Application authentication with a Microsoft Entra application ID and a Microsoft Entra application key. The application ID and application key are like a username and password.
  • Application authentication with a previously obtained valid Microsoft Entra token, issued to Azure Data Explorer.
  • Application authentication with a Microsoft Entra token issued for another resource that can be exchanged for an Azure Data Explorer token using On-behalf-of (OBO) authentication.

Authorization

Before carrying out an action on an Azure Data Explorer resource, all authenticated users must pass an authorization check. Azure Data Explorer uses the Kusto role-based access control model, where principals are ascribed to one or more security roles. Authorization is granted as long as one of the roles assigned to the user allows them to perform the specified action. For example, the Database User role grants security principals the right to read the data of a particular database, create tables in the database, and more.

The association of security principals to security roles can be defined individually or by using security groups that are defined in Microsoft Entra ID. For more information on how to assign security roles, see Security roles overview.