cancel
Showing results for 
Search instead for 
Did you mean: 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to create workspace using API

Jeff4
New Contributor

Hi all,

I'm trying to automate the deployment of Databricks into GCP. In order to streamline the process, I created a standalone project to hold the service accounts SA1 and SA2, with the second one then being manually populated into the Databricks account console as an "Account Admin" user. The idea was that this would then be a one-time manual intervention, allowing SA2 to be used for all workspace creation tasks regardless of the environment / project (each of our environments is a dedicated project in GCP). I have provisioned the SA2 account as "owner" of the project that will host the workspace, however this does not appear to be sufficient to create the workspace.

The API returns a 201 response, and the new workspace appears in the account console, but with a Status as "Failed", and a Status Message as "Workspace failed to launch. Error: Unknown Error." I can see no associated errors in the GCP logs for the project.

If I create the SA1 and SA2 accounts in the workspace project, the workspace is created successfully, which suggests to me that either a) there are additional roles I need to consider to enable SA2 to be hosted from a different project, or b) the workspace creation can only be conducted by a SA hosted on the workspace project.

Would anyone be able to advise on which of these is true?

Many thanks in advance

1 REPLY 1

Louis_Frolio
Databricks Employee
Databricks Employee

Greetings @Jeff4 ,  thanks for laying out the setup and symptoms so clearly. Short answer: it’s not required that the workspace-creating service account be hosted in the same GCP project as the workspace; cross‑project is supported. The failure you’re seeing is almost certainly due to missing or restricted permissions on the target workspace project (most commonly the absence/disablement of the Compute Engine default service account), not the location of SA2 itself.

What’s supported

  • A Databricks account admin (user or service account) can create a workspace as long as they hold the required Google permissions on the target workspace project. The creator can be from a different project; the key is having rights on the workspace project where Databricks will deploy resources.
  • During creation, Databricks uses the workspace creator’s credentials to grant permissions to a per‑workspace service account and to set up required resources in your project. That process requires specific IAM privileges on the target project.

Likely root cause of “Failed / Unknown Error”

The most common cause for a GCP workspace creation that returns 201 but later shows “Failed” is that the Compute Engine default service account (format: “<project-number>-compute@developer.gserviceaccount.com”) is missing or disabled in the target project. Databricks relies on this identity by default to run GKE nodes; if it’s absent, the IAM policy grant step fails (often surfaced as “Unknown service account”), and the workspace provisioner aborts. If the project is more than ~30 days old and the default compute SA was never created (or later deleted), GCP won’t auto‑recreate it; the recommended fix is to use a new project or provide a compliant compute SA.
 

Cross‑project SA2 vs same‑project SA2

  • It is not required that SA2 live in the workspace project; cross‑project identities work as long as SA2 has the necessary IAM on the workspace project (and any host project if using Shared VPC). The “same‑project” success you observed likely indicates the target project had the required compute SA and/or fewer org policy restrictions, rather than a platform limitation about SA location.

Required permissions for the workspace creator (SA2)

Ensure SA2 has these capabilities on the target workspace project (and host project if using Shared VPC): * Ability to create and manage custom IAM roles used by Databricks (iam.roles.create/get/update/delete).
  • Ability to get/set IAM policy on service accounts to grant Service Account User on the GCE service account used for clusters.
  • If using a customer‑managed VPC, ability to create firewall rules in the VPC project (which may be different from the workspace project).
  • If using customer‑managed keys, permissions to access KMS key policies (cloudkms.cryptoKeys.getIamPolicy).
  • Databricks will automatically enable Compute Engine API and Cloud Storage API on the project at creation time if needed. Confirm your org policy allows this.

Checks and fixes

  • Verify the Compute Engine default service account exists and is active in the target workspace project: bash gcloud iam service-accounts list --project <WORKSPACE_PROJECT_ID> \ --format="value(email)" | grep "compute@developer.gserviceaccount.com" If it’s missing (and the project is older than ~30 days), create a fresh project or pre‑provision a compliant compute SA and coordinate to use it; otherwise Databricks workspace creation will fail.
  • Confirm SA2 has the required IAM on the target project(s) per “Required permissions” above; Owner typically covers the needed actions, but org policies (e.g., Domain Restricted Sharing, constraints on who can be added as members) can block grants even for owners.
  • If your org enforces Domain Restricted Sharing, ensure Databricks’ Google Workspace customer ID is allowed at the org or project level, and that cross‑project identities are permitted under your constraints.
  • From the account console, click the workspace row to look for a more specific error than “Unknown Error.” If present, it often points directly to the missing GCP identity or permission. If it remains opaque, delete and recreate after fixing the compute SA issue; failed workspaces cannot be updated in place.

Bottom line

  • a) “Workspace creation can only be conducted by an SA hosted on the workspace project” → False. Cross‑project SA2 is fine.
  • b) “There are additional roles to enable SA2 from a different project” → True, with the nuance that the most common blocker is the target project missing the Compute Engine default service account (or policies blocking its use), not the SA’s origin. Make sure SA2 has the exact required permissions on the workspace project and that the compute SA exists/enabled.
 
Hope this helps, Louis.