I'm exploring options for securing some Azure resources within a subscription from tampering, even by subscription owners.
The intent is to standardize our subscriptions which are used by other teams for their engineering. We've considered giving teams custom RBAC roles similar to Owner and Contributor, but slightly reduced--however we've found this approach to be high friction and not to cover 100% of our scenarios. In some cases excluding a permission is fine--in others we need to grant them those permissions but restrict them from being used on our resources.
Our preferred design is to create a resource group of a known-name in each standardized subscription, place the resources users aren't allowed to modify or delete in the group, and explore options to prevent subscription owners from tampering with that RG or its resources.
So far we've explored most options we're aware of:
excluding the action/permission isn't an option as the users need those actions/permissions to manage other resources of the same type (i.e. denying users the ability create/modify/delete resource groups isn't viable)
defining an Azure Resource Policy to either deny all operations on the RG (which doesn't appear to function)
defining an Azure Resource Policy to require our standard resources -- this still does nothing to prevent deletion
Blueprints (in Preview) to create a locked (with some kind of lock other than a Resource Lock?!?) RG and apply deny assignments
Other options begin to get "sloppy". They leave gaps, or create significant complexity. Such as...
Relying on Policy to report (and possibly redeploy) when required resources were destroyed
These resources are security and compliance related--Policy can eventually detect their absence, but the gap between deletion and detection leads to these subscriptions being potentially tainted
Denying our users the resource lock permissions, so we can exclusively lock our RG and they are unable to unlock it
When the RG is unlocked there is no protection -- so we would need to coordinate unlocking it, applying updates, relocking it, and re-verifying that nothing else snuck in while it was unlocked
Give our teams a single RG per subscription and only grant them permissions at the RG level
This may have merit if RGs could be nested -- and perhaps is one of the few viable options, but taking away Resouce Group management from Azure engineers feels wrong and would likely lead to RGs being 'bloated' with multiple deployments as well as
Blueprints may be an option, but raise similar questions around coordinating the unlocking and relocking of resources
And, Terraform is our IaC platform -- Blueprints are in some ways another layer of IaC, so while we may get this to work it will require some analysis to use Blueprint for just the minimum to create protections and Terraform to continue to do the bulk of the work
After learning more about Azure Policy I'm gaining the understanding that it's not capable of setting policies to prevent deletion. It can define conventions for creating or updating resources, it can create resources if they are absent, but it doesn't trigger during deletion and so resources required by Policy cannot be protected by Policy.
Overall this seems somewhat counter-intuitive--as delete operations are a /write permission just like create and update.
So overall I don't believe Policy is actually a permissions component. It lacks any context of who is performing an action and instead effectively is good for saying "if you do X it needs to meet criteria Y". And not saying "your subscription is required to comply with X".
This is surprising--does Azure not have any way of setting resource-level permissions at the Subscription level or above?
After communicating with our Azure contacts this is a known limitation. Presently there is currently no way to retract permissions once granted. I.e. if you grant a user the ability manage resource groups you can not deny them those permissions to a specific instance.
There are some half-baked abilities in AWS Blueprint, which can deploy a Resource Group with an RBAC Deny Assignment (only available via Blueprints). When assigning the Blueprint the "lock" is actually an RBAC Deny -- not a Resource Lock (confusing?).
Hoever they explicitly block that permission from being inherited. So while the resource group itself is "ReadOnly" nothing within it is. Using ARM templates deployed via Blueprints may support this -- but in our case that would involve rewritting months of work.
Hopefully Microsoft will add Deny Assignments directly to RBAC. They have the API and ability but are keeping it hidden/locked at the moment.
Related
I understand the objective of deploying infrastructure as code and appreciate the benefit of being able to enforce code peer review pre-deployment. From a Security perspective this technical control assures me that changes that are being made to an environment are peer-reviewed.
However, wouldn't it still be possible for someone with relevant permissions (e.g. with the role Owner) to make changes directly on the console/cloud shell? This change then wouldn't be peer reviewed.
Just want to check what, if any, controls there are to prevent this? Of course, i understand that one control would be to restrict IAM permissions on the project or at org-level to prevent changes being made since then only the terraform service account could make changes but i want to understand if there are any other controls.
Nothing will stop a user to create/update/delete a resource manually (by manually I mean here : via Console or Cloud shell) if he has
the IAM permissions to do so.
In the case of a manual resource update : if the resource is managed by Terraform, running terraform plan will alert you that a modification has been made. Indeed, Terraform will see a difference between the resource description in your
.tf file and the reality. If you apply these changes, it will revert modifications made manually by the user.
Running periodic checks to verify if some modifications have been made out of Terraform (on resources managed by Terraform) could be a
good idea to alert you that someone did something manually.
But in case of newly created resources (out of Terraform), unless the resource is imported in Terraform after creation (terraform import),
you'll never know that this resource have been created, and you could not track any modifications on that resource.
The only way to prevent resource creation is by restricting IAM permissions. For example, if nobody (unless Terraform service account) have the permission storage.buckets.create, then nobody (excepted Terraform service account) will be able to create a bucket. The same applies to resources update.
If you want all your resources to be managed by Terraform, remove the create/update IAM permissions to all users except Terraform service account. But be aware that :
you can't create/update all GCP resources with Terraform. Even if Terraform providers grows fast, there will always be some delay between a new GCP product and its implementation in Terraform GCP provider. Some time ago, I remember myself waiting for Cloud Composer resource in Terraform,
which appears in 1.18.0 version on 2018/09/17, though Cloud Composer was available since the 2018/05/01. If I have chosen to create resources with only Terraform, then I should have wait 4 months before starting to use Cloud Composer (this is an example amongst other)
you may sometimes want to create resources outside of Terraform, for testing purpose for example. If Terraform is enforced to create/update all resources across your organization, this will not be possible. Think about non-technical users who want to create temporarily some resources to make some tests : they probably won't learn how to use Terraform, so they'll either give up or ask someone to create resources for them. As your number of users increase, this should become cumbersome
reasoning by the absurd : do you want to manage all resources available using Terraform? If so, then you may want to manage also Storage objects with Terraform, because there is a Terraform resource google_storage_bucket_object. Except some very specific cases, you don't want to manage these kind of resources with Terraform (in Storage objects case, think of huge files)
In conclusion, managing all your resources across your organization using Terraform and restrict only Terraform service account to create/update/delete resources is definitively a goal to aim for, and should be done as much as you can, but in reality, it is not always completely possible. Critical resources must be protected, and so IAM for updating/deleting them must be restricted. Also, owner role is not the only one that allows creating/updating/deleting resources. You will have to be very careful about roles you give to your users to ensure that they won't have such permission, and will probably rely on custom roles because predefined roles are often too broad.
I want a group of people to be able to completely manage a subscription, including managing access to resources within it, except for managing the subscription itself. So (for example) when a new resource group with a storage account is added to the subscription, I want them to be automatically (by inheritance) have all rights to the storage account, including the right to give people roles on that storage account. I just don't want them to be able to give other people roles on the subscription itself, so no adding administrators to the subscription etc.
Is a role (or combination of roles) built-in that I can use for that? Will I have to look into creating a custom role, or is what I'm looking for not possible?
well, I might be wrong, but I dont see how this could be possible:
You want a user to inherit rights from subscription level (only way to get rights to a newly created resource group)
you want rights to assign permissions
you want to block rights to assign permissions on subscription level
so, essentially you are asking for 2 things that conflict. this would not be possible even when using Azure Blueprints, because you cannot block inheritance yet. so you cannot block rights on a specific level, you can only block rights on that level and all "downward" levels
I want to create an Azure key vault with fairly restricted access (one or two of our apps). I've created the Key Vault through the Azure portal, but when I look at the Access Control section, I find that several Apps and Users have the Contributor role (inherited from the subscription) for the key vault, which gives them more access than they should have.
Since the subscription is the highest level at which access control can be set, there is no way for me to revoke access for these apps/users without revoking it at the subscription level, and this would probably cause all sorts of problems. (it's not really clear what permissions these need, so it'd be a bit painful to have to give those permissions at a resource group or resource level). What's more, there'd be nothing stopping someone who comes along later from adding contributor roles at the subscription level (for some new app, for instance), and breaking the security of the key vault.
So with all of this in mind, what would be the best way to limit access to an azure key vault, so that only the apps/users I want have access to it, despite the fact that several apps/users already have these permissions at the subscription level?
More info: We're using the Azure Resource Manager model, and everything is currently stored in one subscription.
It looks like you can not achieve this with the way RBAC works today.
Here are a couple of feedback requests already running on Feedback Forums - https://feedback.azure.com. One is for Key Vault and another takes the example of a storage account but essentially looking for the same feature to override the inherited permissions.
You may want to vote up for these requests.
Deny users with inherited permissions to Azure Key Vault Service from modifying Access Policies
Exclude / override RBAC permissions inhereted from a subscription at a resource group level
UPDATE (to answer additional queries from comments):
Not granting subscription-level access in the first place (except to
admins)
Yes this would definitely help.
Another suggestion would be to try and use Resource Groups to organize your resources and then assign roles on these Resource Groups (scope). This way, you don't need to give access to individual items, but at the same time you can avoid giving access at the highest level of subscription.
An option you have is to create a blueprint that you can use to configure locks on your keyvaults.
If you deploy this BP as readonly the locks can't be removed from your vault so no-one can alter te permissions of your vault until you change the blueprint config again to don't lock and then remove the lock from your vault.
Applications etc having access to your vault (aka dataplane) de still access the keys ofcource
A group of friends and I are working on an private project and are considering hosting it on Azure.
I have an account on Azure and will be the one controlling the costs.
Is it possible to assign a pool of resources (e.g. Functions + database) to another user(s), preferably also assigning a cost limit for it to avoid things exploding?
You can give them access to a subscription / resource group / resource by going to e.g. the subscription and clicking on Access Control (IAM).
There you can enter their email address, and give them the role needed. Reader for read-only, Contributor for Read/Write, and Owner for Read/Write + access management. There are a bunch of others too. More about Role-based access control
I am not aware of a way to limit cost for individual users, though you can for example setup Billing alerts.
You can use ARM policies to limit the types of resources that can be used. As an example, you can deny the use of certain very expensive VMs to a group of users. Some samples of these policy templates can be found here
As stated in other answers, you can assign access to others on various levels. You can assign to "live" accounts (Hotmail,outlook,live.com etc) but as part of your subscription you can also create an Azure Active Directory instance on which you can create users. You would also want to use this AAD to create service accounts in the future, register applications for authentication, etc.
I want to set up TFS permissions to better reflect the responsibilities and levels of clearance of different roles within my organization; I'm finding that the default Reader and Contributor groups are too coarse-grained for my needs (and too loosely named).
To keep maintenance overheads to a minimum, I'm therefore thinking of replacing the Contributor and Reader groups with my own groups, but... is there any negative side effect of deleting those two groups? Does any part of TFS rely on them being there?
You should be fine. The built-in groups at the project level are for convenience only.
(This is NOT true of some of the server-level groups like TF Valid Users and TF Licensed Users. Maybe TF Service Accounts as well, I forget. These "well known groups" play a specific role in internal TFS operations. Delete them and the system won't work, even if you recreate them exactly as they were, because the GUIDs won't match.)
Just make sure that if you remove the Project Administrators group, you still have admin privileges inheriting from another group (eg TF Admins), otherwise you'll find yourself in a catch-22 situation. If you do get stuck by accident, know that local admins on the application tier machine are "TFS super-admins" who can bypass all security checks and put things back in order.
-EDIT-
One thing you will have to do is manually grant permissions to the new groups in Sharepoint and Reporting Services. I'd recommend downloading the TFS Admin Tool -- makes these tasks much simpler.