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.
Related
I am currently trying to work out a concept for a roles and rights concept. Azure RBAC already has a few built-in roles but I am trying to create a few more custom roles. Are custom roles directly linked to the RBAC? And does anyone have any suggestions which roles I should definitely add? I'm not familiar with all applications in Azure at the moment since i have only been working with azure for a few weeks, so I would appreciate some suggestions. I am also trying to understand the hierarchy and structure behind Azure RBAC.
If anyone has worked out such a concept themselves or works a lot with azure rbac, feel free to share your experiences or results!
Azure role-based access control (Azure RBAC) helps manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.
Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.
Create your own custom roles. Just like built-in roles, assign custom roles to users, groups, and service principals at management group (in preview only), subscription, and resource group scopes.
Custom roles can be shared between subscriptions that trust the same Azure AD directory. There is a limit of 5,000 custom roles per directory. Custom roles can be created using the Azure portal, Azure PowerShell, Azure CLI, or the REST API.
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 have two subscriptions.
On one subscription I run logic apps and on the logic apps I have azure functions.
The other subscription contain target resources for the automation via logic apps and azure functions.
In order to run the Logic Apps and Azure functions associated it with it, what privileges do I need on target subscriptions? I want to be able to do things like stop VM, change NSG settings, run malware scans, etc
Do I need to run the logic app using an account that has owner permissions on both the subscriptions?
Regards,
Kelly
Its best to use a service principal for having centralized access control.
With this, you can use the service principal to authenticate and authorize actions against resources. It can be configured for the Azure Resource Manager connector in Logic Apps as well.
Another option would be to use Managed Identity, but that is supported only for the HTTP Action.
Even in your Function Apps, you could either setup Managed Identity or use the Client Credentials Flow using the Service Principal details.
As for the exact permissions for this service principal, you can use this reference of built-in roles for providing granular control. For example, to just stop/start VMs, your service principal would need Virtual Machine Contributor.
You could also provision finer access to resources by creating custom roles.
I am currently in the process of setting up Sentinel POC, within Sentinel you have playbooks which is basically Logic Apps, it is same as the playbooks in security center.
I need to know what permissions i need on target subscriptions in order to automate remediation of alerts, for example isolate a VM, Stop a VM, etc.
Our Sentinel will have its own subscription in a tenant where there are 100's of subscriptions.
Its best to use a service principal for having centralized access control.
With this, you can use the service principal to authenticate and authorize actions against resources. It can be configured for the Azure Resource Manager connector in Logic Apps as well.
Another option would be to use Managed Identity, but that is supported only for the HTTP Action.
As for the exact permissions for this service principal / managed identity, you can use this reference of built-in roles for providing granular control. For example, to just stop/start VMs, your service principal would need Virtual Machine Contributor.
You could also provision finer access to resources by creating custom roles.
What is the difference between IAM and Azure AD on the azure cloud?
They don't make it clear.
Identity Access Management is what they call the Role-Based Access Control system in Azure subscriptions. Basically, it allows you to give users certain roles on subscriptions, resource groups, or individual resources.
Azure AD is a more general identity management solution. It allows you to manage users and applications, users' access to those applications and more. Calling it the "same as on-prem AD" is not really quite right, since their features differ quite a lot. The general purpose is similar to on-prem AD of course.
Logically Azure subscriptions exist within one Azure AD (they are linked to one). But having your user account in Azure AD does not give you access to Azure subscriptions! In addition to a user having to be a member (or invited guest user) of the AAD assigned to the subscription, you also have to use the RBAC (IAM) system to assign roles for users.
Azure AD is for Authentiction - User must prove who they are using a Username and Password
IAM (RBAC) is for Authorization - a User is assigned a role or permissions to use a specific resource.
What is the difference between IAM and Azure AD on the azure cloud?
Azure IAM is Azure Role-Based Access control (RBAC). Work for Azure subscription, to manage Azure resources.
Using RBAC, you can segregate duties within your team and grant only
the amount of access to users that they need to perform their jobs.
Instead of giving everybody unrestricted permissions in your Azure
subscription or resources, you can allow only certain actions. For
example, use RBAC to let one employee manage virtual machines in a
subscription, while another can manage SQL databases within the same
subscription.
Azure AD same as on-prem AD, create users to access or manage some applications.
Azure IAM same as Active directory group(have some permissions), Azure AD users in this group will have those permissions.
Identify and access management (IAM) is called RBAC (Role-Based Access Control). This is used to grant level of access such as reader , contributor , owner to Azure resources and hence perform role assignment.
Azure AD is identity management solution for Azure. It is a live directory or a database that stores the user accounts and their password.