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 :
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.
Can I ask why you don't believe that to be a good idea? I would imagine having a "break glass" group which has the role "Owner" applied to it and adding users to that group if for whatever reason, manual changes need to be made to the environment would alleviate any risk of only allowing resources to be managed by Terraform.
I will update my answer with more details when I have more time :) But theoretically, it's a very good idea, and for small projects with few resources, I'll definitively implement it. But at enterprise scale (I don't know about your use case), it may become too difficult to manage. Another issue is that you cannot unfortunately create all resources with Terraform (new GCP products), or update (for example, stop Compute Engine instances), so you sometimes have to rely on the Console/Cloud Shell/Deployment Manager. These operations will not be tracked in Terraform state.
@ellefc I've updated my answer, I hope it helps clarify.