I'm creating subscriptions in Azure with a number of RBAC roles assigned: hosting team and project team. The hosting team should have full access to everything, and the project team should have full access to everything baring a few exception, e.g. no access to the 'Networking' resource group (although they are allowed to create their own resource group(s) containing networking). We have set the RBAC owner for the project team at the subscription level, but in doing so, this also allows them to fully manage the restricted areas.
In principal the 'deny' assignments in Azure Portal would fit our needs, however they are currently only available for Azure Blueprints. Any ideas?
Block inheritance doesnt exist yet, your only option is to carefully craft and assing custom rbac roles or carefully assing built-in roles (so, never at sub level, only at resource group level).
Or use Azure Blueprints, it appears they added support for that there.
Related
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 want to use a service principal to deploy a single ARM template to our Azure account.
I cannot find documentation for how to grant the least possible privilege, but it appears the only way to make this work is to grant contributor on the subscription.
Is there a way to limit the role on my service principal to only deploy ARM Templates or at the very least limit it to a single resource group?
actually, for each template you can figure out the minimum possible permissions by looking at the template, they would be resourcetype + /write. and the permissions to create deployments Microsoft.Resources/deployments/write.
but its really easier to just give a person contributor over the resource group. if you are concerned about security you can use Privileged Identity Management in Azure AD
In the access control (IAM) section under a Resource group you can make the service principle you created 'Contributer'. this will make sure that that user can only deploy resources within that resource group. This way the account doesn't need any permissions on the subscription level.
When you go to the Access Control section click Add, and select "Add role Assignment"
In the panel that shows you can select the role "Contributer" and lookup the Service principle you created.
Then click 'Save' to finish and you should be good to go
I tend to make service connections (with separate Service Principles) in DevOps per environment this makes it clear what resources you can touch and prevents people from accidentally deploying to incorrect locations from a pipeline because the typed in the wrong resource group name.
I want to find or create an azure role that has the same capabilities as an Owner, or at the very least a contributer. But this role should not have access to create azure resources.
I've been going through the pre-defined roles that exist.
this makes no sense in Azure RBAC context. you cant edit but not create resources, because this is being governed by the same permission: resource/write.
you can achieve something like that by having a role that can do anything except writes, but that would mean that it cannot edit resources, which is not what you are after, probably.
technically you can grant contributor permissions to each individual resource, that way user wont be able to create new resources, only modify existing ones (he would be able to delete resource).
I have the same requirements, and I managed to configure it by taking the Contributor role as base and adding
"Microsoft.Resources/*/write"
in notActions section of role JSON configuration.
What it does is that it prevents deployments. Every resource creation is a deployment.
As far as I have tested every "edit" operation on resources works, even deployment slot creation for Web Apps, but you can disable that too if you need.
I have two Azure Subscriptions, Enterprise and MSDN subsciptions. I want to transfer a resource group from one subsciption to another. Already found this method but it requires to change the tenant of one of the subscriptions. How to move resources from subscriptions in different directories in Azure
These accounts have different active directories (Cannot Change Directory). So essentially the tenantid remains different.
Official Docs also mentions this way https://azure.microsoft.com/en-in/documentation/articles/resource-group-move-resources/
Is there any alternate methods to move the RG?
I think there is no alternate method to move the RG. What you can do as a Workaround is to try to download the Automation Script (ARM template) for your Resource Group, delete the RG and deploy the template to your new subscription. But this only works for services that uses the Resource Manager (not Service Manager).
Also this only creates the services / infrastructure but you probably have to redeploy content depeding on which resources you are using.
Someone mentioned this can be done by contacting the support.
I found that its possible in some scenarios to do this by moving the resource group to a new/temporary subscription, and then transferring ownership of that subscription to the desire account. It doesn't matter if the account is on a different domain or not, however not all resource types can be transferred (e.g. Azure role-based access control assignments).
https://learn.microsoft.com/en-gb/azure/cost-management-billing/manage/billing-subscription-transfer?WT.mc_id=Portal-Microsoft_Azure_SubscriptionManagement
We are developing applications in .Net and deploying them to Azure app services. We currently have a multi-tier environment (QA/STG/PROD). In order to replicate the same environments we are using slots. However, the issue with slots is all developers who has access to QA slot are able to view/modify STG / PROD slot settings. We want to segregate this with authorization where-in users should only be able to publish apps on QA. Should we still use slots or we go with separate web apps?
As suggested in one of the comments you can use RBAC (Role Based Access Control) to control the user permissions on the web app/slots.
Azure RBAC has three basic roles that apply to all resource types:
Owner has full access to all resources including the right to delegate access to others.
Contributor can create and manage all types of Azure resources but can’t grant access to others.
Reader can view existing Azure resources.
So, you could add the developers as a READER to the webapp and as a CONTRIBUTOR to one of the slots. This will prevent the web app changes
Further, you can customize the RBAC to suit your requirements.
You can create a role with custom
Refer this article:
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
You can go with slots. Each slot creates a separate URL and you could control access to the slots by Authenticating using AD.
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/