I am writing a program in Java that creates a VM instance in Azure, uploads a script to a container, and downloads and executes the script in the VM. However, I am currently facing a difficulty in granting the machine access to the container. When the machine is already up, I can manually go to Azure and assign a role with access, however I want to do that in my program (when creating the VM) before the machine is up, so that the program can run uninterrupted. Is there a way to do that? From the Documentation
Currently, the Azure portal does not support assigning a user-assigned managed identity during the creation of a VM. Instead, refer to one of the following VM creation Quickstart articles to first create a VM, and then proceed to the next section for details on assigning a user-assigned managed identity to the VM
Am I understanding correctly that it is not possible? Is there a workaround?
It is possible, the doc just means you can't do that in the portal, not mean in the code.
In your case, actually I am not sure you want to use system-assigned identity or user-assigned identity.
Here is a sample which creates a Linux VM with system-assigned identity enabled via withSystemAssignedManagedServiceIdentity, if you want to use user-assigned identity, you could change the code to use WithUserAssignedManagedServiceIdentity, you can specific an existing or not-yet-created user assigned identity, it depends on your requirement.
VirtualMachine virtualMachine = azureResourceManager.virtualMachines()
.define(linuxVMName)
.withRegion(region)
.withNewResourceGroup(rgName)
.withNewPrimaryNetwork("10.0.0.0/28")
.withPrimaryPrivateIPAddressDynamic()
.withNewPrimaryPublicIPAddress(pipName)
.withPopularLinuxImage(KnownLinuxVirtualMachineImage.UBUNTU_SERVER_16_04_LTS)
.withRootUsername(userName)
.withRootPassword(password)
.withSize(VirtualMachineSizeTypes.STANDARD_DS2_V2)
.withOSDiskCaching(CachingTypes.READ_WRITE)
.withSystemAssignedManagedServiceIdentity()
.create();
Related
Input: client_id, subscription_id, resource-group-name, .
Manual / command line steps:
Approving at
https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<client_id>&response_type=code
Creating a new role (az role definition create --output none --role-definition)
Creating a role assignment (az role assignment create).
Steps 2-3 are pretty easy since I could leverage azurerm TF Provider and, more speficially, its azurerm_role_definition and azurerm_role_assignment resources but I'm kinda confused about step #1.
Update: after googling it seems like step #1 is very similar to Enable Azure Active Directory in your App Service app if that helps.
Before you can even get Terraform to interact with Azure/Azure AD resources you need to get Terraform to authenticate to it.
If you're running your Terraform code locally, the process is generally to authenticate using the Azure CLI - az login and then you provide the code shown by the CLI, to the authentication page.
If you want to do this non-interactively, the best practice is you'd need to get the Terraform code run on a machine that either has Managed Identities enabled. Either a System-Assigned or a User-Assigned identity.
Another possible but less direct approach would be to use a Service Principal with a Client Secret for Terraform to authenticate. this is kinda like the link you provided for the App Service.
Try to follow the steps in those two links above as these are from Terraform and have all required steps to ensure you are able to set it up right.
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 have created a asp.net API that accesses KeyVault to get secrets.
When I run locally on my laptop, I use Managed Identity to access KeyVault with a dedicated Service Princiapl. (with AZURE_CLIENT_ID, AZURE_CLIENT_SECRET and AZURE_TENANT_ID set in my system
environment variables).
This is working just fine.
Now I have created a VM in Azure to be used as a developer machine. All the tools are installed and configured like they are on my laptop.
But when I run the web API I get a 403 telling me the object ID #### does not have Get/List access to KeyVault.
I've checked and the object ID matches the one of the VM. Indeed the VM does not have this access to KeyVault, however I'd expect the Web API to run with the configured AZURE_CLIENT_ID in my environment variables.
Am I missing something ?
Ensure get/list operations are selected/enabled in the access policy created for your managed identity/service principal:
I have two subscriptions and a VM in my Azure account. I have assigned two Service Identities to the VM where each MSI is assigned with one subscription. I want my terraform script to use both of them in my providers block. How to proceed with this situation.
I tried to provide client id of the MSI within the provider block but terraform somewhat considers 1 MSI as default and goes along with it.
You can define multiple providers in the terraform script, then use the MSI authenticate. And you can choose which provider to use with the provider property when you create the resources.
I am using Azure CLI 2.0 and I am trying to create Azure Container Service type Kurbenetes, with this command (I already created resource group)
az acs create --orchestrator-type=kubernetes --resource-group=mi-shared-docker-test --dns-prefix=kube --name=mishareddocker
I am getting this error
waiting for AAD role to propagate..........Could not create a service
principal with the right permissions. Are you an Owner on this
project?
I can create any vms, webapps etc, but why am I receiving this issue ?
Well, the error states it pretty clearly, you don't have the right permissions, you should read on the ACS\Kubernetes guide.
I understand you are using AZ, not azure, but the idea is the same, you should have enough permissions and a service principal to deploy Kubernetes on Azure.
You need to look specifically at this link.
There's an typo in your command, orchestrator=type should be orchestrator-type (dash instead of equals)