Currently, I am working on establishing enterprise-scale landing zones for Cloud Adoption Framework in Azure.
Azure has a list of BuiltInRoles defined as mentioned in this article - https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles.
It is unclear to me which role should be assigned to which resource
Especially for the below Resources
Management Groups
Subscriptions
Vnets
Gateways,
VMs
Storage Accounts,
SQL databases
Can you suggest what are all the Roles should be assigned while provisioning any of the above listed Resources?
The Cloud Adoption framework is not about putting some roles on some arbitrary resources. You have to look at the framework in terms of hierarchical levels. Each hierarchical level has its own purpose and therefore uses its own set of permissions to deploy the resources needed for that particular step. I referenced some role mapping templates from aztfmod (Terraform + CAF) so that you get an idea about the role/permission structure.
Level 0: Core platform automation
Billing subscription role delegation (source)
Credential role mappings (source)
Launchpad role mappings (source)
Level 1: Core platform governance
Level 2: Core platform connectivity
ASVM role mappings (source)
Level 3: Application landing zones vending machine
Level 4: Applications landing zone
If you understand the levels correctly, you are able to infer what permissions are needed at what stage of the deployment of the CAF framework. For example:
level 0 is initiated by a user that is tenant administrator and Enterprise Agreement (EA) user, besides it needs to be the owner of the initial "launchpad" subscription.
From there this user will create service principals for each of the other stages of the deployment, and delegate permissions according to the principle of least privilege.
Key vaults and key vault policies are used to exchange sensitive information like credentials in between steps.
Each platform step (automation, governance, connectivity) is then run by its own service principal with its own specific set of permissions set on a specific scope (management group, subscription, resource group).
When all the platform components are in place you’ll be able to provision custom landing zones. Where you’ll again create service principals that are scoped to a single subscription. These service principals are able to deploy resources only within that landing zone.
Etc.
I would not recommend setting CAF or the permissions by hand, because it will become a pain in the ass to maintain. You could for example use aztfmod a Terraform implementation of CAF. If you follow the steps as described here, you'll create terraform configuration to deploy a CAF setup.
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 would need to create a policy in subscription level contributor cannot able to create virtual machines and virtual network or any vnets. Only owner are able to create Vnets. How to do this
It looks like you might need to create a custom role.
You can add various roles using RBAC for Access management of cloud resources.
The following document has the information on all the built-in roles in Azure RBAC:
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
If built-in roles do not fulfill your requirements, you can also use create your own custom roles using PowerShell:
https://learn.microsoft.com/en-us/azure/role-based-access-control/tutorial-custom-role-powershell
Here is the Azure doc on understanding various roles and create in Azure portal:
https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles