Azure Container Registry User Accounts; Single, Multi, Admin and Service Principals
The Azure Container Registry went into public preview yesterday. We're excited to add this core platform feature for the breadth of container deployments being added to Azure. These include Azure Container Service, Azure Service Fabric, Azure App Service and Azure Batch, ...as of now. More are coming...
When designing the Azure Container Registry, we felt it important to maintain common CLI support, such as using Docker login, push and pull.
Docker login is a basic auth flow, requiring a username and password. What we want to do, and will do, is support your Azure Login credentials so you can manage access to the registry with Azure Active Directory groups. Such as your development team has read/write access, while others outside your org may not have access, or they may have read access. To use active directory identities, we need a token flow, and because many companies require 2 factor auth, it gets even more complex. At this point the docker client doesn't yet support 2 factor auth flows. Rather than wrap the docker api in an Azure specific API, we chose to stay true to the docker CLI. Which means things got a bit more complex and/or limited in the short term.
Shipping a Public Preview - managing time/resources/quality
When we decided to land a public preview for Connect() 2016, we needed to decide which top problems we were going to take on.
- Fully Qualified Image Names - that won't change
We felt the top priority was to design the service such that image fully qualified names won't chnage as we add features or go GA. We went through several designs for how to name the registry URL. We want to provide geo-replication features that mean an image tag of stevelas-microsoft.azurecr.io/helloworld would be available across any region I decide. But, I can decide later, not at the time of creation.
We also want to support several groups autonomy from each other. For intance, warranty-contoso.azurecr.io/web from marketing-contoso.azurecr.io/web from contoso.azurecr.io/aspnetcore for corporate images. - Headless access to the registry for Build/Deploy and Production Systems
When VSTS, Jenkins or other build systems need to push/pull images, they need authentication. This includes your production hosting solution, such as ACS or App Services. While we want to provide token flows with Service Principals over time, the current docker flows use basic auth. - Multi-Region Support
While we will support geo-replicaiton n the future, we first need to support multiple regions. Deploying a core Azure Service and resource provider turns out to be a lot of work. - Azure CLI
An open source CLI for managing the container registry, such asaz acr - Azure Portal Integration
Enabling developers to easily provision in the portal - Reliable Availability
What good is an azure service if it's not reliably available for your build and deploy scenarios.
When we considered these priorities, along wiht our backlog, we realized we couldn't fit the token flows in reliably in time for the public preview at Connect(), so, what to do...?
The Azure Container Registry Admin Account and Service Principals
The docker CLI supports basic auth. You use this for docker hub and other private registries. We felt this was the first important goal.
We also wanted to support more than one account, and we know we need to support headless scenarios. Azure AD and service principals is great for this. You create a service principal and we can use the App Id as the username and the password as the password. You can regenerate the passwords and manage these over time with secured storage of Azure Ad.
At the same time, the AD integration can be tricky. We don't yet have great AD support in the new Azure Portal.
Until we get full AD / Individual Identity and 2 factor token flows working with the Azure Container Registry, we chose to add a special Admin Account.
When you create an ACR instance, you have the option of creating it with the Admin Account enabled/disabled. We debated the default as we want this to go away over time.
When the admin account is enabled, you get a single user, username/password combination you can immediately use to interact with the registry. Simply issue: docker login myregistry-company.azurecr.io -u [admin username] -p [admin password] and your good to go.
However, when you want multiple users to have access to the registry, you really don't want to give out these credentials. This means everyone would use a single account, which doesn't scale as it makes it near impossible to reset the password without breaking someone/something you want to keep running.
Until we get AD Identity complete, you can add service principals. The easiest way is to use the az cli.
az resource group create -l westus -n myregistry-acraz acr create -n myregistry -l westus -g myregisry-acr --admin-enabled true
Once the registry is created, the az acr cli will provide some helpful commands:
Create a new service principal and assign access:
az ad sp create-for-rbac --scopes /subscriptions/[your subscription id]/resourcegroups/myregistry-acr/providers/Microsoft.ContainerRegistry/registries/myregistry --role Owner --password <password>
You can also assign existing service principals to the registry
az role assignment create --scope /subscriptions/[your subscription id]/resourcegroups/myregistry-acr/providers/Microsoft.ContainerRegistry/registries/myregistry --role Owner --assignee <app-id>
You can use other roles of course for:
- Owner: Push, Pull and can assign Push & Pull to other users
- Contributor: Pull and Push access
- Reader: Pull only access
Summing it up:
We're excited to bring you the Azure Container Registry to support your Azure and even On Prem Container workloads. We're working to prioritize the features you need, expect, want and value. ...in that approximate order.
We will be adding AD individual identity with 2 factor auth flows, but wanted to get customers something they can easily use today.
We do not recommend using the admin account for anything other than some basic testing. Please use the service principal flows, even for individual users, until we complete the AD individual identity flow complete.
Steve