I have created a Azure Service Principal like this
az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role reader
after logging in (az login --service-principal -u $SERVICE_PRINCIPAL_NAME -p $SERVICE_PRINCIPAL_ID --tenant $TENANT_ID) I am able to see all the images (az acr repository list --name $ACR_REGISTRY_NAME) which are in my registry, but I can not push or pull images (docker pull myregistry.azurecr.io/myimage:latest).
Are there any permissions I am not aware of? I have tried the similar with other roles like owner or contributor, but also SPs are getting the same error, which is the following:
Error response from daemon: Get https://myregistry.azurecr.io/v2/myimage/latest/manifests/latest: unauthorized: authentication required
Update 14. of August:
I am also not able to docker login with the SP
Error response from daemon: Get myregistry.azurecr.io/v2: unauthorized: authentication required
You need to login to the registry using docker login
docker login myregistry.azurecr.io -u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -p myPassword
Refer to: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication#service-principal
For the Azure Container Registry, there are two ways to log in.
One is that log in with the command az acr login -n azureacrServer -u username -p password, you have the owner permission after logging in.
The other one is that log in with a service principal using the command docker login azureacrServer -u servicePrincipalId -p sppassword. In this way, you just have the permission of the service principal after logging in. I try and the result like the screenshot shows below:
This service principal is just set as a Reader. So we cannot push the image.
You can get the details about the service principal of Azure container registry with the command az role assignment list --scope acrId, the command will show all the service principals of the registry. The command az acr show --resource-group groupName --name acrName --query id --output tsv will show you the registry Id.
Related
I am geeting the error while I try to attach the Azure Container Registry to the AKS using Visual studio
syntax:
az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --attach-acr $ACR_NAME
Error:
microsoft.containerregistry/registries' could not be found in subscription
I have logged into the correct subscription and also set the correct subscription
az login --tenant $TENANT_ID
az account set --subscription $SUBSCRIPTION
az acr list also shows me the acr that is created
any possible solution for this?
Tested in my environment it is working fine for me, The error you are getting is due to you are looking into wrong subscription. When you use the CLI command az login then you log in with a default subscription. For you, it seems the "Some Other susbscription" is the default. You should check if your registry is in the current subscription. If not, you should set that subscription as the current subscription through the CLI command:
az account set --subscription subscription_id
Now would suggest you to check if the registry exists in current subscription with the CLI command:
az acr show -n acr_name
Also, you can set the subscription in the login time with the parameter --subscription through the CLI command az login.
Reference : az acr - Unable to find repository in case of multiple subscription on single account
I have a strange situation where when I use a local powershell script in my visual studio project that logs in using a service principal and then is able to associate a specific subscription.
#login with service principal
az login --service-principal --username $APPLICATION_CLIENT_ID --password $SECRET --tenant $TENANT --allow-no-subscriptions
#set the subscription we want to use
az account set --subscription $SUBSCRIPTION_ID
and i'm able to create resource groups etc, once I've picked the right subscription.
Now I need to do the same thing in a Dockerized environment.
admins:~ admin$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9e507c6639a1 mcr.microsoft.com/dotnet/core/sdk:3.1 "bash" 2 days ago Up 2 days adoring_goodall
I login into the container and I run these commands:
curl -sL https://aka.ms/InstallAzureCLIDeb | bash
apt-get install curl && curl -sL https://deb.nodesource.com/setup_12.x | bash -
apt-get install nodejs
npm install -g azure-functions-core-tools#3 --unsafe-perm true
az login --service-principal -u $APPLICATION_ID -p $SECRET --tenant $TENANT_ID --allow-no-subscriptions
This works just fine. Output I get back from the login is identical to output from my local workstation via powershell.
PS /usr/share/powershell> az login --service-principal --username $AZ_APPLICATION_CLIENT_ID --password $AZ_SECRET --tenant $TENANT --allow-no-subscriptions
{
"cloudName": "AzureCloud",
"id": "<tenantId>",
"isDefault": true,
"name": "N/A(tenant level account)",
"state": "Enabled",
"tenantId": "<tenantID>",
"user": {
"name": "<ApplicationClientID>",
"type": "servicePrincipal"
}
}
But when I try to associate the subscription, I get the following error message:
The subscription of '<subscription ID>' doesn't exist in cloud 'AzureCloud'
I've even gone ahead and install powershell on the docker container just so i can copy paste from my local ps script into the docker env. But I'm getting the same results.
Any tips?
Edit 1
In the docker container, I ran "az login"... and went ahead and authenticated my "device" at https://microsoft.com/devicelogin
Once I did that, all the commands listed above in my question started working the same way in the docker environment as it does on the actual local workstation.
I thought the idea behind creating a service principal was to avoid the "interactive" steps needed to use the az cli. how can i set things up so that when i deploy my azure function app via a script, it can run unattended? I want to be able to use dockerized containers to deploy this app to different azure tenants ..(dev, qa and production)
Going back to the drawing board / reading the docs to see what I missed but any suggestions would be appreciated.
Thanks.
As far as I know, the output of the command az login --service-principal --username $AZ_APPLICATION_CLIENT_ID --password $AZ_SECRET --tenant $TENANT --allow-no-subscriptions also includes the subscription ID like "id": "<subscriptionId>" instead of "id": "<tenantId>" in your output. You can show the default subscription with the command az account show.
I found that there are two variables $APPLICATION_CLIENT_ID and $APPLICATION_ID in your questions. Not sure you have a typo or using the wrong variable there. Please make sure you input the correct subscription id value when you run az account set -s <subscriptionId> and other parameters values via echo the environment variable value.
You can also get a list of subscriptions for the logged-in account with the command az account list and check if the subscription Id does exist in the specific tenant.
At last, you may need to re-auth the CLI with az login. Or, by comparing the Az CLI version with your local workstation, you may need to reinstall or upgrade it.
Edit
You can verify if the service principal indeed belongs to the subscription. Search the display name of App registration in the IAM of subscriptions.
Update:
A colleague who works for Microsoft said:
Changelog entry for this behaviour change is here: https://github.com/MicrosoftDocs/azure-docs-cli/blob/master/docs-ref-conceptual/release-notes-azure-cli.md#aks-3
I'm following the proper instructions and the documentation must be out of date.
https://learn.microsoft.com/en-us/azure/aks/kubernetes-service-principal
Automatically create and use a service principal.
When you create an AKS cluster in the Azure portal or using the az aks create command, Azure can automatically generate a service principal.
In the following Azure CLI example, a service principal is not specified. In this scenario, the Azure CLI creates a service principal for the AKS cluster. To successfully complete the operation, your Azure account must have the proper rights to create a service principal.
az aks create --name myAKSCluster --resource-group myResourceGroup
This is what happened a few months ago - see Finished service principal creation:
Now when I try I get Add role propagation:
The problem is querying the servicePrincipalProfile.clientId results in msi, I need the guid of the service principal not the Managed Service Identity.
$CLIENT_ID=$(az aks show --resource-group $AKS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query "servicePrincipalProfile.clientId" --output tsv)
echo $CLIENT_ID
Used to work:
Now its changed:
How do I create the Kubernetes Cluster with a Service Principal as the documentation states and how it used to work?
Repro steps:
https://github.com/MeaningOfLights/AzureTraining/blob/master/Hands-On-Labs-That-Work/80-Kubernetes.md
https://github.com/MeaningOfLights/AzureTraining/blob/master/Hands-On-Labs-That-Work/85-Kubernetes-Deployment.md
For Reference: I got the same and following your link I found that this worked.
az aks show -g aks -n cluster --query identityProfile.kubeletidentity.clientId -o tsv
and this returned the appropriate guide, that I could use for my RBAC assignment
# get the clientId of the cluster
$clientId = (az aks show -g aks -n cluster --query identityProfile.kubeletidentity.clientId -o tsv)
# get the resourceId of the registry
$acrId=(az acr show -g acr -n myacr --query id -o tsv)
# give authority for cluster id to the acr pull
az role assignment create $clientId --role AcrPull --scope $acrId
I'm new with Kubernetes and Azure. I want to Deply my application and I am floowing the microsoft tutorial about kubernetes. At first I have created the resouce group and ACR instance. When I try to login in ACR console show this error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
I'm using azure cli localy and I have docker running.
You can try below options to connect ACR :
run az acr login first with the --expose-token parameter. This option exposes an access token instead of logging in through the Docker CLI.
az acr login --name <acrName> --expose-token
Output displays the access token, abbreviated here:
{
"accessToken": "eyJhbGciOiJSUzI1NiIs[...]24V7wA",
"loginServer": "myregistry.azurecr.io"
}
For registry authentication, we recommend that you store the token credential in a safe location and follow recommended practices to manage docker login credentials. For example, store the token value in an environment variable:
TOKEN=$(az acr login --name <acrName> --expose-token --output tsv --query accessToken)
Then, run docker login, passing 00000000-0000-0000-0000-000000000000 as the username and using the access token as password:
docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN
you will get the below promt if you follow the above method :
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded
Seems your Docker Desktop is not running. Make sure you installed the Docker for Desktop on your machine and start it if not. You should be good once you start.
Using powershell how do we login to Azure Container registry. The sample provided is only for is only for Azure CLI
az acr login --name <acrName>
Connect-AzContainerRegistry -Name MyContainerRegistry
Microsoft Docs
Available as part of the official Az Powershell module. Note that the older AzureRM module does not include this functionality.
There is no single powershell to login in Azure Container registry, if you want use powershell to login in, we should get the admin credentials for the registry first and run docker login to log in.
You could refer to the command below.
$creds = Get-AzureRmContainerRegistryCredential -Registry $registry
$creds.Password | docker login $registry.LoginServer -u $creds.Username --password-stdin
For more details, refer to this article.