Support connecting to Azure Container Registry (acr) with managed identity (or similar) like Azure AKS.
- Dominant language
- PowerShell
- Stars
- 118
- Forks
- 63
- PR merge metrics
- No merged PRs in 30d
Description
**Title**: Support connecting to Azure Container Registry (acr) with managed identity (or similar) like Azure AKS.
**Description**:
Azure AKS can connect to an ACR instance (using --attach-acr on the CLI) and have access to pull images. Azure Local / Arc AKS does not have a similar functionality. The best we can do is use a [service principal](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal). Doing that is somewhat unfortunate as we now have to manage yet another object in Azure. Ideally there would be some integrated way of connecting the registry.
There's some recent work (https://github.com/Azure/AKS/issues/5375) going on for Azure AKS to support a new Kubernetes feature called [projected service account tokens](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/4412-projected-service-account-tokens-for-kubelet-image-credential-providers). ACR says they already support using them (https://github.com/Azure/acr/issues/828#issuecomment-2981270860). I'm not quite sure how it all ties together, but maybe it's a good starting point since it seems like that's going to be the "preferred" method?
Contributor guide
Research direction
Start with the linked AKS work on projected service account tokens and ACR’s support statement, then compare that approach with Azure Local / Arc AKS. Define the supported managed-identity image-pull flow and acceptance criteria, including how it would replace the service-principal setup described in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, kubernetes
- Domain
- authentication, cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100