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

Nekhilesh Bansod 0

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 0 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 0 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 0 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!

1 answer

Patchfox 3,831 Reputation points

2024-09-19T10:20:10.5133333+00:00
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!
Please sign in to rate this answer.
Nekhilesh Bansod 0 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 0 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 0 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!
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

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

1 answer

Your answer