Protecting AWS resources created by Terraform from getting edited by colleagues

I’m working at a small to medium sized company doing DevOps.

I would like to know where I can find info about good ways to protect resources created through Terraform to not get edited by anyone else?

My DevOps colleagues each have admin accounts for the company AWS account. I’m worried my colleagues (or even I) would accidentally make small edits to AWS resources created via Terraform, because we forgot that that should be done through Terraform.

My idea was to make sure Terraform marks all resources with a specific default tag to indicate that I want that resource “protected” (e.g. ProtectedResource=1), and then I’d put all AWS users including admin users into a default group that would have policies checking that if whoever wants to make an edit to a resources is not the owner of the resource and the resource has a ProtectedResource=1 tag, then access to write should be denied.

I don’t know how I would write those policies though. Also this may not be the best approach. So I would appreciate being pointed in the right direction for this with good concrete examples, rather than just general theory e.g. “configure it with policies somehow”.

While in theory you might be able to do something with tags for some resources, for others that just wouldn’t be possible. You’d either need to just remove certain edit permissions from the admin users or live with the case that someone might make changes outside of Terraform.

For our developers we do the former, and only give them limited permissions to make changes - things like starting/stopping/destroying instances and taking backups, but not things that are more permanant changes (such as making a new EKS cluster or removing an ECR repository). The idea is that the developers have the ability to make emergancy changes, but everything else has to be done via Terraform.

For our admin users we do give them much broader permissions. However we expect them to not misuse this ability, making changes directly only if essential, and even then ensuring the changes are reflected in the Terraform code as quickly as possible. In the normal non-emergancy case all changes should be via Terraform.

One item that we have on our backlog is to proactively scan for config drift (finding differences between what the Terraform code says and reality) to detect anything that does get done incorrectly, but that’s not something we’ve had chance to implement just yet.

I would be careful about removing all ability to make changes other than via Terraform. There will always be situations where the Terraform change isn’t possible (e.g. because things are suffficiently broken to prevent Terraform from running) or is too slow.

2 Likes