[ISSUE] Account-level OAuth from Databricks CLI is broken: account level bearer token is not picked up for a workspace within the account

[nfx]

Account-level OAuth from Databricks CLI is broken: account level bearer token is not picked up for a workspace within the account, even though account-level bearer tokens are working for all the workspaces within it.

Steps to reproduce:

1. databricks auth login --host https://accounts.cloud.databricks.com --account-id XXXX as account admin.
2. Create a workspace within the account and assign it to $NEW_WORKSPACE. Any existing workspaces within the account would work as well.
3. databricks auth token --host $NEW_WORKSPACE
4. See cannot configure default credentials. Config: host=$NEW_WORKSPACE

See the effect: https://github.com/databricks/terraform-provider-databricks/issues/2610

[bradleyjamrozik]

I am experiencing this issue as well.

Command:

az login --service-principal --tenant $(tenantid) -u $(databricksdevopsdeployment-clientid) -p $(databricksdevopsdeployment-clientsecret)
databricks bundle deploy

Response:

[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "***",
    "id": "<id>",
    "isDefault": true,
    "managedByTenants": [
      {
        "tenantId": "<tanant>"
      }
    ],
    "name": "<subname>",
    "state": "Enabled",
    "tenantId": "***",
    "user": {
      "name": "***",
      "type": "servicePrincipal"
    }
  }
]
Starting upload of bundle files
Uploaded bundle files at /Users/***/.bundle/oz_databricks/development/files!

Starting resource deployment
Error: terraform apply: exit status 1

Error: cannot create job: default auth: cannot configure default credentials. Config: host=<databrickshost>. Env: DATABRICKS_HOST

  with databricks_job.general_ledger_balances,
  on bundle.tf.json line 227, in resource.databricks_job.general_ledger_balances:
 227:       }

[bryanmcq-db]

It seems there is a need for the CLI to be able to map from workspace to account, so it knows when it can use account credentials.

For the specific example you mentioned, the CLI should know that the workspace is associated with the account, as the user just used the CLI to create the workspace in the context of the account.

More generally, the model I would expect as a user is: I tell the CLI how to authenticate to Databricks, and all API calls I make use that authentication mechanism. So if I tell the CLI to authenticate using account level OAuth, and then I start interacting with workspaces in the context of the same authenticated CLI session, I expect the CLI to just do what I told it and use those account OAuth credentials. If I try to access a workspace that isn't in that account, I expect the CLI to fail, and I need to sign in to that other account or workspace first. I dont think we should try to guess / infer which credentials should be used for different API calls as if we guess wrong and use credentials that happen to work but that the user did not intend us to use, this could lead to surprising results for the user.