feat: Refine run_as validation for dashboards to only disallow when…

[iammuntazirali]

Description

Fixes#4394

This PR refines the run_as validation for dashboards. Previously, all dashboards were rejected when the bundle's run_as identity differed from the deployment user. Now, only dashboards with embed_credentials: true are rejected, as those embed the owner's credentials for query execution.

Dashboards with embed_credentials: false (the default) don't embed owner credentials - queries run under the viewer's credentials instead. Therefore, the run_as setting is irrelevant for these dashboards and they should be allowed.

Changes

• Modified validateRunAs() in run_as.go to iterate over dashboards and only reject those with embed_credentials: true
• Updated the error message to be more specific about the embed_credentials requirement
• Added dashboards to the allowList in tests since they're now conditionally allowed
• Added unit tests for both the error case (embed_credentials: true) and success case (embed_credentials: false)
• Added acceptance tests in run_as/dashboard_embed_credentials/ and run_as/dashboard_no_embed/

Why

The previous behavior was overly restrictive. According to the run_as documentation, run_as semantics apply to resources that execute code on behalf of a user. Dashboards with embed_credentials: false don't embed the owner's credentials for query execution - they run queries using the viewer's credentials. This means run_as is irrelevant for such dashboards, and blocking deployment was unnecessarily preventing valid use cases.

Tests

• Added TestRunAsErrorForDashboardsWithEmbedCredentials - verifies dashboards with embed_credentials: true still fail validation
• Added TestRunAsAllowsDashboardsWithoutEmbedCredentials - verifies dashboards with embed_credentials: false pass validation
• Added acceptance tests in acceptance/bundle/run_as/dashboard_embed_credentials/ and acceptance/bundle/run_as/dashboard_no_embed/

Run tests with:

[github-actions]

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

• PR number: 4408
• Commit SHA: a87e364762680a81ce2d04ebf4d46417c09b0a0c

Checks will be approved automatically on success.

[andrewnester]

Thanks for raising the PR! For contributing to Databricks CLI we require users to sign CLA, if that's something you are willing to do, please drop an email with a request to dabs-feedback@databricks.com

[kmarq]

Any hope on this one moving forward?

[txti]

Thanks for raising the PR! For contributing to Databricks CLI we require users to sign CLA, if that's something you are willing to do, please drop an email with a request to dabs-feedback@databricks.com

Is there another committer (with a CLA) that can take this forward? IMHO this is a bug, not a feature.

If it is a "feature" then it stands to reason that there is a "correct" way to set the run_as at the bundle level without affecting dashboards.

Today that is not possible and the only way that might work is to set run_as for each job individually and not for dashboard. That sounds pretty broken to me.

In my case, I can't even do that because in development mode I need to use user_name for run_as and in production I use service_principal_name for run_as.

Now I probably need to create a separate solution and copy configurations everyone which is worse than my old bash scripts.

[github-actions]

This PR has not received an update in a while. If you want to keep this PR open, please leave a comment below or push a new commit and auto-close will be canceled.