How to connect securely from AKS cluster to Azure PostgreSQL Single Server using Service principal as the Managed Identity is not supported.
From my point of view you have 2 options (maybe more but lets focus on those 2):
Use Azure AD Workload identity together with federated identity credential linked to you Service Principal. Basically you configure trust between your AKS (OIDC issuer), the Kubernetes Service Account for your Pod and the Azure Service principal to access resources with an Azure AD Token. Here you have to adopt the code running inside your container to leverage the workload identity with the issued Azure AD access token.
Use the Azure Key Vault Provider for Secrets Store CSI Driver. You will configure the Kubelet Identity of your AKS to read the secrets from the KeyVault and mount the Service Principal Client ID & Client Secret (saved as KeVault secrets) during Pod startup as volume into your pod. Here you have to adopt the code running inside your container to read the information (Client ID & Secret) from the filesystem inside the pod. P.s.: You can also use Workload Identity, System assigned identity or a Service Principal instead of managed-identity to access the KeyVault.
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'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 )
As per my understanding, Azure Kubernetes Service(AKS) allows getting credentials for admin and user identities. Can the user identity be an AD app or a managed identity?
I'm writing .Net code. Can you provide some sample where we can get the user credentials from AKS cluster by using AD app credentials, assuming I have already done AD integration with my AKS cluster and have already assigned the appropriate role binding for my AD app?
The security section here - https://learn.microsoft.com/en-us/rest/api/aks/managedclusters/getaccessprofile needs implicit flow. How does implicit flow work for AD app credentials?
You can use Implicit grant flow to get access token.
You'll need the Azure Kubernetes Service Cluster User built-in role to access an Azure AD enabled cluster.
Get the user credentials to access the cluster:
az aks get-credentials --resource-group myResourceGroup --name MyManagedCluster
Or use List Cluster User Credentials API.
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerService/managedClusters/{resourceName}/listClusterUserCredential?api-version=2020-04-01
Because Get Access Profile API will be deprecated in the futhure.
I am trying to use azure keyvault in my MVC application to get storage account keys. This MVC application is hosted in different azure subscriptions with storage accounts belonging to those subscriptions. Is it possible to have a one Azure Keyvault resource in any subscription and serve keys for storage accounts residing in different subscriptions?
Yes it is possible.
You will need to make identities for the apps using the Key Vault in the Azure AD tenant where the Key Vault's subscription is. And then assign permissions to access the vault to those service principals.
Then you can put the client id, client secret and tenant id to the apps that need to access the Key Vault. They should then be able to call it, since they have an identity that is allowed access. Key Vault uses an HTTP API so whether the apps and the vault are in the same subscription/data center/cloud provider is irrelevant.
Hi you can use below to do via azure CLI
az webapp config ssl import -n 'webappname' -g 'webappresourcegroup' --key-vault "/subscriptions/[provide subscriptionID]/resourceGroups/[Provide resource group Name]/providers/Microsoft.KeyVault/vaults/[Provide Vault Name] --key-vault-certificate 'Provide certificate Name'