I have come across a situation, where i have to pass this {azurerm_app_service.app1.identity.0.principal_id to SQL Server inside User assigned managed identity? Any suggestion how to achieve that.
Managed identities is a Microsoft Azure feature that allows Azure resources to authenticate or authorize themselves with other supported Azure resources. You can use a system-assigned managed identity or a user-assigned managed identity (preview) in your case.
But terraform currently don't support the user-assigned managed identity for Microsoft SQL Azure Database Server. If you check the identity argument block in this terraform document, you will find the following -
An identity block supports type which specifies the identity
type of the Microsoft SQL Server. At this time the only allowed value is SystemAssigned.
So you can use the system-assigned managed identity with terraform now. Check this terraform document for more information.
I can see from the list of built-in roles that RBAC is used to control the access that people have to Azure resources. For example, the Virtual Machine Operator built-in role seems geared towards a person, it even gives permission to perform Microsoft.Support/* actions.
Currently I'm using an access policy on the key vault that is specifically for the Azure Functions App (using its system-assigned identity).
When I think about using RBAC for this and all other access to Azure resources, I am not sure how to go about defining roles. My main worry is that I either define them too granular, and I end up running into the RBAC limit for role assignments, or too broad and I end up giving applications permissions they should not have.
Should RBAC be used for custom applications we write and deploy as well? For example an Azure Functions App that has to be able to get a secret from a key vault?
There are two ways to control the access to azure keyvault data plane, access policies and RBAC roles, you need to select different options to use different ways in the portal.
In your case, if you use the access policies(select Vault access policy above) for the system-assigned MSI(managed identity) to get the secret, no need to use RBAC roles additionally, the permission in access policies is enough.
If you want to use the RBAC roles, select the Azure role-based access control above, then use the Key Vault Secrets User is suitable.
I have been looking into managed identity and AKS cluster and this is my understanding:
I can assign only a single user managed identity to the AKS cluster.
I have to do the relevant role assignments to the identity for getting access.
Now my question is, let's say I have two different pods. One pods want
to access keyvault and the other pods wants to access Azure DNS. The
only way of making this work is modifying the user managed identity to
give access to both the resources. But now it seems both the pods can
access both the resources.
Now my question:
Is my above understanding right and is this the usual way of doing things using AAD Pod Identity ?
Is there a better way to do this to avoid the above security concern ?
Regarding the managed identities in AKS there are two things they are uses for. The AKS cluster itself and its pods.
Regarding the managed identity for the cluster, that one is used to access several azure resources as described in the docs:
Currently, an Azure Kubernetes Service (AKS) cluster (specifically, the Kubernetes cloud provider) requires an identity to create additional resources like load balancers and managed disks in Azure. This identity can be either a managed identity or a service principal.
Then you have managed identities for Pods. This is currently in preview and available on linux nodes only!
You can create more than one of them and assign permissions per identity. Then you need to add a pod identity that refers to the managed identity and use it when you deploy the pod.
You can have up to 200 pod identities this way.
So, back to this question
Now my question is, let's say I have two different pods. One pods want to access keyvault and the other pods wants to access Azure DNS. The only way of making this work is modifying the user managed identity to give access to both the resources. But now it seems both the pods can access both the resources.
That is not correct, as stated you can have multiple pod identities each with their own access permissions.
I would like to know if it is always recommended to use Managed Identities in Azure , mostly system assigned or a Service Principal?
When should Service Principals be used in Azure compared to a managed identity, what is the advantage of one over the other?
Any help would be appreciated.
Internally, managed identities are service principals of a special type, which are locked to only be used with Azure resources. When the managed identity is deleted, the corresponding service principal is automatically removed. Also, when a User-Assigned or System-Assigned Identity is created, the Managed Identity Resource Provider (MSRP) issues a certificate internally to that identity.
Source: What are managed identities for Azure resources?
and
So what’s the difference?
Put simply, the difference between a managed identity and a service principal is that a managed identity manages the creation and automatic renewal of a service principal on your behalf.
Source: What’s an Azure Service Principal and Managed Identity?
A managed identity is a type of the service principal.
A service principal can be one of three types: application, managed identity, and legacy. The division into types is based on circumstances of their usage. Thus their specific handling also differs based on their type.
rickvdbosch provided link to an article that talks about specifics of the managed identity type of the service principal.
For those who would like to learn about the concept of the service principal object and its types, here is a link to a different article:
Application and service principal objects in Azure Active Directory.
An Azure service principle is like an application, whose tokens can be used by other azure resources to authenticate and grant access to azure resources.
Managed identities are service principals of a special type, which are locked to only be used with Azure resources.
The main difference between both is that in managed identity you don’t need to specify any credentials in your code compared to service principles where you need to specify application id, client id, etc to generate a token to access any Azure resource. Ideally, you should opt for service principal only if the service you use doesn’t support managed identity.
Service Principal
We can say the most relevant part of the Service principal is the Enterprise Apps section under Azure Active Directory. This is basically an application that will allow your user apps to authenticate and access Azure resources, based on the RBAC.
It essentially is an ID of an application that needs to access Azure resources. In layman’s terms, imagine if you have to assign certain access to your colleague so that he\she can access Azure resources and perform required tasks, you can use their email id as a way to authenticate the user.
Managed Identity
We can say that the Managed Identities are actually Service Principals and they are identical in the functionality and purpose they serve.
The only difference is, that a managed identity is always linked to an Azure Resource, unlike an application or 3rd party connector mentioned above. They are automatically created for you, including the credentials; big benefit here is that no one knows the credentials
There are two types of managed identities:
1.) System assigned; in this scenario, the identity is linked to a single Azure Resource, eg a Virtual Machine, a Web App, Function,… so almost anything. Next, they also “live” with the Azure Resource, which means they get deleted when the Azure Resource gets deleted.
2.) User Assigned Managed Identity, which means that you first have to create it as a stand-alone Azure resource by itself, after which it can be linked to multiple Azure Resources. An example here could be out of integration with the Key Vault, where different Workload services belonging to the same application stack, need to read out information from Key Vault. In this case, one could create a “read KV” Managed Identity, and link it to the web app, storage account, function, logic app,… all belonging to the same application architecture.
Managed Identities are tied to a resource (VM, Logib App, etc). To give the resource grants and permissions for accessing(CRUD) other resources you use Managed Identities.
Service Principial do not have to be tied to a resource, they leave under tenant and above subscription, and what is more is more important - have some auth tokens that could be stored somewhere (Key Vault). It is like a fake user with some credentials and tokens.
A Service Principal could be looked at as similar to a service account-alike in a more traditional
on-premises application or service scenario. Managed Identities are used for “linking” a Service Principal
security object to an Azure Resource like a Virtual Machine, Web App, Logic App or similar
I'm looking for my VSTS deployment agent service principal to get the Object ID of a managed service principal (created by Data Factory V2).
It needs this for assigning ACL's in data lake store.
However as far as I can tell, it requires Read Permission on Azure AD.
I wish to avoid granting it read permission if possible, to follow the 'least privilege' mantra.
For non-managed service principals, I allow the deployment agent to manage service principals it has created (thus not needing full read access). However I suspect the fact that the service principals are managed by Azure it is unlikely I'll be able to give the deployment agent any ownership over the managed service principal (however I'm working with AD admins to see if there is a way).
I've tried everything I can think of mixing and matching Azure RM data factory v2 powershell modules and Azure AD modules.
Is it possible to get the id without Azure AD read access? Or a novel workaround (I'm considering a constrained Web API wrapper)?