Shared access vs Single user access mode

[naga_databricks]

I am running a notebook to get secret value from GCP Secret Manager. This is working well with Single user Access Mode, however it fail when i use a cluster with Shared Access mode. I have specified the same GCP service account on both of these clusters. Below is the error i get with Shared Access mode:

RetryError: Deadline of 60.0s exceeded while calling target function, last exception: 503 Getting metadata from plugin failed with error: Failed to retrieve http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true from the Google Compute Engine metadata service. Compute Engine Metadata server unavailable

Are there differences in the accessibility to cloud resources between these 2 types of clusters?

[Kaniz]

Hi @naga_databricks , 

Yes, there are differences in the accessibility to cloud resources between two types of Databricks clusters: Single-user and Shared clusters.

Single-user clusters are associated with the user's identity and they have access to the user's cloud resources, such as Google Cloud Platform (GCP) service accounts and keys. Therefore, when you run a notebook using a Single-user cluster, the notebook has access to the user's GCP service account.

Shared clusters, on the other hand, are not associated with a single user identity and they run under a Databricks-managed service account that has limited access to cloud resources. This means that if you want to access your GCP service account from a Shared cluster, you will need to explicitly grant access to the service account used by the Shared cluster.

To grant access to your GCP service account, you can follow these steps:

1. Create a GCP service account and grant it the necessary permissions to access your secret in Secret Manager.

2. Generate a key for the service account and download it as a JSON file.

3. Create a Databricks secret scope and store the service account key in the secret scope. You can use the Databricks CLI or REST API to create the secret scope and store the service account key.

4. Grant the necessary permissions to the Databricks-managed service account to access the secret scope. You can grant the necessary permissions using the gcloud CLI tool or the GCP Console.

5. In your notebook, use the dbutils.secrets.get() method to access the service account key from the secret scope and authenticate the GCP client with the key.

By following these steps, you can grant access to your GCP service account from a Shared cluster and access your secrets without running into authentication errors.

[naga_databricks]

Thanks for your response.

I am using a cloud service account (same account that was used to create the workspace) on the cluster properties in case of both the single user cluster and on the shared user cluster. This service account has all the necessary access to the cloud resources (secretsAccessor).

With a single user cluster, i am able to mention the service account and able to access the secrets. I did not have to keep the JSON file of the service key in a secret scope. This means, the cluster is with my user ownership, and i just specified the cloud service account, which enabled me to access the underlying cloud resources.  

I was earlier using other type of the cluster called "No Isolation Shared", for this specifying the cloud service account was sufficient.

How does the service account property on the cluster configuration work? does it always need the service account key? or is it only for the Shared user cluster type.