[Feature] Automatic authentication from AKS to GHCR

[felfa01]

Is your feature request related to a problem? Please describe.

We run a multi-tenant AKS cluster setup and our container registry of choice has landed on ghcr. We'd like for our tenants to be able to pull images to their workloads without requiring them to handle their own PAT-token life cycles. Essentially, to establish a trust relation between our AKS clusters and our organization's ghcr.

Describe the solution you'd like

AKS should be able to authenticate to Github Enterprise GHCR without having to use imagePullSecret in individual pods. Essentially, the exact same feature as already supported for ACR: https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration.

Describe alternatives you've considered

1. Use Kyverno to mutate workload specs with a reference to a pre-configured, namespaced k8s Secret that contains a general read-only PAT.

2. Configuring the nodes to provide VM-level access to the registry, something along the lines of this. Not sure if this level of configuration is allowed by AKS.

3. Using a kubelet image credential provider, each node has a binary it polls on a schedule based on registry url pattern matching. This appears to be the recommended k8s native approach.

While options 2 and 3 has potential, it does add additional layers of complexity while also being unsupported/undocumented. Option 1 is the most viable in the current setup but requires secret duplication + rotation across all namespaces.

[jack4it]

option 3 seems really legit. it even would solve a pain point on our side that we have multiple AKS clusters living their own aad tenant. for now, we have to replicate images across all the add tenants. would be great to pull from a central ACR without setting up explicit tokens

[illrill]

Agree, AKS should have support for kubelet image credential provider. This is something that EKS is already on top of.

[lgulliver]

👍 from here. We want to be able to use GHCR for our whole Kubernetes fleet, but using individual PATs are a non-starter in an enterprise.

It means instead we need to stand up an ACR per tenant and replicate to them

[aydosman]

With the changes to the AKS service on 30th June, based on this announcement from the AKS releases I would have thought this would be in place prior to the cut-off; it doesn’t seem so.

Here is an extract for reference: In 2020, Docker enacted a Rate Limiting policy for all users. In order to assist customers with the change, Microsoft worked directly with Docker to prevent users of Microsoft Azure from being impacted. However, beginning on June 30th, 2024, Azure customers will begin to be impacted by this limit. In order for customers to mitigate the potential effects of this limit.

Now AKS cluster operators are in a position where they need to make changes or use additional Azure resources to implement something that operating bare-metal k8s offers out of the box.

Could we please get an update on the progress of this feature request?

I would appreciate any help from anyone reading this if it's possible to inject the credentials on an aks node outside the aks service using kubelet config safely?

[ericyew]

Will this ever be looked at?

[ppodevlabs]

how is it possible this feature is not supported? This should be a must instead of forcing clients to add acr caches.