Azure Managed ID can be used for the Helm Controller?

[stevendick-work]

It's not immediately clear from the Azure-specific documentation if we can use Azure Managed ID (Pod ID) for running the Helm controller. Is this expected to work?

We already extensively use Managed ID in the cluster and have now been asked to disable user name/password access to the ACR that we currently use with Flux.

[kingdonb]

The Azure docs should be quite specific about what is supported, hope you can find what you're looking for in here:

https://fluxcd.io/flux/use-cases/azure/#aad-pod-identity

Is 'pod id' the same as 'AAD Pod Identity'? I am a lightweight Azure user but also pretty noob in this area, (I don't know much except that the AAD Pod Identity approach is likely preferred by security teams to the Service Principal approach, because the ambient creds can be used rather than embedding a special token that can be exfiltrated, and needs to be rotated.)

I guess the password is equivalent to the service principal approach, but not completely sure.

[stevendick-work]

I've read the Flux docs on Azure and I don't find them clear on whether or not the helm controller supports using Pod Identity to read Helm charts from the ACR.

We are currently using the ACR's admin user for the user name/password and this is the approach we need to stop.

If we cannot get Pod Identity to work, then we can probably fall back to using a service principal. Pod Identity eventually resolves to a service principal, so that should not be an issue.

[stevendick-work]

Looks like I am talking about the wrong Flux controller as looking at the logs, I see it is the Source controller that retrieves the Helm charts.

[kingdonb]

It's a little bit obscure, but this is a core concept in Flux: yes; the source controller handles everything regarding fetching and unpacking sources or verifying of provenance. So the configuration flags would go on the Source Controller.

But as of the last release of Flux (0.40) the flags are not necessary anymore, the configuration goes on the ImageRepository resource.

Here's a current reference (please note if you are on an older version of Flux, then you'll need to upgrade to at least 0.40 to take advantage of this new feature.)

• https://fluxcd.io/flux/components/image/imagerepositories/#provider

[stevendick-work]

Is that relevant? I'm not talking about container images but Helm charts. Azure's container registry handles both, but with different interfaces. I'm assuming in our current setup that Flux itself isn't doing anything with container images: it is Kubernetes that pulls the new container image as the result of a new Flux HelmRelease.

The Image Controller is a mandatory feature as of the 0.40.0 upgrade?

[kingdonb]

The Image Controller is a mandatory feature

No, image update controllers are only required for image update automation. Sorry for the bad link:

https://fluxcd.io/flux/components/source/helmrepositories/#provider

The Helm Repository has its own description of the provider which is also part of the same update. (Functionally, you have to be using a HelmRepository of type: oci so, under the hood it's a lot like ImageRepository, which doesn't really matter here, the point is the docs look very much the same under both of these interfaces, because they are both OCI repositories under the hood.)

This doc warns that you can only use this with OCI helm repositories. (Do you know if this is the only option/enabled by default for your new Azure Helm repos? I sure hope so...)

[stevendick-work]

Migrating to OCI Helm repositories is on our radar but not yet planned. I've tested OCI support in Azure, but we still need to update our promotion service between dev, test and prod ACRs to handle OCI charts.

[kingdonb]

So, does Helm itself have a way to connect to Azure Helm repos that are not OCI through the new AAD Pod Identity? I'm not sure I'm aware of how this works. I'm not an expert on Azure, but if I had to guess why Flux requires you to use the type: oci, if you tell me that you can definitely use the new Identity features with the old style Helm Repository (I'm not sure myself)...

I'd guess that the OCI interface being scalable for the future and Helm Repository with index.yaml being considered legacy, made it an easy choice on which one to support first. I don't really know the history behind the new Azure ID feature, how it was promoted etc but it sounds like they're forcing the migration, and you might want to consider migrating sooner.

The Flux team is small, and adding new features to support legacy Helm repository on a specific cloud provider that's forcing their users through changes, it's frankly likely going to land pretty low on our roadmap priorities. (If someone contributes a patch to plug the feature gap, on the other hand, I think it would be reviewed quickly and merged with priority...)

[stevendick-work]

With the legacy Helm storage format, interaction with the ACR was handled by the AZ CLI. This has been marked as deprecated for several years.

With the OCI format, responsibility has moved to the helm command, using 'helm registry' for login/logout and 'helm push' for publishing.

We would prefer to to decouple the OCI upgrade from making Flux work with managed identity and we can fall back to using a service principal as an acceptable solution for Helm chart interaction.