Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service Account Token - Ephemeral Resource support #1946

Open
0x006EA1E5 opened this issue Dec 9, 2024 · 0 comments
Open

Service Account Token - Ephemeral Resource support #1946

0x006EA1E5 opened this issue Dec 9, 2024 · 0 comments

Comments

@0x006EA1E5
Copy link

Feature Request

The recently released Terraform 1.10 has added support for "Ephemeral Resources".

Such Ephemeral Resources are designed for resources such as secrets which the user dosen't want to store in the terraform state, but instead are provisioned ad-hoc during plan and apply phases.

Ephemeral resource support must be added to a provider; it is not something that simply becomes available for regular resources once upgraded to Terraform 1.10.

This feature request is for ephemeral resource support to be added to the following Grafana resources

  • grafana_cloud_stack_service_account_token
  • grafana_service_account_token

Concrete Use-case

It is hoped that this feature will be especially for the use case where a user has an appropriate Cloud Access Policy Token, and intends to configure a stack's resources which require a Service Account.

There is a somewhat-difficult-to-explain problem that can occur when you try to both provision a service account token, and then use that token to provision resources in a stack (alerts, dashboards etc) in a single Terraform, and if the token expires.

The initial plan / apply works fine: TF knows there are no resources in it's state, so can simply plan to create all of them.

So the first apply goes:

  1. Create a service account with the Cloud Access Policy Token
  2. Create a service account token with the Cloud Access Policy Token
  3. Use the service account token in a Grafana provider alias
  4. Use the Grafana provider alias to provision some resources

This works.

Later, we want to do anther plan / apply:

(we need to do "pre-apply plan" first, so TF knows what to apply)

  1. Check we have the service account with the Cloud Access Policy Token
  2. Check we have the service account Token with the Cloud Access Policy Token
  3. Use the service account token stored in the TF state in the Grafana provider alias
  4. Use the Grafana provider alias to check the required resources

Only after this "pre-apply plan" is done, can TF know what it needs to apply

This "pre-apply plan" requires the service account token stored in the TF state to be valid. This will not work if the token has expired.

We get into a chicken-and-egg situation here: We need a token to do the plan, but we won't have a valid token until we do an apply to refresh it, but we can't do an apply until we have done a plan to see if the local TF state matches the remote infra...

Workarounds

We can escape the above problem a few ways:

  • Provision the service account/token in another terraform; use the token as an output and then build the stack's resources in another terraform
  • Do a "partial apply" of the TF, only for the sepcific token resources. Do this before doing the "full apply" to ensure you have a valid token

How will this FR help?

As the token is generated ad-hoc in each phase, then the token should get generated at the beginning of the plan phase, before TF tries to check the remote infra which uses it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant