|
| 1 | +--- |
| 2 | +title: How to administrate data authentication |
| 3 | +titleSuffix: Azure Machine Learning |
| 4 | +description: Learn how to manage data access and how to authenticate in Azure Machine Learning |
| 5 | +services: machine-learning |
| 6 | +ms.service: machine-learning |
| 7 | +ms.subservice: enterprise-readiness |
| 8 | +ms.topic: how-to |
| 9 | +ms.author: xunwan |
| 10 | +author: xunwan |
| 11 | +ms.reviewer: larryfr |
| 12 | +ms.date: 05/24/2022 |
| 13 | + |
| 14 | +# Customer intent: As an administrator, I need to administrate data access and set up authentication method for data scientists. |
| 15 | +--- |
| 16 | + |
| 17 | +# How to authenticate data access |
| 18 | +Learn how to manage data access and how to authenticate in Azure Machine Learning |
| 19 | +[!INCLUDE [sdk v2](../../includes/machine-learning-sdk-v2.md)] |
| 20 | +[!INCLUDE [cli v2](../../includes/machine-learning-cli-v2.md)] |
| 21 | + |
| 22 | +> [!IMPORTANT] |
| 23 | +> The information in this article is intended for Azure administrators who are creating the infrastructure required for an Azure Machine Learning solution. |
| 24 | +
|
| 25 | +In general, data access from studio involves the following checks: |
| 26 | + |
| 27 | +* Who is accessing? |
| 28 | + - There are multiple different types of authentication depending on the storage type. For example, account key, token, service principal, managed identity, and user identity. |
| 29 | + - If authentication is made using a user identity, then it's important to know *which* user is trying to access storage. Learn more about [identity-based data access](how-to-identity-based-data-access.md). |
| 30 | +* Do they have permission? |
| 31 | + - Are the credentials correct? If so, does the service principal, managed identity, etc., have the necessary permissions on the storage? Permissions are granted using Azure role-based access controls (Azure RBAC). |
| 32 | + - [Reader](../role-based-access-control/built-in-roles.md#reader) of the storage account reads metadata of the storage. |
| 33 | + - [Storage Blob Data Reader](../role-based-access-control/built-in-roles.md#storage-blob-data-reader) reads data within a blob container. |
| 34 | + - [Contributor](../role-based-access-control/built-in-roles.md#contributor) allows write access to a storage account. |
| 35 | + - More roles may be required depending on the type of storage. |
| 36 | +* Where is access from? |
| 37 | + - User: Is the client IP address in the VNet/subnet range? |
| 38 | + - Workspace: Is the workspace public or does it have a private endpoint in a VNet/subnet? |
| 39 | + - Storage: Does the storage allow public access, or does it restrict access through a service endpoint or a private endpoint? |
| 40 | +* What operation is being performed? |
| 41 | + - Create, read, update, and delete (CRUD) operations on a data store/dataset are handled by Azure Machine Learning. |
| 42 | + - Data Access calls (such as preview or schema) go to the underlying storage and need extra permissions. |
| 43 | +* Where is this operation being run; compute resources in your Azure subscription or resources hosted in a Microsoft subscription? |
| 44 | + - All calls to dataset and datastore services (except the "Generate Profile" option) use resources hosted in a __Microsoft subscription__ to run the operations. |
| 45 | + - Jobs, including the "Generate Profile" option for datasets, run on a compute resource in __your subscription__, and access the data from there. So the compute identity needs permission to the storage rather than the identity of the user submitting the job. |
| 46 | + |
| 47 | +The following diagram shows the general flow of a data access call. In this example, a user is trying to make a data access call through a machine learning workspace, without using any compute resource. |
| 48 | + |
| 49 | +:::image type="content" source="./media/concept-network-data-access/data-access-flow.svg" alt-text="Diagram of the logic flow when accessing data."::: |
| 50 | + |
| 51 | +## Scenarios and identities |
| 52 | + |
| 53 | +The following table lists what identities should be used for specific scenarios: |
| 54 | + |
| 55 | +| Scenario | Use workspace</br>Managed Service Identity (MSI) | Identity to use | |
| 56 | +|--|--|--| |
| 57 | +| Access from UI | Yes | Workspace MSI | |
| 58 | +| Access from UI | No | User's Identity | |
| 59 | +| Access from Job | Yes/No | Compute MSI | |
| 60 | +| Access from Notebook | Yes/No | User's identity | |
| 61 | + |
| 62 | + |
| 63 | +Data access is complex and it's important to recognize that there are many pieces to it. For example, accessing data from Azure Machine Learning studio is different than using the SDK. When using the SDK on your local development environment, you're directly accessing data in the cloud. When using studio, you aren't always directly accessing the data store from your client. Studio relies on the workspace to access data on your behalf. |
| 64 | + |
| 65 | +> [!TIP] |
| 66 | +> If you need to access data from outside Azure Machine Learning, such as using Azure Storage Explorer, _user_ identity is probably what is used. Consult the documentation for the tool or service you are using for specific information. For more information on how Azure Machine Learning works with data, see [Identity-based data access to storage services on Azure](how-to-identity-based-data-access.md). |
| 67 | +
|
| 68 | +## Azure Storage Account |
| 69 | + |
| 70 | +When using an Azure Storage Account from Azure Machine Learning studio, you must add the managed identity of the workspace to the following Azure RBAC roles for the storage account: |
| 71 | + |
| 72 | +* [Blob Data Reader](../role-based-access-control/built-in-roles.md#storage-blob-data-reader) |
| 73 | +* If the storage account uses a private endpoint to connect to the VNet, you must grant the managed identity the [Reader](../role-based-access-control/built-in-roles.md#reader) role for the storage account private endpoint. |
| 74 | + |
| 75 | +For more information, see [Use Azure Machine Learning studio in an Azure Virtual Network](how-to-enable-studio-virtual-network.md). |
| 76 | + |
| 77 | +See the following sections for information on limitations when using Azure Storage Account with your workspace in a VNet. |
| 78 | + |
| 79 | +### Secure communication with Azure Storage Account |
| 80 | + |
| 81 | +To secure communication between Azure Machine Learning and Azure Storage Accounts, configure storage to [Grant access to trusted Azure services](../storage/common/storage-network-security.md#grant-access-to-trusted-azure-services). |
| 82 | + |
| 83 | +### Azure Storage firewall |
| 84 | + |
| 85 | +When an Azure Storage account is behind a virtual network, the storage firewall can normally be used to allow your client to directly connect over the internet. However, when using studio it isn't your client that connects to the storage account; it's the Azure Machine Learning service that makes the request. The IP address of the service isn't documented and changes frequently. __Enabling the storage firewall will not allow studio to access the storage account in a VNet configuration__. |
| 86 | + |
| 87 | +### Azure Storage endpoint type |
| 88 | + |
| 89 | +When the workspace uses a private endpoint and the storage account is also in the VNet, there are extra validation requirements when using studio: |
| 90 | + |
| 91 | +* If the storage account uses a __service endpoint__, the workspace private endpoint and storage service endpoint must be in the same subnet of the VNet. |
| 92 | +* If the storage account uses a __private endpoint__, the workspace private endpoint and storage service endpoint must be in the same VNet. In this case, they can be in different subnets. |
| 93 | + |
| 94 | +## Azure Data Lake Storage Gen1 |
| 95 | + |
| 96 | +When using Azure Data Lake Storage Gen1 as a datastore, you can only use POSIX-style access control lists. You can assign the workspace's managed identity access to resources just like any other security principal. For more information, see [Access control in Azure Data Lake Storage Gen1](../data-lake-store/data-lake-store-access-control.md). |
| 97 | + |
| 98 | +## Azure Data Lake Storage Gen2 |
| 99 | + |
| 100 | +When using Azure Data Lake Storage Gen2 as a datastore, you can use both Azure RBAC and POSIX-style access control lists (ACLs) to control data access inside of a virtual network. |
| 101 | + |
| 102 | +**To use Azure RBAC**, follow the steps in the [Datastore: Azure Storage Account](how-to-enable-studio-virtual-network.md#datastore-azure-storage-account) section of the 'Use Azure Machine Learning studio in an Azure Virtual Network' article. Data Lake Storage Gen2 is based on Azure Storage, so the same steps apply when using Azure RBAC. |
| 103 | + |
| 104 | +**To use ACLs**, the managed identity of the workspace can be assigned access just like any other security principal. For more information, see [Access control lists on files and directories](../storage/blobs/data-lake-storage-access-control.md#access-control-lists-on-files-and-directories). |
| 105 | + |
| 106 | + |
| 107 | +## Next steps |
| 108 | + |
| 109 | +For information on enabling studio in a network, see [Use Azure Machine Learning studio in an Azure Virtual Network](how-to-enable-studio-virtual-network.md). |
0 commit comments