Open hadberg opened 7 months ago
Yes, please add this! For companies that enforce a short PAT lifetime, it is very cumbersome to re authenticate each Gitops configuration with a new PAT token every x number of days.
We would like it very much if workload identities were implemented! See: https://fluxcd.io/flux/installation/configuration/workload-identity/#azure-workload-identity.
Right now, our work-around is to use an Azure Blob, and configuring the service principal such that the pipeline has access to it. Then, for the flux configuration we have configured a bucket source. This is not ideal, since an extra step is required to keep the repository and Azure Blob in sync.
Flux 2.4.0 is now available with workload identity functionality built it for the source-controller: https://github.com/fluxcd/flux2/releases
https://github.com/fluxcd/source-controller/blob/v1.4.1/CHANGELOG.md
Would be great if this could be implemented the same way as the image and kustomize controllers.
Since release of flux source controller v1.4.0 in flux bundle v2.4.0 this is possible now.
However, it requires providing spec.provider: 'azure'
in the GitRepository object. This would mean that the ARM api Microsoft.KubernetesConfiguration/fluxConfigurations@2023-05-01
would also need to be updated to accommodate new property.
When we can expect that this will be available in AKS flux extension?
@miqm We still need properties.gitRepository.managedIdentity
(similar to azureBlob
) on Microsoft.KubernetesConfiguration/fluxConfigurations
in order to configure workload identities and DevOps, since we cannot control the Flux bootstrap, right? Or have you found a work around for now?
I hope that workload identity configuration will do the trick as described here: https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/tutorial-use-gitops-flux2?tabs=azure-cli#workload-identity-in-aks-clusters
proper annotation on pod is set:
but still - we'd need to set provider: 'azure'. But the first part is done - bump the version.
Wow that's fast!
Sounds like we need a workaround, potentially patching the GitRepository for this to work until they come up with a native implementation.
I see that v1.13.0 is available in uksouth and westcentralus - anyone with a cluster there? :)
@bavneetsingh16 - could you take a look and provide details if we can set provider: 'azure'
on GitRepository object using flux extension?
We are working on releasing a new API version with the ability to specify the provider field via ARM.
I manually patched GitRepository object by adding provider: azure
and it works beautifully. However, doing a redeployment (I'm using bicep, so every CD run is a redeployment) clears the value. So we need to wait for the RP API update.
@dipti-pai Any update on this?
@miqm What should have been a relatively small change has got caught in a redesign of the swagger/ARM API layer leading to delays. The new ARM API version release might not be available before January, will keep you posted if something changes and we are able to release it sooner.
Is your feature request related to a problem? Please describe. When configuring the Flux integration with Azure DevOps only option out-of-the-box appears to be through personal access tokens.
Describe the solution you'd like We would like to be able to integrate the flux extension with Azure DevOps through a service principal or workload identity. Basically using any authentication mechanism that is not tied to a personal user account.
Describe alternatives you've considered