I have tried az aks show and az aks list commands but they don't show the names of the attached ACR's.
I ran the command to attach acr using az aks update --attach-acr and it shows thats it attached.
Can I see through the CLI or portal that the acr is in the cluster?
I am afraid you cannot see the attached ACR in the cluster UI portal.
When you attached the ACR to the AKS cluster using az aks update --attach-acr command.
It just assigned the ACR's AcrPull role to the service principal associated to the AKS Cluster. See here for more information.
You can get the service principal which associated to the AKS Cluster by command az aks list
See below screenshot. The AcrPull role was assigned to the service principal associated to the AKS Cluster.
If you want to use Azure CLI to check which ACR is attached to the AKS cluster. You can list all the ACRs. And then loop through the ACRs to check which one has assigned the AcrPull role to the AKS service principal. See below example:
# list all the ACR and get the ACR id
az acr list
az role assignment list --assignee <Aks service principal ID> --scope <ACR ID>
Actually, the parameter --attach-acr in the command just grant the role ACRPull to the service principal of the AKS. There is no difference from before. You only can see the service principal of the AKS. Currently, the CLI command az role assignment list cannot get the ACR directly if you do not know the ACR scope already. But you can get the principal ID first like this:
az aks show --resource-group groupName --name aksName --query identityProfile.kubeletidentity.objectId
And then use the CLI command to get the resource Id of the ACR:
az rest --method get --uri "https://management.azure.com/subscriptions/{subscription_id}/providers/Microsoft.Authorization/roleAssignments?api-version=2015-07-01" --uri-parameters "\$filter=principalId eq 'objectId'" --query "value[0].properties.scope"
If you know the ACR resource Id, I think you know which ACR attached to the AKS clearly.
The az aks check-acr command checks if a certain ACR is available from a specific AKS.
You have to provide both the ACR and AKS as argument, so this is not good for discovery.
You can build a small script around this that queries multiple subscriptions for their registered ACRs (you cannot pass multiple subscription argument to az acr list --subscription, you have to query the Subscriptions one-by-one), build an aggregated table of the ACRs then pass those values in a loop to az aks check-acr.
Related
I have a service principal which is an Owner on the subscription that I am using to create an Azure Kubernetes Service cluster as part of a script. I want my cluster to use:
Kubernetes RBAC --> enable
AKS-managed AAD --> enable
Local accounts --> disabled
I would like the same Service Principal creating the cluster to be able to create k8s roles and role bindings however in order to do this the Service Principal seems to need a cluster-admin role binding.
When creating the cluster there is the option of adding an array of "admin group object ids" which seems to create cluster-admin role bindings for AD Groups. However the SPN cannot be a part of a Group.
Is there anyway around this process?
I tried to reproduce the same in my environment and got the results as below:
To assign Azure Kubernetes Service RBAC Cluster Admin to service principal you can make use of below cli command:
az role assignment create --assignee <appId> --scope <resourceScope> --role Azure Kubernetes Service RBAC Cluster Admin
When I run this command kubernetes roles are added successfully like below
Alternatively, In azure AD create a group add service principal as a member like below:
Now, Add the group in cluster configuration like below
You can use the below the cli command to create the aks cluster using service principal like below:
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--service-principal <appId> \
--client-secret <password>
Reference:
Use a service principal with Azure Kubernetes Services (AKS) - Azure Kubernetes Service | Microsoft Learn
I get an ERROR: The request did not have a subscription or a valid tenant level resource provider. when trying to create a service principal via the azure cli under the scope of an Azure Iot Hub. I'm using the CLI (bash) but python would be sufficient, too.
As shown at end, i have correct credentials & rights to create sp's in this subscription, and i have owner rights to the iot hub in question.
In case i'm missing a better way to accomplish this, here is the context: We need to authenticate a job that automates the registration of new devices immediately after they are flashed, before they are shipped off to be plugged in. This does many things to customize the flashed filesystem (add unique device hostname & local passwords, for instance); and finally it needs to register the device with IotHub.
az iot hub device-identity create --device-id [device id] --hub-name [hub name] --edge-enabled
With my user permissions, i can az login and accomplish all of this - but it needs to run in an automated job with no interactive login. I believe service principal is the way to accomplish this (?).
Thus, attempting to create the principal I run:
# the following pulls a valid(looking) `"/subscriptions/NAME/resourceGroups/THEGROUP/providers/Microsoft.Devices/IotHubs/THEHUB"`
IOTHUB_ID="$(az iot hub show --name TheHubName --query id)
az ad sp create-for-rbac --name http://my-iothub-serviceprincipal --scopes $IOTHUB_ID --role contributor --query password --output tsv
which fails with the following as above (Note: contributor is too broad, will be a custom-role later):
WARNING: Role assignment creation failed.
ERROR: The request did not have a subscription or a valid tenant level resource provider.
as a test to ensure i have the right az login and other local state, the following analogous command for an Azure ACR scope does succeed, with a new service principal visible in the portal.
ACR_ID="$(az iot hub show --name TheAcrName --query id)
az ad sp create-for-rbac --name http://acr-service-principal-foobar --scopes $ACR_ID --role acrpull --query password --output tsv
This was caused by a bug in the azure CLI. az iot hub show is returning an improperly quoted string; az acr show for example does not.
az iot hub show --name your-iothub-name --query id returns a string like the following. both quotes " are in the original
'"/subscriptions/guid/.../IotHubs/your-iothub-name"'
az acr show --name your-acr-name --query id returns the same format string, but without the extra ' quoting.
"/subscriptions/.../registries/your-acr-name"
az iot hub device-identity create cannot deal with the '"..."' (understandable) but unfortunately doesn't fail cleanly, making this a bit difficult to track down as quoting blends in a bit for script output.
A few weeks ago, I was able to use the Azure CLI to create my Container Registry (ACR) and Kubernetes (AKS) cluster. I could push images to my ACR and have AKS pull images successfully - everything worked great. Every now and then, I would have to refresh my login with az acr login --name <acrName>, but not a big deal.
Today, I found that when I go to deploy an updated image to my AKS cluster, I got a status of ImagePullBackOff:
Failed to pull image "MY_ACR.azurecr.io/MY_IMAGE:v1": rpc error: code = Unknown desc = Error response from daemon: Get https://MY_ACR.azurecr.io/v2/MY_IMAGE/manifests/v1: unauthorized: authentication required, visit https://aka.ms/acr/authorization for more information.
I couldn't remember what I needed to do to make this work, so I went through my original steps and created an entirely new resource group, ACR, AKS cluster, and service principal connecting them. I pushed images to my ACR and was able to apply my Kubernetes manifest, and everything worked again.
A couple hours later, when I applied an updated manifest, I again got the same error message. As part of my setup, I created a service principal:
az ad sp create-for-rbac --skip-assignment
az role assignment create --assignee <principal's appId> --scope <my ACR's id> --role Reader
I also used --role acrpull. It seems like the authentication has timed out, and the documentation for Authenticate with an Azure container registry says that individual AD identities will time out after 3 hours, but even after running az acr login --name <acrName>, I'm not able to fix the issue.
What are the required steps to get my AKS cluster to be able to authenticate again to my ACR?
I'll note that I also attached the ACR according to the documentation at Authenticate with Azure Container Registry from Azure Kubernetes Service by running:
az aks update -n cluster_name -g resource_group --attach-acr acr_name
I also tried using the ACR id instead of the name. After a minute or so, the command completed, and even a half hour+ later, I get the same permissions issue.
The easiest way to integrate AKS with ACR is to leverage the --attach-acr option during cluster creation. This will have AKS manage the service principal for your and handle the token refresh's
https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration#create-a-new-aks-cluster-with-acr-integration
I created the Azure Kubernetes Service and Azure Container Registry using Azure Portal. After that I am able to give the Grant AKS access to ACR, for that I used the below script:
Login-AzureRmAccount
Set-AzureRmContext -SubscriptionID 'XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXX'
#Get the id of the service principal configured for AKS
$AKS_RESOURCE_GROUP = "DSEU2-AKSRES-SB-DEV-RGP-01"
$AKS_CLUSTER_NAME = "DSEU2-AKSRES-SB-DEV-AKS-01"
$CLIENT_ID=$(az aks show --resource-group $AKS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query "servicePrincipalProfile.clientId" --output tsv)
# Get the ACR registry resource id
$ACR_NAME = "DSWEAKSRESSBDEVACR01"
$ACR_RESOURCE_GROUP = "DSWE-AKSRES-SB-DEV-RGP-01"
$ACR_ID=$(az acr show --name $ACR_NAME --resource-group $ACR_RESOURCE_GROUP --query "id" --output tsv)
#Create role assignment
az role assignment create --assignee $CLIENT_ID --role Reader --scope $ACR_ID
Whenever I am running the above PowerShell script then I am getting the exception like shown in below figure.
For the above scenario I followed this documentation:Authenticate with Azure Container Registry from Azure Kubernetes Service
For the command az role assignment create, the description for the argument with --assignee:
Represent a user, group, or service principal. supported format:
object id, user sign-in name, or service principal name.
But what you use is the resource Id of Azure Kubernetes cluster. So you get the error.
And the link you posted, the document shows the secret in the yaml file and the secret created with the command kubectl create secret. The secret just be used for pulling the image from the Azure Container Registry.
Update
With the ERROR shows, the resource group could not be found, so you should check your resource group carefully.
And from your script, you use PowerShell command to log in and use CLI to execute. I think the subscription will not be changed for CLI. So you can check if you are in the correct subscription. PowerShell command will not change the Subscription for CLI.
So I suggest the CLI command az account set --subscription.
I'm trying to create aks cluster with command
az aks create --node-vm-size Standard_A2 --resource-group dev --name cluster --node-count 1 --generate-ssh-keys --debug
It successfully creates the AD App for the cluster.
Anyway, it shows the error:
Operation failed with status: 'Bad Request'. Details: Service
principal clientID: not found in Active Directory tenant
.
The clientId is the id of the app in the AD it has created.
I don't have even an idea where does it take the tenant guid.
So does somebody knows how can I solve the issue?
Info about my subscription:
One account, one directory (Default), two subscriptions (trial expired, and bizspark one).
So in my experience I had to specify clientId\clientSecret to the az aks command to be able to créate aks cluster. I dont think that's a permissions issue (because I definitely have permissions to créate new service principal on my subscriptions), but rather a bug.
az aks create --resource-group aks --name aks --location westeurope --service-principal guid --client-secret 'secret'