Azure / AKS

Azure Kubernetes Service
https://azure.github.io/AKS/
1.97k stars 309 forks source link

[Feature] Integrate FluxCD extension in AKS with Azure DevOps without using PATs #4189

Open hadberg opened 7 months ago

hadberg commented 7 months ago

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

  1. Using a PAT which we really would like to avoid
  2. A custom service principal solution with a container continuously requesting a new access token for the service principal and updating the flux pods with the returned token.
Carsondraper commented 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.

bramvanneerven commented 2 months ago

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.

jayctran commented 1 month ago

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 Image

Would be great if this could be implemented the same way as the image and kustomize controllers.

miqm commented 1 month ago

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 commented 1 month ago

That was fast: https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/extensions-release#1130-october-2024

bramvanneerven commented 1 month ago

@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?

miqm commented 1 month ago

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: Image

but still - we'd need to set provider: 'azure'. But the first part is done - bump the version.

jayctran commented 1 month ago

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.

miqm commented 1 month ago

I see that v1.13.0 is available in uksouth and westcentralus - anyone with a cluster there? :)

miqm commented 1 month ago

@bavneetsingh16 - could you take a look and provide details if we can set provider: 'azure' on GitRepository object using flux extension?

dipti-pai commented 1 month ago

We are working on releasing a new API version with the ability to specify the provider field via ARM.

miqm commented 1 month ago

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.

miqm commented 2 weeks ago

@dipti-pai Any update on this?

dipti-pai commented 1 week ago

@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.