D is the right answer.
I tested in my local machine to create Sql server with 2 environment vaiables $env:TF_VAR_sql_admin = "username" and $env:TF_VAR_sql_password = "sqldbpassword"
Also created the SQL Server with Terraform which accesses env variable during execution.
BUT FOUND MY SENSITIVE ENVIRONMENT VARIABLE VALUES ARE STILL LISTED IN THE "STATE FILE"
so answer should be "D"
That is because you are referring to a secret tied to a resource which will eventually always end up in the state file. The question is about secrets for provider authentication so to sign in to Azure for example. This will not end up in the state file when using environment variable hence:
The correct anwser is A.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.40"
}
}
required_version = ">= 1.3.6"
}
provider "aws" {
region = "us-east-2"
access_key = "MY AWS ACCESS KEY"
secret_key = "MY AWS SECRET KEY"
}
I provided the credentials directly in the provider block, then after apply the state file does not contain any information about these secrets.
D is correct, I just tried this in terraform and found that provider credentials are not stored in state file. The key here is provider credentials not other sensitive values.
So it should be A then? The question asks provider auth, and provider auth is by provider creds, which are then not stored in the state file when done via env vars..
When you use environment variables to store credentials, Terraform does not include these credentials in the state file. Environment variables are read at runtime, which means they are not persisted in the configuration files or the state file.
Answer is A 100%: Using environment variables
We already use Terraform this way:
Bash
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
Terraform
provider "aws" {
access_key = "YOUR_ACCESS_KEY"
secret_key = "YOUR_SECRET_KEY"
}
1. Code example:
...
resource "azurerm_sql_server" "example" {
name = "example-sqlserver"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
version = "12.0"
administrator_login = var.sql_admin_username
administrator_login_password = var.sql_admin_password
}
variable "sql_admin_username" {}
variable "sql_admin_password" {}
...
2. Set env variables:
export TF_VAR_sql_admin_username="adminuser"
export TF_VAR_sql_admin_password="SuperSecretPassword"
3. terraform init
4. terraform apply
5. After applying, if you inspect the state file (terraform.tfstate), you will find that it contains the administrator login and password.
Terraform Enterprise and Terraform Cloud credentials are not stored in Terraform state or the CI/CD platform. Therefore, the correct answer to your question is D. None of the above.
nswer: using environment variables
The only method list above that will not result in the username/password being written to the state file is environment variables. All of the other options will result in the provider's credentials in the state file.
Terraform runs will receive the full text of sensitive variables, and might print the value in logs and state files if the configuration pipes the value through to an output or a resource parameter. Additionally, Sentinel mocks downloaded from runs will contain the sensitive values of Terraform (but not environment) variables. Take care when writing your configurations to avoid unnecessary credential disclosure. Whenever possible, use environment variables since these cannot end up in state files or in Sentinel mocks. (Environment variables can end up in log files if TF_LOG is set to TRACE.)
Wrong.
In terraform, are environment variables stored in state file?
ChatGPT
No, environment variables are not stored in the Terraform state file. The state file contains information about resources, not configuration values. Use environment variables or other secure methods to pass sensitive information during Terraform execution.
Refer: https://developer.hashicorp.com/terraform/language/values/variables
Setting a variable as sensitive prevents Terraform from showing its value in the plan or apply output, when you use that variable elsewhere in your configuration.
Terraform will still record sensitive values in the state, and so anyone who can access the state data will have access to the sensitive values in cleartext. For more information, see Sensitive Data in State.
The answer is A. Using environment variables.
Here is an example of how to use environment variables to provide authentication credentials for an AWS provider:
provider "aws" {
region = var.aws_region
access_key_id = var.aws_access_key_id
secret_access_key = var.aws_secret_access_key
}
No, environment variables are not safe to store credentials in the state file of Terraform. Environment variables can be accessed by any process running on the same machine, including potentially malicious processes. It's important to use a secure method of storing credentials, such as using a secrets manager or key vault. Additionally, it's important to ensure that the state file itself is properly secured, either by encrypting it or by storing it in a secure location.
I think correct answer is A.
I have checked in my remote state file sitting in Azure storage account. (I used Azure DevOps environment variables) secret files are not visible in the state file.
Opt A. If you look into official terraform provider documentation, including terraform enterprise, all providers point to "Dynamic Provider Credentials". This workflow generally exposes a temporary OIDC compliment token as environment variable and authenticated by cloud providers. So I would say the straight forward answer would be environment variables.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Jayanth
Highly Voted 1 year, 5 months agogerardjongh
4 months, 3 weeks agoazizbaghirov
Most Recent 1 month, 1 week agoanand0310
3 months, 4 weeks agoRealPro111
3 months, 2 weeks agodzhang344
6 months, 1 week agoabobeida94
7 months, 3 weeks agomattuyghur
10 months, 2 weeks agoBere
11 months, 1 week agofrees
1 year agoAndreiWebNet
11 months, 1 week agoRamdi1
1 year, 1 month agoakm_1010
1 year, 4 months agoAlandt
11 months, 1 week agoAlandt
11 months, 1 week agoRajmane
1 year, 4 months agoHa_Baruh_Architect13
1 year, 5 months agoVSMu
1 year, 5 months ago[Removed]
1 year, 6 months agoJhaggar
1 year, 7 months agoOMERKENT
1 year, 7 months agozanhsieh
1 year, 7 months agozanhsieh
1 year, 7 months ago