Hello.
At my previous job, we used Terraform Cloud and it was very nice. At my current job, we’re using Gitlab for our CI/CD. State is stored in Gitlab but for the sake of this post that’s not a crucial detail.
Right now, a user can run terraform apply and terraform destroy from their workstations, provided they have run terraform init with the correct incantations first.
This is not good. It means that our state can be manipulated before code is merged to the main branch. For obvious reasons, I don’t like this.
How can I mitigate this?
Thanks.
Hi @jeffmacdonald,
Typically a requirement like this would be met with some sort of access control rule in the remote system, so that then the Terraform client would not be able to perform some or all of the operations required to start a run outside of the automation system.
The Terraform client itself cannot enforce any such rule because it is code running directly on the user’s workstation, and so the user could just modify Terraform to remove the restriction, or use an older version of Terraform that didn’t have it yet, etc.
I don’t have any direct experience with GitLab and so I can’t give direct advice, but an idea I would start with here is to try to configure GitLab so that only the automated system has access to the state, and no tokens representing human users have that access. That way if those human users try to use their tokens to run terraform apply the action will fail immediately, because Terraform won’t be able to retrieve the prior state.
Yeah, I"m going to see if Gitlab has a mechanism for this. The user still needs access to state to do a plan. But read only access.
Terraform Cloud made this so easy, but is against policy where I’m at.