I'm new to Azure and k8s and somewhat confused about when to assign rights to which principal.
Whats the difference between assigning rights to azurerm_kubernetes_cluster.[name].kubelet_identity[0].object_id vs azurerm_kubernetes_cluster.[name].identity.0.principal_id and are there any other principals on the cluster that might be relevant in some other situation?
azurerm_kubernetes_cluster.[name].kubelet_identity[0].object_id = Managed identity of your user node pool ( this identity is needed for example to access the ACR in order to pull images or acces the AKV via CSI integration )
azurerm_kubernetes_cluster.[name].identity.0.principal_id = Managed identity of your AKS ( this identity is needed for example to add new nodes to the Vnet or use Monitoring/Metrics )
Related
I'd like to assign a user assigned manage identity a role in resource group scope for Azure Container Instances related operation, such as list containers in a RG, start or stop an container group, is there any build-in role available for this purpose? I searched in the role list, not find any:
Usually,to use a managed identity, that particular identity should have the access granted to following one or more Azure service resources like azure web app, azure key vault(with access policies or roles), or azure storage account in the subscription.
Select Access control (IAM).
and Add role assignment
Select roles , select appropriate role that you want the user identity to
have.
Here i am giving for storage access
To give storage access select storage blob data reader role or
contributer role
Then select the managed identity and select required user managed
identity.
But please note that from Limitations: Enable managed identity in container group - Azure Container Instances | Microsoft Docs
Currently you can't use a managed identity in a container group deployed to a virtual network.
Container groups which are running in Azure Virtual Networks do not support managed identity authentication image pulls with ACR.
If system assigned identity is enabled, then the group must have 'Contributor' role in order to have access to a storage account.
Reference:
use-a-managed-identity | Microsoft Docs
I would like to know under whose authority AKS is creating the resource.
I'm trying to create an Internal Loadbalancer in AKS, but it fails without permissions.
However, I don't know who to give that privilege to.
The account that connected to AKS or the managed identity of AKS ? Or something else ?
Is the account that connected to AKS in the first place the same as the account that creates the AKS resources ?
It would be great if you could tell me the source of the information as well, as I need the documentation to explain it to my boss.
Best regards.
I'm trying to create an Internal Loadbalancer in AKS, but it fails
without permissions. However, I don't know who to give that privilege
to. The account that connected to AKS or the managed identity of AKS ?
Or something else ?
You will have to provide the required permissions to the managed identity of the AKS Cluster . So for your requirement to create a ILB in AKS you need to give Network Contributor Role to the identity.
You can refer this Microsoft Documentation on How to delegate access for AKS to access other Azure resources.
Is the account that connected to AKS in the first place the same as
the account that creates the AKS resources ?
The account which is connected to AKS is same as the account that created the AKS resources from Azure Portal (User Account) But different while accessing the Azure resources from inside the AKS (Managed Identity / Service Principal).
For more information you can refer this Microsoft Documentation.
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.
We are planning to deploy multiple applications on our single Azure kubernetes cluster, each application will have its own set of Azure resources - eg: Key vault, Storage.
I am planning to provision individual managed identities per application and provide access to the relevant resources.
I know that AZURE AAD POD identify is the way to configure the pod to make use of the managed identity to access the Azure resources.
However how do I add multiple managed identity into the Azure kubernetes cluster? and is this the right of implementing?
As I mentioned before, I don't think you can add multiple MSIs to the cluster, you can just use a system-assigned MSI or user-assigned MSI for it.
Reference - Use managed identities in Azure Kubernetes Service
In your case, if you want to use different service principals to authenticate(essentially MSI is also a service principal managed by Azure), you can create multiple AD Apps along with the service principals.
Reference - How to: Use the portal to create an Azure AD application and service principal that can access resources
Then in the code of every application, use ClientSecretCredential to authenticate.
ClientSecretCredential credential1 = new ClientSecretCredentialBuilder()
.tenantId(tenantId)
.clientId(clientId)
.clientSecret(clientSecret)
.build();
Then use the credential to create a client e.g. SecretClient .
SecretClient secretClient = new SecretClientBuilder()
.vaultUrl("<your-key-vault-url>")
.credential(credential1)
.buildClient();
I want to programmatically give an Azure VM a contributor role to another modify things in another resources such as Route tables, Storage accounts.
https://learn.microsoft.com/en-us/azure/active-directory/managed-service-identity/howto-assign-access-cli
Above msft doc explain how one can give MSI enabled VM a contributor role to Azure Storage Account using Azure CLI. Can someone achieve the same using Azure Python SDK instead of Azure CLI ? Is it possible to achieve the same purpose without enabling MSI?
If you create a Service Principal for your VM, and push somehow the credentials on the VM, you can avoid MSI. But MSI was created on purpose to avoid that, since it's not really a simple process nor safe to push credentials inside a VM.
To assign a role to an Active Directory ID (whatever using MSI or dedicated ServicePrincipal), you can use this code to assign role (using azure-mgmt-authorization package).
https://github.com/Azure-Samples/compute-python-msi-vm#role-assignement-to-the-msi-credentials
# Get "Contributor" built-in role as a RoleDefinition object
role_name = 'Contributor'
roles = list(authorization_client.role_definitions.list(
resource_group.id,
filter="roleName eq '{}'".format(role_name)
))
assert len(roles) == 1
contributor_role = roles[0]
# Add RG scope to the AD id
# This assumes "sp_id" is either a MSI id or a SP id
role_assignment = authorization_client.role_assignments.create(
resource_group.id,
uuid.uuid4(), # Role assignment random name
{
'role_definition_id': contributor_role.id,
'principal_id': sp_id
}
)
Then this AD id will be able to act only on that role and nothing more.