Updated gitignore and added terraform lock files #27
Conversation
| # Exclude all .tfvars files, which are likely to contain sensitive data, such as | ||
| # password, private keys, and other secrets. These should not be part of version | ||
| # control as they are data points which are potentially sensitive and subject | ||
| # to change depending on the environment. |
There was a problem hiding this comment.
I am not sure this is always true though. The original idea about introducing tfvars files is that we want to keep some default values in version control and avoid going through repetitive questions on each TF run. Devs should make sensible decisions on not checking in sensitive data but only encrypted data. Following this gitignoring, can the current terraform.tfvars files be renamed to sth like terraform.tfvars.example as still being instructive?
There was a problem hiding this comment.
The current terraform.tfvars that have been checked in and committed won't be ignored, but new .tfvars files will.
Shouldn't the default values be provided in variables.tf files?
People make mistakes, it's better to systematically try to prevent it from happening instead of relying on people to be careful.
Yes we can have a terraform.tfvars.example file and ask people to copy it to terraform.tfvars when deploying, we're doing this in RADAR-Kubernetes with base.yaml file.
There was a problem hiding this comment.
Yes but variables.tf won't memorise values the user typed in during the first run. On consecutive runs, the user needs to type in the same values again and again if they forget (or don't want) to update the default values in variables.tf.
Great and it sounds terraform.tfvars.example could be the middle ground.
There was a problem hiding this comment.
In our own deployment I've created a terraform.tfvars file on the top level of this repo and run terraform commands with -var-file=../terraform.tfvars argument. I suspected that the S3 or Hashicorp backend also stores this file in a secure location but I haven't looked into them yet.
There was a problem hiding this comment.
Cool. In that case, how can other Devs see the terraform.tfvars and your change to it if *.tfvars is ignored?
There was a problem hiding this comment.
Alright. We are not using a top-level terraform.tfvars and hence I believe it is safe to merge this.
There was a problem hiding this comment.
How to you manage your terraform.tfvars file?
There was a problem hiding this comment.
Our terraform.tfvars files only contain non-sensitive values so they are version-controlled in the private repo for each cluster.
There was a problem hiding this comment.
Is it just a private fork of this repository with the terraform.tfvars committed to git?
There was a problem hiding this comment.
Yes, each cluster has its own forked private repo.
This allows ignoring
terraform.tfvarsfiles.Also committed
terraform.lock.hclfiles, I wanted to add them to.gitignorebut it seems like it's better to commit them.