Running into a security red flag with the Genesys Cloud Terraform provider. I’m trying to provision a new OAuth client for our analytics dashboard integration, but the genesys_cloud_oauth_client resource stores the client_secret in plaintext inside the terraform.tfstate file. That’s a no-go for our compliance team since we commit state to a remote backend that isn’t fully encrypted at rest yet.
I tried using the sensitive = true argument on the output, but that only masks it in the CLI console. It still sits there in the JSON state file waiting for anyone with read access to the backend bucket to pull. I’ve looked at the provider docs and the source code on GitHub, but I don’t see a built-in way to handle secret rotation or exclusion for this specific resource type.
Here’s the snippet I’m working with:
resource "genesys_cloud_oauth_client" "analytics_client" {
name = "Analytics Dashboard Client"
description = "Used for internal reporting tools"
grant_types = ["client_credentials"]
redirect_uris = ["https://internal-dashboard.company.com/callback"]
}
# This exposes the secret in state
output "oauth_secret" {
value = genesys_cloud_oauth_client.analytics_client.client_secret
sensitive = true
}
Is there a workaround? I was thinking of generating the secret via a random_password resource and then updating the client via the API directly after Terraform applies, but that feels messy and breaks the declarative model. Or should I just ignore the state file exposure and rely on backend encryption? We’re on the US/Eastern region, standard enterprise org. The terraform apply works fine, it’s just the state persistence that’s the issue. I need to know if there’s a pattern for this that doesn’t involve storing secrets in the state file entirely. The provider version is 1.54.0. Any ideas on how to handle this without compromising the IaC workflow?