GitHub Actions OIDC with Databricks: wildcard subject for pull_request workflows

[Valerio]

Hi,
I’m configuring GitHub Actions OIDC authentication with Databricks following the official documentation:
https://docs.databricks.com/aws/en/dev-tools/auth/provider-github

When running a GitHub Actions workflow triggered by pull_request, authentication fails unless the Databricks federation policy subject is configured to exactly match the full sub claim issued by GitHub.

For example, configuring the policy with the full subject string from the token allows authentication to succeed. However, this is not practical, as the subject includes PR-specific and workflow-specific components (such as job_workflow_ref and @refs/pull/<id>/merge), which change across pull requests and workflows.

I would like to configure the federation policy using a wildcard subject that supports multiple pull requests and workflows for the same repository and environment.

What is the recommended way to define the subject pattern in the Databricks federation policy to support this use case?

Thanks!

[bianca_unifeye]

There isn’t a Databricks-side wildcard subject pattern to solve this. 

Databricks service principal federation policies don’t support wildcard / glob / regex matching on subject today, the policy’s oidc_policy.subject is effectively an exact match against whatever claim you configure as the “subject claim” (default: sub). The Databricks docs describe subject as the unique identifier for the workload, and only mention switching subject_claim away from sub if sub is not stable. https://docs.databricks.com/aws/en/dev-tools/auth/oauth-federation-policy

So the “recommended” way to make this work across many PRs/workflows is not a wildcard in Databricks, but making the GitHub-issued subject stable.

The recommended solution is to make the GitHub sub stable, use GitHub Environments so sub is repo:<org>/<repo>:environment:<env> even for PR workflows.

If your org has customized sub to include job_workflow_ref/PR refs, update that GitHub customization to a stable template.

Otherwise, fall back to subject_claim = a stable claim like repository, understanding the security implications