While adding managed identities to the Keyvault Access Policy is easy
Now there's quite a few VMs that should be given access to the cluster.
It seems possible to select multiple managed identities add once and ascribe the same permissions to them, but I haven't managed to do this yet (ctrl + click, alt + click, selected multiple... all does not work). I cannot find it in the documentation either, however, it clearly states "selected items" below. How can I achieve this?
You cannot assign many managed identities at once. Neither for Portal nor via Azure CLI. You will need to assign one by one unfortunately..
Usually, Azure CLI is more capable of doing more jobs but it accepts only one assignee at a time.
az role assignment create --role
[--assignee]
[--assignee-object-id]
[--assignee-principal-type {Group, ServicePrincipal, User}]
[--condition]
[--condition-version]
[--description]
[--resource-group]
[--scope]
[--subscription]
Optional Parameters
--assignee
Represent a user, group, or service principal. supported format: object id, user sign-in name, or service principal name.
--assignee-object-id
Use this parameter instead of '--assignee' to bypass Graph API invocation in case of insufficient privileges. This parameter only works with object ids for users, groups, service principals, and managed identities. For managed identities use the principal id. For service principals, use the object id and not the app id.
--assignee-principal-type
Use with --assignee-object-id to avoid errors caused by propagation latency in AAD Graph.
accepted values: Group, ServicePrincipal, User
--condition
Condition under which the user can be granted permission.
--condition-version
Version of the condition syntax. If --condition is specified without --condition-version, default to 2.0.
--description
Description of role assignment.
--resource-group -g
Use it only if the role or assignment was added at the level of a resource group.
--scope
Scope at which the role assignment or definition applies to, e.g., /subscriptions/0b1f6471-1bf0-4dda-aec3-111122223333, /subscriptions/0b1f6471-1bf0-4dda-aec3-111122223333/resourceGroups/myGroup, or /subscriptions/0b1f6471-1bf0-4dda-aec3-111122223333/resourceGroups/myGroup/providers/Microsoft.Compute/virtualMachines/myVM.
--subscription
Name or ID of subscription. You can configure the default subscription using az account set -s NAME_OR_ID.
Checkout Assign a managed identity access to a resource using Azure CLI.
Create a user-assigned managed identity and grant it access to the Key Vault. Then assign the user-assigned managed identity to each VM.
This blog might help.
Related
I've just setup a Managed Identity in my AKS cluster to authenticate with an Azure Key Vault resource, using the following guide: https://dev.to/vivekanandrapaka/access-secrets-from-akv-using-managed-identities-for-aks-91p
In the guide, we setup a system-assigned managed identity in the VMSS. We then add the VMSS application to an access policy in keyvault and this works, the pods in my AKS cluster now have access to my KeyVault resource.
My question is, I am planning on using managed identity to setup other connections with AKS. Example AKS -> Blob storage, AKS -> Cognitive Services. In order to do this, would I add the same AKS VMSS application as lets say a 'Contributor' role to each of these other services. Or would I assign the Managed Identity object that gets created as a 'Contributor' role to each of these other services? Essentially I'm asking, why am I assigning this VMSS as a role instead of the actual Managed Identity object?
Any clarification would be super helpful - thanks,
When you are creating a AKS Cluster ,it creates a kubelet_identity by default evenif you have not specified anything. Kubelet identity is a User-Assigned Identity. If you go to the VMSS >> Identity , You will see two tabs System-Assigned and User-Assigned , the System-Assigned is by default No but in User defined you will find the aks-agentpool assigned to it . So , Even if you don't assign System-Identity , You can assign contributor roles to the Agentpool managed identity.
Example:
I created a AKS Cluster using the Command az aks create -g ansumantest -n MyAKSansuman --location uksouth --generate-ssh-keys.
If I go to MC_ resource group which is the node resource group , I see the Managed Identity present there:
In Identity Blade of VMSS , you can see as below the System-assigned Identity is not present but User-assigned Identity is present:
Now if I want to add a access policy for the AKS in Keyvault then I can refer to the Managed-Identity:
Generally using the above only you can assign Access Policy for key vault or any RBAC Role required by AKS to access other Azure services. As that is being used by AKS by default.
When you do that assignment of your VMSS, under the covers it is assigning the role to the system assigned managed identity. The "MyAKS agentpool" is a different managed identity from the one you created.
We are dealing with multiple identity concepts, and unfortunately all of them are not super clear. (you can read through a few articles that shed some light: https://learn.microsoft.com/en-us/azure/aks/concepts-identity, https://learn.microsoft.com/en-us/azure/aks/use-managed-identity)
Let's walk through a few basics, so the answer makes more sense:
#1: when you created your AKS cluster, a system-assigned managed identity was created for you. The cluster uses this to authenticate and do actions it needs to do (such as manage VMs)
#2: when AKS created the VMSS, it created a "user-assigned managed identity" which shows up in the "MyAKS-agentpool" in your portal. This is the identity that is deployed on the VMSS for the kubelet to authenticate in the context of that VMSS. Depending on what you are trying to do, you could potentially use it for your purpose, instead of creating a system-assigned managed identity.
#3: when you used a "system-assigned managed identity" on your VMSS, it caused a system-assigned managed identity to be deployed on all those VMs. The notion of a system-assigned managed identity is that it is part of the original azure resource itself: it does not show up as another entity. So when you are giving a role to something, you are picking the VMSS (even though under the covers the access gets granted to the system-assigned managed identity). You will not find this as a separate "managed identity" in the portals.
So hope that answers why you had to grant the role to the VMSS and not the managed identity you see in the portal.
Having said all of this: I generally think it's a bad idea to do this kind of assignment: since the system assigned identity is available to every pod running on the node irrespective of the namespace. And you probably need a better finer granularity than that, in which case a better route is to use the https://learn.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity
I think the steps in the post is wrong, the user-assigned MSI was created by default when you created the cluster, you then use this MSI to authenticate to other services.
I want to give an Azure Managed Identity access to the Graph with Directory.Read.All. I was able to get it to work by following this blog: https://blog.bredvid.no/accessing-apis-using-azure-managed-service-identity-ff7802b887d?gi=f2307752395a, however:
that throws an Authorization_RequestDenied error (though apparently expected: MSI Permissions for Graph API)
I would prefer to get this working under az-cli
I tried...
graphId=$(az ad sp list --filter "appId eq '00000003-0000-0000-c000-000000000000'" --query "[0].objectId")
roleId=$(az ad sp list --filter "appId eq '00000003-0000-0000-c000-000000000000'" --query "[0].appRoles[?value=='Directory.Read.All' && contains(allowedMemberTypes, 'Application')] | [0].id")
az role assignment create --role $roleId --assignee-object-id fa22d971-c442-41f2-add1-77e636f80d31 --scope $graphId --assignee-principal-type MSI
But this results in... "The request did not have a subscription or a valid tenant level resource provider."
I am thinking this means I don't have the scope right. Is it possible to do this assignment under az-cli?
It is not possible to assign a service principal(MSI) to an application role currently, all commands here.
The az role assignment create is to add the user/service principal/group to the azure resource as an RBAC role, not that you want, it equals the steps in this link.
Besides, if you want to use the azure CLI instead of powershell because of the cross-platform issue. You could try the powershell core, it is cross-platform, refer to this link to install AzureAD.Standard.Preview module in it, then you will be able to use the AzureAD commands.
I have two VMSS with same name in different resource group , and i see both of them have managed identities enabled and both are givn access to keyvault i want to remove access to one of the VMSS from keyvault i am not able to differentiate which one belongs to whom, below is screenshot-
when i click on any one of them it just shows below screenshot
how can i get the object id to identify exact vmss?
You can make use of Powershell to remove the specific identity
Remove-AzureRmKeyVaultAccessPolicy -VaultName '<your keyvault name>' -ObjectID <id for managed identity linked to requrired VMSS>
Portal doesn't really provide a way to distinguish as far as I could see. It only shows DirectoryID but from your screenshot it's evident that DirectoryID is probably same for both identities.
To find the unique ObjectID linked to each of your VM Scale Sets, go to Azure Portal > desired virtual machine scale set > Identity.
problem statement
currently, I am in the process to create/modify azure resources in the different subscription with the help of azure terraform.
error
Principal <appid> does not exist in the directory {destination-tenant-id-for which contribution role required}
consider the following scenario.
we want to create Azure AKS cluster in one subscription and in same execution, we want to update DNS define in another subscription. this process works well if we are having both i.e. DNS zone and aks cluster in the same subscription but it will not work if these two resources in the different subscription.
steps taken
create service principal without assignment
az ad sp create-for-rbac -n sp-terraform-001 --skip-assignment
assign contributor role for current sp for current subscription
az role assignment create --assignee <appid> --role Contributor --scope /subscriptions/<sub-id>
*assign contributor role to current sp for a different subscription. it will fail with *
az role assignment create --assignee <appid> --role Contributor --scope /subscriptions/<diff-sub-id>/<resource-group>....
please let me know correct steps to access resources in another subscriptions
You can assign rights to a service principal to multiple subscriptions, that is not an issue, as the SP sits outside of the subscription, it is in Azure AD.
However, you cannot assign rights to resources in a different Azure AD tenant to the one the service principal sits in, which it sounds like you are trying to do here.
I am assigned an owner role in my Employer's Azure subscription. He was able to create resource groups, but I can't. We're both wondering why since I was already assigned as Owner, the highest role aside from subscription level.
When I try the az group create --name myGroup -l southeastasia command, its response is
The client 'live.com#<myAccount>#outlook.com' with object id '<object ID>'
does not have authorization to perform action 'Microsoft.Resources/subscriptions/
resourcegroups/write' over scope '/subscriptions/<subscription>/resourcegroups/<myGroup>'.
Edit: I have no subscription level resources
Do you have multiple subscriptions in your tenant? If yes, you should set it.
##list subscription
az account list --output table
##change the active subscription
az account set --subscription "My Demos"
If you only have a subscription, I suggest you could create a sp, then use the sp to create a new resource group. See this link.
Update:
You should give Owner role on subscription level, according to your screenshot, you give Owner role on resource group role, you only create resources in the resource group. You also could not create new resource group. You should give Owner role to your subscription,like below:
Note: This issue is more likely to happen in newer subscriptions and usually happens if a certain resource type has never been created before in that subscription.
Subscription admins often fix this issue by granting resource group owners contributor rights on the subscription level which contradicts with their strategy of isolating access down to the level of resource group level not the subscription level.
For root cause and quick resolution, refer "Common problem when using Azure resource groups & RBAC".
Well, the error clearly says you dont have rights over the scope, so you are either owner of the wrong sub or you have a role that specifically restricts that.