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.
Related
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.
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.
How to enable "system assigned" identity and also update the key vault to add new access policy using azure cli...
Tried below command but it complaints that it cannot find RG for some reason or i'm missing something.
az webapp identity assign --name --resource-group
Tried below command but it complaints that it cannot find RG for some reason or i'm missing something.
The command you used is correct, make sure you input the resource group name correctly, also make sure you run the command under a correct subscription via az account show, if not, use az account set to set it.
az account set --subscription '<subscription-id>'
az webapp identity assign --name '<webapp-name>' --resource-group '<group-name>'
Then if you want to add the system-assigned identity to the access policies of the keyvault, use az keyvault set-policy. (wait for several minutes after az webapp identity assign, the service principal related to the identity need to be created in Azure AD)
Sample(the <object-id> is the principalId returned by az webapp identity assign):
az keyvault set-policy --name '<keyvault-name>' --resource-group '<group-name>' --object-id '<object-id>' --secret-permissions get list delete
I'm on the basic account type on Azure.
I have: A private registry with only one Access Key (Admin one)
I want: To be able to create more access keys with read only (acrpull) access.
Question: Am I reading correct from here: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-skus#sku-feature-matrix that this is not allowed (only in the premium account)?
Isn't there a way to create another token with acrpull access only on a basic account?
Regards,
Of course, you can. It uses a service principal to do the authentication. You need to create a service principal assigned with the role acrpull for the ACR.
Here is an example script which uses the CLI command:
#!/bin/bash
# Modify for your environment.
# ACR_NAME: The name of your Azure Container Registry
# SERVICE_PRINCIPAL_NAME: Must be unique within your AD tenant
ACR_NAME=<container-registry-name>
SERVICE_PRINCIPAL_NAME=acr-service-principal
# Obtain the full registry ID for subsequent command args
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv)
# Create the service principal with rights scoped to the registry.
# Default permissions are for docker pull access. Modify the '--role'
# argument value as desired:
# acrpull: pull only
# acrpush: push and pull
# owner: push, pull, and assign roles
SP_PASSWD=$(az ad sp create-for-rbac --name http://$SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query password --output tsv)
SP_APP_ID=$(az ad sp show --id http://$SERVICE_PRINCIPAL_NAME --query appId --output tsv)
# Output the service principal's credentials; use these in your services and
# applications to authenticate to the container registry.
echo "Service principal ID: $SP_APP_ID"
echo "Service principal password: $SP_PASSWD"
You can get more details in Azure Container Registry authentication with service principals, and also you can choose an appropriate role as you need when you take a look at Azure Container Registry roles and permissions.
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'