Federated identity credentials support for wildcards

[nclaeys]

Is your feature request related to a problem? Please describe.
We are porting our product from AWS to Azure and in AWS you can use wildcards in your trust relationships between your serviceaccount and a role (similar to azure ad application in azure) as follows:

  statement {
    actions = [
    "sts:AssumeRoleWithWebIdentity"]
    effect = "Allow"

    condition {
      test     = "StringLike"
      variable = "<oidc_url>"
      values = [
      "system:serviceaccount:environmentprefix-*:saprefix-*"]
    }

    principals {
      identifiers = [<oidc_arn>]
      type = "Federated"
    }
  }

Is this something that you are considering as well? At the moment it is rigid to work with federated identity credentials in Azure:

• 1 ad application can only have 20 federated identity credentials
• you need to create a federated identity credential when deploying an application to a different aks environment.

Describe the solution you'd like
It would be great if the federated identity credential had support for wildcards to for example allow multiple environments or allow creating a dedicated service account for each pod.
An example of a credential could be as follows:
resource "azuread_application_federated_identity_credential" "app" { application_object_id = azuread_application.object_id display_name = "uuid" audiences = ["api://AzureADTokenExchange"] issuer = var.oidc_issuer_url subject = "system:serviceaccount:*:service_account_name-????" }
wildcard support: * for any string or ? for 1 random character

Describe alternatives you've considered
The other path we are thinking of is managing the federated identity credentials using a kubernetes operator. This way we can dynamically create the federated identity credential, when an application is deployed to a new environments.
Issues we see there are:

• We could bump to the limit of only allowing 20 federated identity credentials per ad application.
• Our clients might want to keep control over the federated identity credentials that get created for an azure ad application.
• We notice a delay between the creation of federated identity credential and when it can be used, this might impact the jobs being launched on a new environment.

Additional context

[ekristen]

I really need this. I was going to go down the creating of federated credentials but the limit of 20 is going to kill me. I need my pods to use different service accounts and sometimes these are dynamically created.

Anything you can do to add in support on AAD side to allow wildcards on this would be HUGE! Thanks.

[ekristen]

@aramase I see you added the label aad -- is there a change this gets supported, especially since this has nothing to do with the kubernetes webhook and everything to do with the aad side of things in Azure? Thanks!

[aramase]

Thank you for the feedback. I've shared this issue with the AAD team and will update the issue here once I hear from them.

cc @udayxhegde

[ekristen]

@aramase any update from the AAD team? Thanks.

[udayxhegde]

@ekristen thanks for the feedback! We will consider this support in our future planning cycles. Right now, we are heads down on completing the work needed to allow customers to use this capability in production for both app registration and managed identities.

[ekristen]

@udayxhegde appreciate the information and that you are heads down. I think without supporting wildcards you are going to extremely limit people's ability to use this. Service Accounts are often created in larger quantities per workload even to help with permission restrictions and other needs, not being able to wildcard service accounts is very very limiting.

Has there been any further discussion in supporting this and if so any ETA? Thank you.

[udayxhegde]

Hi @ekristen : thanks for your feedback. In our initial release we will not be able to support wildcards unfortunately. The additional support in the form of wildcards or custom claims is indeed very important: but there's no ETA for that support.

[ekristen]

@udayxhegde alright, that's unfortunately. I'll have to fallback to using secrets or certificates, with the limit of 20 federated identities and no wildcards, while this is the preferred way to auth, it's not usable which is unfortunate. If there's someone I can elevate this to to get higher priority via my company, please let me know. Thanks.

[udayxhegde]

@ekristen : are there no other options to consider here? Since each pod can only use one service account, what is causing you to intentionally use different service accounts or create them dynamically? I am sure there is a good reason why this is being done, just trying to understand it.

[ekristen]

Maybe there is, any chance the limit of 20 federated identities can be increased for an app? Like 250?

We are also using a service principal to target a couple different tenants as well.

We have a lot of automation and various workloads that need specific access to resources within the the cluster, this all happens via automated means.

This ends up meaning that we have 20-100+ (this number will grow) different workloads with service accounts that can access specific resources like dedicated secrets or config maps.

This is why we can't use a single service account.

If the limit of 20 federated identities wasn't there I might be able to make this work.

I started down the path of dynamically editing the federated identities until I ran into the 20 limit.

[udayxhegde]

changing by that order of magnitude is not practical: another alternative is to use multiple service principals, but that is not easy to manage either.

[ekristen]

The wildcard is the best approach and least amount of work for the Azure team by far. I'm unfortunately going to have to use certificates or shared secrets until wildcards are supported which is a huge bummer. Hopefully it won't take long to implement, it's not a very complex mechanism and is going to unlock you and your customers a ton to do more amazing integrations.

[ekristen]

@udayxhegde following up on this, I thought of another user-case/reason this is needed. For teams that are helping to manage or do things in multiple tenants.

Use Case: I'm a company with a product to help people with Azure, our software is deployed and managed on k8s and needs to use a single service principal (or two) to talk to dozens if not hundreds of other tenants.

AZWI would be the best from a security perspective, but since only the service account can change the tenant being targeted, and since wildcards aren't supported and the limit on federated identities is 20 this can't be used, unfortunately that means hard coded certificates or secrets. :(

[ekristen]

@udayxhegde any movement on this feature request?

[smokedlinq]

Just hit this after a few GitHub repos converted. What's the recommended best practice for a GitHub repo? One per repo? Was hoping one per team would be sufficient, especially when the team repos would be given the same permission to Azure and app resources.

[ekristen]

You have to do one federated identity per repo and limited to 20 per app, then you have to create another one. Unfortunately this is a very painful feature to use.

[ekristen]

@udayxhegde is there anyone we can elevate with this on the Azure side and put in direct contact with. To be very honest, this feature is useless at scale. Without wildcard support, it's just easier and better to use hard coded client secrets/certificates which is a shame.

[salaxander]

Hey @ekristen - would you maybe be willing to have a chat with me on this? I'm not on the Azure Identity team, but I am the PM for Workload ID at Microsoft, so I'd really love to be sure I've got your use case well understood and documented to maybe help push this forward.

If you're on Kubernetes Slack you're welcome to ping me there (@ Xander), otherwise xgrzywinski @ microsoft.com

[ekristen]

Hey @ekristen - would you maybe be willing to have a chat with me on this? I'm not on the Azure Identity team, but I am the PM for Workload ID at Microsoft, so I'd really love to be sure I've got your use case well understood and documented to maybe help push this forward.

If you're on Kubernetes Slack you're welcome to ping me there (@xander), otherwise xgrzywinski @ microsoft.com

Absolutely! I'll reach out.

[udayxhegde]

Sorry @ekristen for the late reply... I recognize this capability is important to manage things at scale, but unfortunately, we don't have any updates on this yet.

[kevinharing]

This is holding us back as well. We deploy resources dynamically at request with a pre-existing managed identity. The namespace name is dynamic and is unique for each deployment. The service account is created in this namespace. It is really cumbersome to have to create/delete the federated identity credential for each deployment, and of course there's the limit of 20 credentials. Also, the delay in identity/credential propagation is exactly what we're trying to fix by moving away from AAD Pod Identity. A wildcard for the namespace name would fix this problem, as we would be able to have a pre-existing federated identity credential that can be reused.

[ekristen]

I had a call with a PM a few months back on this. I said match what AWS does, allow wildcards anywhere, or StringLike matching. This is still a HUGE pain point.

[kevinharing]

@salaxander So no plan for implementing this for now? Is there a workaround?

[ekristen]

@kevinharing I had a call with a product person from Microsoft to explain the situation and they seemed responsive. Unfortunately that was 6+ months ago. I unfortunately have taken the position that this will never be addressed.

[salaxander]

@kevinharing @ekristen Sorry for the confusion here folks! I did remove this from our roadmap project board because the limitation is on the AAD side, and so it's not an actionable feature item on our roadmap. I have been told by AAD that they will support wildcards though. I don't know a timeline, but I do know that it they are planning to do it. I'll pin this issue on the repo though for visibility.

[RiddlerKnight]

omg, this issue still here for 2 years.

[iohenkies]

Fix please

[Noahnc]

Stumbled up on this yesterday while evaluating federation for GitHub Actions. Without support for wildcards and a higher limit than 20, this feature is basically useless for us to use with GitHub Actions.

[jikuja]

Stumbled up on this yesterday while evaluating federation for GitHub Actions. Without support for wildcards and a higher limit than 20, this feature is basically useless for us to use with GitHub Actions.

For Github there is a workaround described earlier: #373 (comment)

[Noahnc]

Stumbled up on this yesterday while evaluating federation for GitHub Actions. Without support for wildcards and a higher limit than 20, this feature is basically useless for us to use with GitHub Actions.

For Github there is a workaround described earlier: #373 (comment)

This is not really a solution for us, since we have some principals that can be used by the entire GitHub organization (e.g to pull container images) and other principals only assigned to specific repositories. For the first requirement to work, we would have to modify the subject to only include the GitHub organization, in which case principals with repository scope would not work.

[smokedlinq]

For GitHub, if you are using branches or tags for releases, I think you can circumvent this by using a static environment for your release and including that in the federated credential as it takes priority over the branch ref.

[swapnil-potnis]

Any updates on this?? We really need to have the regex functionality for smoother execution of the multiple use-cases that we have.

[chessser]

I've noticed that the pattern matching for the branch is for only the start of the branch name, which means it can effectively can be used as a wildcard.

I'm using GitLab, which doesn't have the ability to manipulate the sub in the JWT token

For example, on main branch, the sub would be:

project_path:example-project/example-repo:ref_type:branch:ref:main

This will directly match a federated credential set of project_path:example-project/example-repo:ref_type:branch:ref:main and be able to authenticate via OIDC.

If I have the branch: DATA-123, the sub would be:

project_path:example-project/example-repo:ref_type:branch:ref:DATA-123

If I configured in Azure the federated credential of project_path:example-project/example-repo:ref_type:branch:ref:DATA-, it would still be able to authenticate, and the OIDC flow will be successful. Note, I didn't add an astrix or any sort of wildcard, it feels like the pattern matcher on Azure only looks for the start of thee string, and not the complete match for the branch reference.

To me this seems like a bug, and something which is poorly coded in Azure and is a risk that may be changed in future, but it does solve our use-case of a GitFlow type pattern, as long as our branches follow the pattern of 'DATA-'.

In our enterprise company we'll be raising this 'feature' I discovered to understand if it is something they'll be fixing

[daisy-timms-xlab]

This combined with the 20 cred limit is hampering our development too - would appreciate any update on whether this is going to be addressed in the near future.

[perlboy]

👍 on this. This limitation breaks any use of GitLab federated identity because you can't change what the target variable is to verify in Azure (GitLab supplies a plethora of them) and any PR includes the source branch name as the sub. Also @chessser's comment about a prefix string working is no longer the case, it doesn't.

[pdxjohnny]

Ya PR based flows are a huge use case for this

[chessser]

@perlboy could you please describe your set up and what's not working? The prefix string we have implemented is still working (as of 9AM GMT 26/04/2024)

[jikuja]

@perlboy could you please describe your set up and what's not working? The prefix string we have implemented is still working (as of 9AM GMT 26/04/2024)

I tested this two days ago with Gitlab and it did not work.

Could it be that there is undocumented new featured being deployed and that works only on some regions

[jensrotne]

I'd like to add myself to the pool of users wanting this feature. Currently, we're stuck with client secret authentication as CircleCI adds the commit author ID to the sub claim.

[dmunch]

@nickludwig Any news on this or the prefix matching, or even better, wild-card support?

[hotfix-houdini]

Just wanted to say call out @scootafew 's solution specific to github -> azure as it addresses my need exactly:

allow federated auth from any branch in a github action workflow

Perhaps other CI products allow modifying what subject identifiers they attempt to auth with, where each branch can use a constant identifier and thus there is no need for wildcards on azure's side.

[dejoost]

could we please avoid diluting this request. If the workaround was helpfull give it a thumbs up and don't blow up the thread with words of gratitude and by making assumptions. For our company this is still a major showstopper.

[perlboy]

The workaround isn't helpful except for those using the (Microsoft owned) GitHub. Azure seems to be the only implementation of federated OIDC that doesn't support a wildcarding concept. This limitation means that either pipelines are untested prior to merging (i.e. change control risk) or we are required to super-privilege any CI with a static token for any Azure operation (i.e. violation of principle of least privilege). It's hard to believe that the implementation team didn't know this.

[dlemstra]

With the @ImageMagick project we were running into the same issue when using azure/login in a GitHub actions and wanting do this for every tag. So a wildcard for a tag would have helped us. We resolved this by using an environment instead:

  create_release:
    runs-on: windows-latest
    environment: release

    permissions:
      id-token: write
      contents: read

And setting up this environment with a wildcard filter for tags:

And use that GitHub environment inside the configuration of our federated credential:

[jack4it]

two years later, we still don't have a word from AAD team? @udayxhegde this has been a true pain once we started to embrace federated creds

[LucasLundJensen]

Surprised this has not been supported already, especially with the amount of attention this issue has.

[dheerajbsomaraj]

There's no wildcard support for Subject Identifier?, I am surprised.

[remiville]

🤯 #metoo

No kidding, in my case I need too give access for different and dynamic workloads inside one tenant (i.e. k8s namespace), each workload has a different serviceAccount (I think it is a good practice), I would like to have the possibility to create a federated identity with subject like system:serviceaccount:<namespace>:* or system:serviceaccount:<namespace>:<some serviceAccount prefix>*

It is possible on AWS with the StringLike operator.

[georgegil]

Just found the 20 limit.. this is a disaster.

can't believe 2 years since this issue it is still an issue

[pauldotyu]

🤯 #metoo

No kidding, in my case I need too give access for different and dynamic workloads inside one tenant (i.e. k8s namespace), each workload has a different serviceAccount (I think it is a good practice), I would like to have the possibility to create a federated identity with subject like system:serviceaccount:<namespace>:* or system:serviceaccount:<namespace>:<some serviceAccount prefix>*

It is possible on AWS with the StringLike operator.

I'm not sure why there is a hard limit of 20 federated credentials, but I think having multiple ServiceAccounts tied to a single Azure User-Assigned Managed Identity might lead to unnecessary Azure permission sprawl. Since the managed identity itself is granted RBAC permissions, all linked ServiceAccounts would essentially inherit those same permissions, even if they don’t necessarily require them. So I prefer creating additional managed identities to guarantee that ServiceAccounts adhere to the principle of least privilege.

[MYKEU]

Twiddling my thumbs and waiting for an official reply on this much needed feature...

[RobertPaulson90]

When can we get this simple feature? What's wrong with Entra ID since this cannot be fixed?

[joshua-hancox]

Wondering if this repo isn't the best place for this issue due to it not being officially supported.

I found this issue here, MS seem to at least officially reply there once something gets enough upvotes.

https://feedback.azure.com/d365community/idea/2068fe95-45ec-ee11-a73d-0022484c4e0d

Everyone go add your upvotes 😄