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.
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.
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.
Problem
I have an azure pipeline YAML file. It is able to run through a service connection which accesses a service principal with all the proper authority, etc.
But I am now trying to clean up the code; we have multiple service principals running on multiple subscriptions and resource groups. They need to create storage accounts, which need to be unique.
So I am trying to create a storage account built partially from the associated subscription and resource group of the service principal creating the storage account.
Example Solution
For the subscription, it is fairly easy. I can do something like this, from within a PowerShell script called inside the pipeline:
$subscriptionId = $(az account show --query 'id' -o tsv)
Write-Output "##vso[task.setvariable variable=AZURE_SUBSCRIPTION_ID;isoutput=true;issecret=true]$subscriptionId"
Now I have the variables $subscription ID and AZURE_SUBSCRIPTION_ID set, and can access subscription information within the pipeline itself.
Question
But how can I do something similar with resource groups?
There is no equivalent to az account show with resource groups, without knowing the resource group name itself. (Eg, I have to type az group show -name <RG-name>, but it is precisely the name that I am trying to get.)
Again, to be clear, I am running inside of a particular resource group and subscription, it is those that are associated with the service connection. Now I simply want that information available to the pipeline.
I'm not sure if I completely understand what you are trying to accomplish. But I suspect that the options below might help.
Get role assignments
If you created separate service connections for each individual resource group you can simply check the role assignments for the SPN and determine the scope of the service connection.
If you, for example, use the Azure PowerShell task, you have configured it with a Service Connection. So when the task starts, it has the context of the service principal. You can then do Get-AzRoleAssignment which should output the Resource Groups to which its authorised. Again, this is only useful if you use a service connection per RG, as you otherwise get results for multiple RGs. (Or for subscriptions and Management groups, if you also assigned a role to those scropes)
Use the Azure DevOps API
You can use the Get Service Endpoint request of the Azure DevOps API to get the service connections. The JSON output will contain information regarding the scope of the service connection.
If you find working with the API directly a bit hard, you can try the PSDevOps PowerShell module to interact with the Azure DevOps API. It has the Get-ADOServiceEndpoint command that allows you to get the available service endpoints.
I have stored Azure VM username and password in Azure Key vaults. I am able to use VM username and password only within a Resource group but I want to use same Azure VM username and password other resource groups or Subscription level. I tried to to give role assignment and permissions but unable to use. Can you please help me on that.
In your screenshot, your keyvault named user2, but in your error above, it is user3, I suppose you used the wrong name, when reference the keyvault resource id in the template, you need to make sure your keyvault name is correct.
I would like to add an Azure app as member of the Azure Group. I am owner of the Group but when I click on Add-->Member , it only lists individual users and there is no option for adding an app:-
I am not trying to provide access to the SG so it can access the app (for that I will have to go to the specific app page) rather I am trying to make the app as the 'member' of an Azure group that I already own. But I just don't see an option for doing that.
If your group is an Office group, it does not support to add the service principal as a member(i.e. the MSI of your datafactory, which is essentially a service principal created by azure automatically in general, see this link).
If you want to add the service principal to the group, you need to use the Security group, see this link.
If your User type is member, but you are not able to create the Security group, the UsersPermissionToCreateGroupsEnabled setting should be set with false in your Azure AD tenant.
See To restrict the default permissions for member users:
For more details, refer to this link.
You need to run this command first from powershell to create the managed identity
Set-AzDataFactoryV2 -ResourceGroupName <resourceGroupName> -Name <dataFactoryName> -Location <region>
https://learn.microsoft.com/en-us/azure/data-factory/data-factory-service-identity