Support for Ephemeral Values in Terraform Auth0 Provider

[schammah]

Checklist

• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

The Auth0 Terraform provider should support Terraform 1.10's ephemeral values to ensure that secrets retrieved provided in some resources are never persisted in Terraform state or plan files. This is a critical improvement for organizations that need to enforce strict security policies while managing secrets in their infrastructure.

Describe the ideal solution

The Provider Supports that
and variables can be defined with ephemeral=true without failing on errors such as:

Ephemeral values are not valid for "secrets", because it is not an assignable attribute.

Alternatives and current workarounds

No response

Additional context

No response

[duedares-rvj]

Hello @schammah
Thank you for taking the time out and report this.

Could you provide some more details around this?

1. A sample use case.
2. Any steps for reproducing this error Ephemeral values are not valid for "secrets", because it is not an assignable attribute.
3. Any one API of ours which might be returning a sensitive value back in response or storing the value in statefile.

I'd be happy to discuss this thoroughly with you and make any necessary improvements that we can agree upon :)
Thanks!

[duedares-rvj]

@schammah Hello 👋
Just catching up again on this.

[schammah]

hi @duedares-rvj
thanks for following up

my reference is about variable assigned with ephemeral=true this was introduced with 1.10
more about ephemeral resources

1. a use case would be configure a resource such as "auth0_connection`` then defining the client_secret` inside of it.

resource "auth0_connection" "okta_workforce" {
  for_each = var.okta_connections

  name           = "${each.key}-okta-workforce"
  display_name   = "${title(each.key)} Okta Workforce Connection"
  strategy       = "okta"
  show_as_button = false

  options {
    client_id              = each.value.client_id
    client_secret          = data.aws_secretsmanager_secret_version.okta_client_secret[each.key].secret_string
.......

in this case i read the secret from a data source defined as

data "aws_secretsmanager_secret_version" "okta_client_secret" {
  for_each  = var.okta_connections
  secret_id = each.value.client_secret
}

replacing this with:

ephemeral "aws_secretsmanager_secret_version" "okta_client_secret" {
  for_each  = var.okta_connections
  secret_id = each.value.client_secret
}

would break and is the answer for #2

So with data source works, but then the problem is in this case the secret is also stored in the state file, using ephemeral allow you to read secrets and apply them to the resources without them being stored in the state file, which pose a security risk.

to resolve this you would need to define fields that can be ephemeral in your provider schema

[dzmitry-kankalovich]

Having absolutely the same problem - in exactly the same place (connection resource, options section - client_id / client_secret)

It would be great to have these ephemeral values support especially for Auth0 provider of all - just by the nature of the thing people are very very likely to use secrets in TF scripts to provide configuration for connections, etc.

The original issue by me was opened in main TF repo: hashicorp/terraform#37202

[duedares-rvj]

@schammah @dzmitry-kankalovich Thank you guys for laying out the use case here.
I'm creating a task internally and shall pick this up soon.

I don't have strict timelines at this point, but expect to hear back from us soon!
Thanks!

[StephenWithPH]

@duedares-rvj ... auth0_action's secrets field would be another use case for this.

[dmunch]

auth0_client_credentials.client_secret would be another natural candidate.

As far as I can see there's currently no se secure mechanism to "ship" a client secret to some sort of vault infrastructure via Terraform. Ephemeral values and resources are made for exactly that, so having support for this in the Auth0 provider shouldn't just be a nice-to-have, but actually should have been supported from the get going for an infrastructure piece which is supposed to be central to security.

[jsmpereira]

@duedares-rvj Have you since gotten any insights on when the Auth0 provider might support write-only attributes, so that we can take advantage of ephemeral values functionality? 🙇

[LeeSaferite]

I'm currently working on cleaning up our state files to remove all sensitive values and this exact issue has come up for me as well. In my case, the auth0_client_credentials.client_secret value currently is persisted in the state file. Adding write-only argument support is what's needed. Ephemeral values and write-only arguments go hand-in-hand to solve the issue of sensitive data getting persisted in the state file. Making an argument on a resource into write-only lets it accept ephemeral values as the previous posters are wanting.

See: https://developer.hashicorp.com/terraform/language/manage-sensitive-data/write-only

Using the GCP provider's google_secret_manager_secret_version resource as an example, it still supports the persisted secret_data argument version, but it also added secret_data_wo and secret_data_wo_version to support a write-only version of the data. In the write-only scenario, secret_data_wo is never persisted and is only set/updated on the remote resource when secret_data_wo_version changes. The secret_data_wo_version argument is persisted in the state file.

[duedares-rvj]

Hello again everyone 👋
I wanted to break the silence on this and share an update.
The team has been heads-down clearing backlog and shipping several improvements that we hope have been valuable to the community; I’m sure some of that would have come to your notice. 🙇

Regarding this issue:
The main challenge we’re facing is that many of these sensitive attributes sit inside Computed blocks, which prevents their child fields from being marked as WriteOnly. Referring to the OP’s example, the options block in auth0_connection cannot support write-only fields under its current schema design.

To address this, we’re already in the process of redesigning the options schema. Instead of keeping everything bundled into a single large block, we plan to separate the attributes based on connection type. This will give us better granularity, clearer schema definitions, and more flexibility for features like WriteOnly. But I currently cannot provide specific timelines on this.

That said, we are actively identifying sensitive attributes that can support the WriteOnly tag, and we plan to introduce the corresponding _wo and _wo_version fields for those attributes. This work is already on our roadmap and part of our ongoing schema improvements.

Happy to clarify anything further.
Regards.

[duedares-rvj]

Hi everyone,

We want to update you on our progress regarding ephemeral values in the Auth0 Terraform provider.
We’ve clearly recognized the need for this functionality, and we’re actively working on it.
Starting with GitHub Issue #1402 - related to Auth0 Event Streams, we have a pull request (PR #1436) in progress that introduces a WriteOnly attribute for sensitive fields like token and password. This is our first step in ensuring that sensitive data is handled securely. Once we establish this for Event Streams, we’ll extend similar support to other sensitive fields across different Auth0 resources.

However, please note that for Auth0 connections, we won’t be supporting WriteOnly attributes immediately, as described in my previous comment.

Also, we’re moving this from a generic issue to a dedicated discussion thread so that we can gather more community input on which attributes should be marked as WriteOnly in the future. We’re excited to collaborate and refine this process based on your feedback.

Thank you for your patience and support as we continue to improve the provider!