Feature: Manage Azure AD resources (f.e. Applications)

[mwieczorek]

This is more a general question:
Is there a plan (or would it be at least considered) to manage Azure AD resources (f.e. Applications) with azure-service-operator?

more context for my question:
As part of exposing services with Gloo Edge, we can enable 'OAuth extension': https://docs.solo.io/gloo-edge/latest/guides/security/auth/extauth/oauth/
To configure that we need Azure AD Application, with its clientId/clientSecret.
For now, it's possible to create AAD App 'outside' of K8s and pass credentials (as k8s secret).

If azure-service-operator provided a way to provision those resources (Application, credentials), it would be easier to automate such deployment scenario.

[theunrepentantgeek]

We already have a support for a small number of non-ARM resources (e.g. User for MySQL), so I think it's within scope to consider more.

It would be useful to know which specific AAD objects (in addition to Application) that you'd be interested in seeing ASO support.

[mwieczorek]

Thanks @theunrepentantgeek for the reply.
That's awesome news.
For my use case, I'd need Application and ApplicationCredentials resources. Should I create separate issues for both where we can continue the discussion?

[mwieczorek]

Going into more details for my use-case:

I was thinking about separate resources for Application and ApplicationCredentials - I won't need multiple creds objects per app, but to not restrict it for others I proposed separate CRDs.

For Application I'd like to be able to set basic properties (f.e. redirectUri, type of tokens it should support, signInAudience, resourceAccess - f.e. to provide standard MS Graph permissions required in oidc flow)

For ApplicationCredentials CRD, I'd need support only for 'secrets' (but of course, I assume certificates and federatedCredentials type of Credentials could also be supported in the future). for generated credentials, I'd like to be able to specify k8s secret details (like name, type - required in my use-case, where I need type: extauth.solo.io/oauth) where the clientSecret from AAD App will be stored

I'd like to have auto-rotation of those secrets in AAD with an update of k8s secret.

I'd like to also be able to store clientId for generated credentials in k8s secret.

Of course, I can gather those details and propose a schema in separate issues. Also, I'm happy to contribute if we agree on it.

[theunrepentantgeek]

I think we can keep the discussion here for the moment. I'll ensure we discuss this topic at our next weekly sync meeting.

[mwieczorek]

@theunrepentantgeek - can you share "weekly sync meeting" discussion outcomes?

[theunrepentantgeek]

Apologies, I should have updated back here after that meeting.

My colleagues agreed that these additional resources would be worth adding to ASO and that my initial triaging of it into the beta.4 milestone was appropriate. (We're currently working on the beta.3 release.)

One of our goals for ASO is to make it easier to deploy things when there are multiple moving parts, so this is in alignment.

The design document in #2489 (written by @matthchr) goes into some of the work we're doing in this space.

(FWIW, there's nothing super secret or particularly interesting about our weekly sync. We look at our project board to discuss both recently-completed and in-progress work, triage new issues, and review old ones.)

[mrmartan]

FYI there is https://azure.github.io/azure-workload-identity/docs/introduction.html which is capable to provision access tokens via kubernetes ServiceAccounts. It requires an existing AAD app registration. So it seems to me that by combining that with ASO, ASO only needs the capability to create app registrations, etc. that would be then consumed by Azure Workload Identity.

[mwieczorek]

Thanks @mrmartan
In my use case, I need also App Registration secrets as those are required in configuring external services for OIDC flows.

@theunrepentantgeek - thanks for the update. I understand that bringing AAD resources to ASO needs preparation/design that's easier to do within your team. But if I can help and contribute anyhow - let me know.
Do you have any rough timeline for beta.4 milestone? (of course I fully understand if you don't want to provide any dates, in my case I'll probably create a simple controller tailored just for my use case and then 'migrate' to ASO when it's ready)

[theunrepentantgeek]

We don't have any firm dates, not even internal ones.

Our intention is to have a release out every couple of months, but we expect beta.3 to be delayed as we're merging a complex change related to Swagger.

Also, the beta.4 milestone currently has way too much in it, so we're going to have to triage. That said, improving our support for AAD in particular has come up multiple times, so I'd expect that to be nearer the head of the list.

[matthchr]

Need for AAD RoleAssignments has come up recently as well.

Terraform supports this: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/directory_role

There's a Go SDK to do this in the msgraph-sdk-go

[abebars]

@theunrepentantgeek I just saw that Beta4 was out, but I can't find the new resource for the application there. Any update on the timeline?

[theunrepentantgeek]

We've triaged this into our schedule for v2.1.0 which will be following our upcoming v2.0.0 GA release.

[danielkimuipath]

Hi, is there any update on this? Also, is this feature going to handle the Graph permission assignment as well? We'd like to grant graph permission to enterprise applications using ASO, but I am not sure if there will be a feature that supports the scenario. thanks!

[matthchr]

I just had another customer ask me about this, it seems like a common ask we should be resourcing. Pulling it into 2.9.0 to force a discussion about if/how we can do this.

[matthchr]

re-added needs triage, let's discuss where we can fit this in or at least what a design might be.

[matthchr]

We'll need to decide what resources we want to support. Terraform has a good list here: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/application

Do we do groups? Do we just do applications? What types of applications do we support - for example the most interesting is probably something like SNI, but that also may be the most complicated to set up.

[old-guy-coder]

This is getting quite an urgent requirement for us, we are constantly hitting the 2000 Role Assignment per subscription limit and this would help us to mitigate that in a big way by allowing use to assign managed identities to groups that have the role assignment (f.e. we could reduce 28+ role assignments in one environment down to 1 role assignment). We are already going through an creating custom roles to reduce the assignments but this is leaving us with custom roles that have broader permissions and goes against the principals of least privilege.

Any chances that this could get bumped to an earlier milestone since already labelled as high-priority?

[theunrepentantgeek]

Currently tagged for v2.12 (February 2025), we should try to make a priority of this.

[matthchr]

Cataloging the set of resources that have been requested, from what I can tell:

• Application - like https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/application
• Application credentials
• Service-principal - like https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal
• Role assignment, which is already implemented
• Groups

This isn't going to happen for 2.12, as much of the development time for that release has passed while we were away due to holidays/vacations/etc.

We're moving this to 2.13 but acknowledging that there is a lot of interest in this, and we're committing to get at least some of the above resources in for that release. The more the better, but if we can blaze the trail to do at least some (maybe Groups first?) it puts us in a much better position to get them all done.