Add ephemeral resource to provider

[busser]

Related Issue

Fixes #437

Description

This PR implements an ephemeral resource that works like the existing data source. This allows running external programs without storing the result in Terraform's state, addressing concerns with sensitive data handling (closes #437).

Our use-case is running an external program that outputs credentials for use by a provider. Storing a Terraform user's credentials in a remote state backend would be a problem. Here's the code this PR allows us to write:

provider "google" {
  credentials = local.credentials
}

locals {
  credentials = jsonencode(ephemeral.external.credentials.result)
}

ephemeral "external" "credentials" {
  program = [
	# Program that fetches credentials on the user's workstation
  ]
}

The ephemeral resource's implementation is heavily copied from the data source's to ensure that the behavior is the same. Any difference would be confusing for users and a pain to document and maintain.

The ephemeral resource's tests check the same scenarios as the data source's. I've actually added a test case to the data source, that checks that the working_dir attribute works as expected.

I've run this provider on our Terraform codebase and it behaves as desired.

If you have any changes you want me to make, I am happy to make them.

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

No.

[busser]

Hey @austinvalle, sorry for the ping. Any chance you can take a look at this PR? 🙏

[busser]

Hey @austinvalle and @stephybun 👋 I'm still waiting on a response for this PR. Do you see any work needed to get this merged? I'm more than happy to make any changes you bring up :)

[busser]

Hey @austinvalle, @stephybun, and @SBGoods 👋 Sorry for the wide ping. I'm not clear on how to get this PR on the correct person's radar. Any chance you can help with that? 🙏

[busser]

It seems that maintainers' focus has shifted to the local provider. There is currently a PR open for a local_command data source that could replace the external provider in most (if not all) use cases: hashicorp/terraform-provider-local#452.

It may make more sense to implement a local_command ephemeral resource rather than an external one.

[austinvalle]

It seems that maintainers' focus has shifted to the local provider. There is currently a PR open for a local_command data source that could replace the external provider in most (if not all) use cases: hashicorp/terraform-provider-local#452.

It may make more sense to implement a local_command ephemeral resource rather than an external one.

Hey there @busser 👋🏻 , thanks for your PR! I'd intended to respond to this one once we had merged hashicorp/terraform-provider-local#452, but since you asked, I think an ephemeral resource would be a good addition!

We'd prefer the design/implementation match the proposed local_command data source in hashicorp/terraform-provider-local#452 (which is still technically a work-in progress), rather than the external data source. If you're keen to contribute that over in the local provider, I would just follow along the changes in hashicorp/terraform-provider-local#452, since the ephemeral resource should be almost a carbon copy of that 😄

Some of the differences at a high level with local_command vs. external:

• The interface/attributes have changes to essentially allow any input/output with strings, which can be parsed with decoding functions in Terraform
• The implementation is mostly similar, some removal of old workarounds we don't need to persist
• The testing doesn't use a custom Go program, we just use some of the installed software on GH actions like jq, bash, yq, etc.