My subscription has a service principal that must have contributor rights. These rights will be inherited by all resource groups. In one resource group that has been established for over a year. for security reasons, this service principal must be prohibited from doing anything. The maximum allowed is reading. I tried using https://learn.microsoft.com/en-us/azure/governance/blueprints/overview but apparently I misconfigured or just doesn't work in my case. Since under the credential of this service principal, I was able to delete the test storage account. Could you please help me set up these policies to see if it's possible or not? Thank you.
Related
I have a client that can only give me full access to one or two resource groups.
I need to deliver some prescripted terraform resources that contain the need for a service principal.
Can you lock an SP to a resource group? The subscription itself is a production subscription so they want to know if you can tie down using role base access just to that group.
Or should I be create a MI account?
Can you lock an SP to a resource group?
You most certainly can. Azure Role-based access control is very granular and you can apply access control at any level (management group, subscription, resource group or even at individual resource).
Please see this for more details: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-steps.
This is my first project in Azure. Please avoid if any mistake. I have a user group "Azure Cross Team Contributors". I want to add it in resource group contributors by default whenever I create any resource group. I got to know there is policy, But not able to write policy rule. What would be policy rule for this scenario.
Similar thread answered on Microsoft Q&A , so updating here for broader community usage. Thank you AshishMishra and DCtheGeek for helping on the thread.
Azure Policy lets you audit the compliance of the configuration of Azure Resource Manager (ARM) properties.
In some cases, such as AKS or Guest Configuration, it can also audit configuration of Resource Provider properties. While Azure Policy can be used to audit how a role definition is defined (sample here), it isn't for applying roles to specific objects. That's the domain of Azure role-based access control (RBAC).
If you want the group "Azure Cross Team Contributors" to have access to all resource groups within a subscription, an easier alternative is to grant the role assignment at the subscription scope.
There isn't a built-in role with the name "Resource Group Contributors".
Feel free to revert back if you have any further queries. Thank you.
What are the best practices when using Terraform to provision infrastructure on Azure? We are struggling to decide between two variants:
Create one Service principal for Terraform and give it Owner rights to the whole subscription so it can create resource groups for each environment and assign roles to service principals in resources.
Create Resource Groups and service principals for each environment manually and assign terraform's service principal Owner rights to only the Resource Group.
The first option is more convenient, but I'm worried about security concerns when giving Terraform Owner rights on the subscription level.
What would be the best solution?
When you worry about security, there should be a limit to your requirements. If you want to create resources only in one resource group or serial resource groups, and then control them for all things. I'd suggest you create a service principal and assign it the Owner role of the resource group or groups, not the whole subscription. And it's the best way for security and you also have all the rights to control the resources in that group or groups, only limit the scope to that group or groups.
Assign the Owner role to the whole subscription, it's not secure, you know, there would be some mistakes on somebody sometimes.
We are building a solution in Azure Government and we will be using Terraform to deploy the solution. Seems the preferred method is to create a Service Principal for Terraform with the Service Principal having the Contributor role scoped to the subscription.
The one issue with this we are looking to solve is that this gives the Service Principal management plane access to the Key Vault...since it is in the subscription. With Contributor role, the service principal is not able to create new access policies (assign itself or others permissions to the data plane) but we are looking for a way that can remove the service principal from having any management plane permissions.
We have tried putting a ReadOnly lock on the Key Vault before creating the Service Principal but the lock does not stop the service principal from getting the Contributor permissions on the Key Vault.
Outside of creating a new role that has Contributor for everything EXCEPT for Key Vault, does anyone have any creative ideas that might help achieve this?
Yes, the root cause of all security issues is that the Service Principal's contributor role assignment is at the subscription level/scope, which enables it to do quite damage specially if multiple applications are deployed to the same subscription (e.g. delete any resource group).
One approach would be:
Provision one resource group for the Azure Key Vault specific to the application and region (the latter in case of geo-distributed applications).
Provision the Azure Key Vault on the resource group created on the previous step.
In our case, the Security Office was responsible for the first 2 steps, where they had monitoring (e.g. email, text-messages, etc.) for any change in the Azure Key Vault (e.g. new keys/secrets/certificates added/deleted/changed, permission changes, etc.).
Provision a second resource group, which will serve as a container for the application components (e.g. Azure Function, Azure SQL Server/Database, Azure Service Bus Namespace/Queue, etc.).
Create the Service Principal and assign the Contributor role to the
application resource group only, for example:
scope =
/subscriptions/{Subscription Id}/resourceGroups/{Resource Group
Name}
Find a sample PS script to provision a Service Principal with custom scope at https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1.
Give appropriate permissions for the Service Principal in the Azure
Key Vault. In our case, we decided to have separate Service
Principal accounts for deployment (Read-Write permissions on keys/secrets/certificates) and runtime (Read-Only permissions on keys/secrets/certificates);
Find a sample PS script to set Service Principal permission on an Azure Key Vault at https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1.
Having that said, there are lots of inconveniences with this approach, such as:
The process (e.g. via runbook) to provision the Azure Key Vault (including its resource group) and the application resource group will be outside of the main Terraform template responsible for the application components, which requires coordination with different teams/processes/tools/etc.
Live site involving connectivity often involves coordination among multiple teams to ensure RTO and MTTM (Mean Time To Mitigate) goals are achieved.
The Service Principal will be able to delete the application specific resource group when terraform destroy is executed, but it will fail to recreate it when running terraform apply after that due to lack of permission at the subscription level/scope. Here is the error:
provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '' with object id '' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/{Subscription Id}'.".
Yeah, I know, this is a long answer, but the topic usually requires lots of cross-team discussions/brainstorming to make sure the security controls established by the Security Office are met, Developer productivity is not affected to the point that it will impact release schedules and RTO/MTTM goals are met. I hope this helps a bit!
can someone please help me with the following question
if I have an Azure Subscription, Resource Group then an Azure Key Vault in that resource group can I block inheritance from the Subscription and Resource group so users with rights at the subscription and resource group level do not automatically inherited the rights (like contributor or owner etc.) to the Key Vault. I see I cannot delete the permissions at the key Vault level as the permissions are inherited. However I may still want someone to have say contributor at the subscription or resource group level but have lesser or no rights on the Key Vault itself
Please advise, thanks in advance
__AAnotherUser
The best solution for what you're looking for might be locks if this is the only resource you want to lock down:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-lock-resources
There are also more granular RBAC setups than just giving someone full owner/contributor access:
https://learn.microsoft.com/en-us/azure/active-directory/role-based-access-control-custom-roles