Day-13-Terraform-AWS
- TF_Logs
- Terraform-Secrets
TF_Logs:
How to configure logging for Terraform
Logging info can be found in the Debugging Terraform section of the documentation and I would encourage you to turn it on when running locally. The information is valuable and more helpful than what is written out during plan or apply. Below are the instructions for enabling logging on both Windows and Linux. I will be setting mine to TRACE, but know that you can set it to DEBUG, INFO, WARN, or ERROR. I have chosen to use the most verbose setting as I don’t want to have to rerun commands when I hit an issue just to debug.
Configuring Terraform logging
Terraform depends on two environment variables being configured. These two variables are TF_LOG and TF_LOG_PATH, both need to be configured our no logging will occur. I will be calling my log file terraform.txt, however, it can be named whatever you like.
Setting in current session
If you want to temporarily configure these for your sessions here is how you do that for both PowerShell and Bash. Once these are set the next time you run the terraform command there will be a terraform.txt file in the current working directory.
PowerShell
> $env:TF_LOG="TRACE"
> $env:TF_LOG_PATH="terraform.txt"Bash
$ export TF_LOG="TRACE"
$ export TF_LOG_PATH="terraform.txt"This is great for the one-time session where you need detailed log information. I have found that I usually execute Terraform from within VS Code and my terminal buffer is overwritten so I can’t always scroll back far enough. This has caused me to enable it permanently and add the log file to my gitignore file.
Terraform-Secrets:
Use secret stores like Key Vault and AWS Secrets Manager.
Secret stores are secure solutions to store and manage secrets and keys like the AWS Secrets Manager. It is a dedicated database designed specifically to store secrets securely and stop unauthorized access.
Here are a few popular, secret stores:
- AWS Secrets Manager
Example — AWS Secrets Manager
Let us consider an example using AWS Secrets Manager. Create a secret to store our database credentials in the AWS Secrets Manager.
In our case, we have named this secret as dbcreds. It is of the type “others” and stores 2 key-value pairs namely: db_username and db_password, as shown below.
Note that we have used the same encryption key used in the previous example to encrypt these secrets in Secrets Manager.
To read and use these secrets in our Terraform configuration create below data sources.
The aws_secretsmanager_secret fetches the secrets data, but we cannot use the same to read secret values. To do the same, we have created another data source named aws_secretsmanager_secret_version to read the values
variable “username” {
type = string
sensitive = true
}
variable “password” {
type = string
sensitive = true
}
resource “random_password” “master” {
length = 16
special = true
override_special = “_!%^”
}
resource “aws_secretsmanager_secret” “password” {
name = “test-db4-password”
}
resource “aws_secretsmanager_secret_version” “password” {
secret_id = aws_secretsmanager_secret.password.id
secret_string = random_password.master.result
}
# Create an AWS DB instance resource that requires secrets
data “aws_secretsmanager_secret_version” “password” {
secret_id = aws_secretsmanager_secret.password.id
}
resource “aws_db_subnet_group” “default” {
name = “main”
subnet_ids = [
aws_subnet.Public-subnet.id,
aws_subnet.Public-subnet2.id,
]
tags = {
Name = “My DB subnet group”
}
}
resource “aws_db_instance” “default” {
identifier = “testdb”
allocated_storage = 10
storage_type = “gp2”
engine = “mysql”
engine_version = “5.7”
instance_class = “db.t2.medium”
username = “dbadmin”
password = data.aws_secretsmanager_secret_version.password.secret_string
publicly_accessible = true
db_subnet_group_name = aws_db_subnet_group.default.id
}
