Terraform state file exposing OAuth secrets despite sensitive flag

General Discussion
1

I’m using the Genesys Cloud Terraform provider to manage OAuth applications. The docs say to mark the client_secret as sensitive, but it’s still writing to the state file in plain text. Here’s the block:

resource "genesyscloud_oauth_client" "this" {
 name = "test-client"
 client_secret = var.oauth_secret
}

I’ve tried adding sensitive = true to the variable and using terraform.tfvars, but the state file still has the secret. Is there a way to encrypt it or skip writing it entirely?

2

Yeah, I’ve burned myself on this exact issue a few times. The sensitive flag in Terraform variables only stops the value from showing up in the CLI output during apply or plan. It doesn’t actually encrypt the state file. By default, the state file is just plain JSON, so if anyone has access to it, they can see the secret.

You need to encrypt the state file itself or use a backend that handles encryption at rest. If you’re storing the state in a local file, you’re pretty much out of luck for security unless you manually encrypt it (which is a pain). The standard fix is to switch to a remote backend like S3 with server-side encryption enabled.

Here’s what the backend config looks like for AWS S3. Make sure encrypt is set to true.

terraform {
 backend "s3" {
 bucket = "my-terraform-state-bucket"
 key = "genesys-cloud/terraform.tfstate"
 region = "us-west-2"
 encrypt = true
 dynamodb_table = "terraform-locks"
 }
}

Also, double-check your IAM policies. The user running the Terraform commands needs s3:PutObject and s3:GetObject permissions on that bucket, plus dynamodb:PutItem and dynamodb:GetItem for the lock table. If you skip the DynamoDB table, you might get race conditions if two people run apply at the same time, which is a nightmare to debug.

Another option is using the remote backend from HashiCorp, which handles encryption for you, but you have to pay for it. For most teams, S3 with encryption is the way to go. Just make sure you restrict access to that S3 bucket strictly. You don’t want just anyone in your org pulling down the state file.

If you’re already using a remote backend and it’s still showing up, check if you’re using an old provider version. The Genesys Cloud provider has improved how it handles sensitive fields in recent updates. Run terraform init -upgrade to make sure you’re on the latest.

One thing to watch out for is that if you’ve already committed the state file to git before switching to a remote backend, that secret is already out there. You’ll need to rotate that OAuth secret immediately. It’s a bad feeling, but it happens.

3

Cause: The sensitive flag only masks CLI output. It doesn’t encrypt the state file.
Solution: Use a remote backend with encryption at rest, like S3 with SSE-KMS or Terraform Cloud.