azure-service-operator
azure-service-operator copied to clipboard
Feature: Manage Azure AD resources (f.e. Applications)
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.
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.
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?
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.
I think we can keep the discussion here for the moment. I'll ensure we discuss this topic at our next weekly sync meeting.
@theunrepentantgeek - can you share "weekly sync meeting" discussion outcomes?
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.)
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.
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)
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.
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
@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?
We've triaged this into our schedule for v2.1.0 which will be following our upcoming v2.0.0 GA release.
There's also been an ask for AAD Groups here #3670
Hi, from my perspective I would need to have :
-
application
- like https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/application -
service-principal
- like https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal -
role assigmnent
, which is already implemented
We would like to have access in-cluster for credentials generated to use them in pods via env variables (or any other mechanism)
@matthchr is there timeline for this ? I see its getting moved
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!
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.
re-added needs triage, let's discuss where we can fit this in or at least what a design might be.