azure-workload-identity
azure-workload-identity copied to clipboard
Azure
Federated identity credentials support for wildcards
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
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.
@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!
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 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.
@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.
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.
@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.
@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.
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.
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.
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.
@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. :(
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.
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.
@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.
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
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.
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.
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.
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.
@salaxander So no plan for implementing this for now? Is there a workaround?
@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.
@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.
@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.
Thank you for the quick reply!
@kevinharing wildcards is very necessary. For now, we have multi(more than 20) namespaces in aks. Within all of these namespaces, we need to access different Azure Resources. Besides, these namespaces have same prefix naming. However, we hope to only aissgn credential in single 3rd party app. we don't want to create multi 3rd party app, which will be very hard to manage.
A recent feature release in Terraform now allows for the use of OIDC auth with Azure and required a federated credential and this limit of 20 has quickly become an issue. We need the wildcard capability to be prioritized quickly as this is a huge hold up on our deployment of using OIDC with Terraform Cloud. https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/azure-configuration
Where can we elevate our request for AAD supporting wildcards and increasing the maximum credentials in flight per identity? My client wants to use user managed identities rather than application registrations due to access concerns (subscription owner level access is not sufficient to create applications and service principals for role assignment and group membership). The limitations discussed at length above are a blocker for us as well.
A recent feature release in Terraform now allows for the use of OIDC auth with Azure and required a federated credential and this limit of 20 has quickly become an issue. We need the wildcard capability to be prioritized quickly as this is a huge hold up on our deployment of using OIDC with Terraform Cloud. https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/azure-configuration
Facing this exact same issue, the absence of wildcards combined with the limit of 20 federated credentials per app registration makes this feature pretty useless at the minute. Would love an update on expected timeframe?
