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: 

Workload identity federation policy

noorbasha534
Valued Contributor II

Dear all

Can I create a single workload federation policy for all devops pipelines?

Our set-up : we have code version controlled in Github repos. And, we use Azure DevOps pipelines to authenticate with Databricks via a service principal currently and deploy the databricks jobs. We have around 25 Github repos and DevOps pipelines thereby. Can I use a single subject in the below kind of policy?

 

databricks account service-principal-federation-policy create 5581763342009999 --json '{
  "oidc_policy": {
"audiences": [
      "api://AzureADTokenExchange"
],
"subject": "p://my-org/my-project/my-pipeline"
  }
}
1 REPLY 1

szymon_dybczak
Esteemed Contributor III

Hi @noorbasha534 ,

In docs they are giving following example of subject requirements for Azure Devops. So, the subject (sub) claim must uniquely identify the workload. So as long as all of your pipelines resides in the same organization, same project and all of them are using the same service connection then you can have on single policy.

"iss": "https://vstoken.dev.azure.com/<org_id>"
"aud": "api://AzureADTokenExchange"
"sub": "sc://my-org/my-project/my-connection"

 The same applies to github.

{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://github.com/my-github-org",
  "sub": "repo:my-github-org/my-repo:environment:prod"
}

So, you can thing of subject in following way:

"This token was issued for workflows running in the prod environment of my-repo inside my-github-org"

So as long as your pipelines are defined in the same organization -> repo -> env then you can use single policy.

This is quite interesting question and I can try to validate on my own environment, but I think I will find time only at the second part of this week.