Using Managed Identities for containers running in PCF to access Azure Blob Storage

Question

I would like to know if it is possible to access a blob storage by a container running in Pivotal Cloud Foundry in Azure using a Managed Identity , say system assigned managed identity, or i need to use a Service Principal Object. Any help is appreciated. Earlier we were using SAS by coding the URL in the code, but want to use Azure AD to do authentication of our API app running inside container. So what is the best way to achieve this

It is Java. The App is going to fetch data from Azure Blob Storage by querying the metadata in blob storage. The app will be hosted in the containers running in the PCF platform in Azure — Pallab

Joy Wang Joy Wang · Accepted Answer · 2021-03-09T07:32:06

In Pivotal Cloud Foundry, you could not use the managed identity(MSI) to auth, when using MSI to auth, it essentially makes an API call to azure instance metadata endpoint to get the access token, then use the token to auth, it is just available in an Azure environment support MSI.

In this case, the best practice is to use a service principal to auth as you mentioned, please follow the steps below.

1.Register an application with Azure AD and create a service principal.

2.Get values for signing in and create a new application secret.

3.Navigate to the storage account in the portal -> Access Control (IAM) -> assign a Storage Blob Data Contributor/Storage Blob Data Owner role to the service principal like below.

4.The use the java code below, to do a quick test, in my sample, I list all the blobs in a container, just do other things depends on your requirement, replace the values with yours got from step 2.

pom.xml:

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity</artifactId>
    <version>1.2.0</version>
</dependency>
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-storage-blob</artifactId>
    <version>12.11.0-beta.1</version>
</dependency>

Code:

import com.azure.identity.ClientSecretCredential;
import com.azure.identity.ClientSecretCredentialBuilder;
import com.azure.storage.blob.BlobContainerClient;
import com.azure.storage.blob.BlobServiceClient;
import com.azure.storage.blob.BlobServiceClientBuilder;
import com.azure.storage.blob.models.BlobItem;

public  class vacate {
    public static void main(String[] args) {
        String clientId="xxxxxx";
        String clientSecret="xxxxxx";
        String tenantId="xxxxxx";

        ClientSecretCredential credential1 = new ClientSecretCredentialBuilder()
                .tenantId(tenantId)
                .clientId(clientId)
                .clientSecret(clientSecret)
                .build();

        BlobServiceClient storageClient = new BlobServiceClientBuilder()
                .endpoint("https://joystoragev2.blob.core.windows.net")
                .credential(credential1)
                .buildClient();

        BlobContainerClient containerClient = storageClient.getBlobContainerClient("tescon1");
        System.out.println("\nListing blobs...");

        for (BlobItem blobItem : containerClient.listBlobs()) {
            System.out.println("\t" + blobItem.getName());
        }
    }
}

For more details, see Quickstart: Manage blobs with Java v12 SDK.

Update:

If you want a user-interactive way to auth, just use these ways - Authenticating Users instead of ClientSecretCredential.

Actually different auth ways in SDK use different auth flows in Azure AD, e.g. ClientSecretCredential uses client credential flow, it is a non-interactive way, DeviceCodeCredential uses device code flow, it is user-interactive way.

To use these user-interactive ways in your case, you need to navigate to the AD App in the portal -> add the delegated permission user_impersonation of Azure storage.

suppose a particular user should have only read access to the Blob Endpoint and another user might have full CRUD access to the Blob Endpoint, how this will be determined when the user calls this API from a front end application?

Yes, this can be achieved by the delegated permission added above. When the user use the auth ways to login the AD App, the App will let the user consent the user_impersonation permission, after consent(the AAD tenant of the user needs to allow the users to consent the permission by theirselves), the AD App will get the permission from the user, then act on behalf of the user. In short, the permission of the app comes from the user, different users have different permissions, then app will have different permissions.

So in your case, just add users with different roles in the storage account like step 3 above. For read access, just add Storage Blob Data Reader, for CURD access, add Storage Blob Data Contributor/Storage Blob Data Owner, then use the user-interactive ways above, it will work.

Using Managed Identities for containers running in PCF to access Azure Blob Storage

1 Answers