Azure GitHub Action Federated Identity Login Issue with Release Tag Pattern Matching

Question

Azure GitHub Action Federated Identity Login Issue with Release Tag Pattern Matching

Nekhilesh Bansod 25

I am deploying a container app in Azure using GitHub Actions. I encountered an issue with the federated identity when trying to login with Azure CLI through OIDC.

The error from the GitHub Action log is as follows:

AADSTS700213: No matching federated identity record found for presented assertion subject 'repo:yeshpal-test17/container-app-bot:ref:refs/tags/alpha-v1'. Please note that the matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience and Issuer against the presented assertion.

It seems the issue is related to the subject identifier in the federated credentials. I tried using a wildcard pattern in the subject identifier, such as: repo:yeshpal-test17/container-app-bot:ref:refs/tags/alpha-v* and repo:yeshpal-test17/container-app-bot:ref:refs/tags/*

However, both attempts returned the same error. The only time the action succeeds is when I specify the exact tag in the subject identifier like this: repo:yeshpal-test17/container-app-bot:ref:refs/tags/alpha-v2

Is there a way to configure the subject identifier to allow wildcard pattern matching for different tags in a single federated identity credential? Or is there a recommended approach to handle this scenario in Azure and GitHub Actions?

Thanks in advance!

Nekhilesh Bansod 25 Reputation points

2024-09-19T16:45:36.6966667+00:00
Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Nekhilesh Bansod 25 Reputation points

2024-09-19T16:46:13.91+00:00
Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Nekhilesh Bansod 25 Reputation points

2024-09-19T16:47:14.1566667+00:00
Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!

Answer accepted by question author

1 additional answer

Your answer

Nekhilesh Bansod 25 Reputation points

2024-09-19T16:45:36.6966667+00:00

Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Nekhilesh Bansod 25 Reputation points

2024-09-19T16:46:13.91+00:00

Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Nekhilesh Bansod 25 Reputation points

2024-09-19T16:47:14.1566667+00:00

Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!

Answer 1

Mario Schützle 4,181

Hello, unfortunately it is not possible by design to use wildcards in the subject string.

Currently it is only possible to choose from the following options:

Environment scope: repo:< Organization/Repository >:environment:< Name >

OR

Branch Scope: repo:< Organization/Repository >:ref:< ref path>

The answer is probably not satisfactory but answers it anyway.

If the reply was helpful, please don’t forget to upvote or accept it as an answer, thank you!

Nekhilesh Bansod 25 Reputation points

2024-09-19T16:44:09.82+00:00
Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Nekhilesh Bansod 25 Reputation points

2024-09-19T16:44:39.4366667+00:00
Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Nekhilesh Bansod 25 Reputation points

2024-09-19T16:45:18.89+00:00
Thank you for your previous reply, I understand that wildcards are not supported in the subject string for federated credentials by design.

Given that limitation, I want to ask if there's an alternative approach to achieve the following use case:

Use Case: My goal is to trigger a GitHub Actions workflow when a new release tag is created (e.g., alpha-v1, alpha-v2, etc.). I want to:

Use the release tag as an environment variable in my workflow.

Deploy the app to an Azure Container App using this workflow.

Ensure the team member who initiated the tag or feature knows that the app deployment has started and can test the feature immediately after deployment.

Is there any recommended way to handle this in GitHub Actions or Azure to make the tag available as an environment variable in the workflow and track which version (tag) has been deployed for testing purposes? I’m looking for a way to streamline this process for a development team that’s testing different features.

Any suggestions or guidance would be greatly appreciated!
Lorentz Vedeler 0 Reputation points

2025-05-30T10:56:35.53+00:00

This severely limits the use of federated credentials. In fact I struggle to imagine a use case where you would only want to grant access to a single tag.

Answer 2

Anonymous

https://docs.azure.cn/en-us/entra/workload-id/workload-identities-flexible-federated-identity-credentials?tabs=github
Flexible federated identity credentials (preview) was announced in 03/12/2025 may be able to help with this by making a Federated credential scenario: Other with A Claims matching expression of

claims['sub'] matches '^repo:prosperops/azure:ref:refs/heads/gh-readonly-queue/main/.*'

P.S. It's a preview ;)

jgrenon45 0 Reputation points

2026-01-05T20:15:10.71+00:00

The Flexible federated identity credentials worked for my case! I wanted to make it work for every future tag in my repository, and using "claims['sub'] matches 'repo:<organization>/<repo_name>:ref:refs/tags/*'" ( * act as a wild-card ) worked.

Share via

Azure GitHub Action Federated Identity Login Issue with Release Tag Pattern Matching

1 additional answer

Your answer