Support `STACKIT_SERVICE_ACCOUNT_KEY` Environment Variable

[rswrz]

Description

Currently, authentication with the Terraform provider can be configured using:

1. The service_account_key parameter, which requires passing the service account key directly.
2. The service_account_key_path parameter, which points to a file containing the key.

Additionally, authentication can be set using the environment variable STACKIT_SERVICE_ACCOUNT_KEY_PATH.

Requested Feature

This feature request proposes supporting the environment variable STACKIT_SERVICE_ACCOUNT_KEY as an alternative to the service_account_key provider configuration property.

Use Case

Allowing authentication via STACKIT_SERVICE_ACCOUNT_KEY would simplify CI/CD workflows, particularly in GitHub Actions (and likely other CI/CD environments).

Currently, storing the service account key in a GitHub Secret requires workarounds, such as:

1. Writing the secret to a temporary file and setting STACKIT_SERVICE_ACCOUNT_KEY_PATH.
2. Using a custom Terraform variable (stackit_service_account_key) and passing it via the TF_VAR_stackit_service_account_key environment variable.

By supporting STACKIT_SERVICE_ACCOUNT_KEY, we could eliminate the need for these workarounds, allowing direct authentication using a GitHub Secret.

Current Workaround

variable "stackit_service_account_key" {
  type      = string
  sensitive = true
}

provider "stackit" {
  service_account_key = var.stackit_service_account_key
}

[rswrz]

The same applies to the private_key property. I propose allowing it to be set via the environment variable STACKIT_PRIVATE_KEY.

[bahkauv70]

Hello @rswrz , thanks for your feature request! Could please clarify for us, why using the standard terraform way of passing an environment variable does not work for you?

[rswrz]

@bahkauv70, it does work! It's indeed a great workaround. 🙂

However, I believe it would be a valuable enhancement for this Terraform provider to natively support service_account_key via an environment variable — just like you already do with service_account_key_path and STACKIT_SERVICE_ACCOUNT_KEY_PATH.

This approach aligns with best practices followed by other major Terraform providers, such as azurerm, which allows authentication using environment variables like ARM_CLIENT_ID and ARM_CLIENT_SECRET as an alternative to defining them in the provider configuration.

[bahkauv70]

Ok, thanks for the clarification. We will have to discuss this internally and will get back to you

[mardonner]

Hey, any update on this? I'm also interested in this feature.

Adding my two cents:
This is of course a convenience feature and kind of a debate about taste. I'm trying to further elaborate on this based on my understanding of @rswrz arguments.

The need for this comes from the combination of these circumstances:

1. Wanting to use key flow, which is recommended by the docs
2. Wanting to keep the terraform provider config agnostic to the used authentication method. So controlling this via environment variable (either key env var or token env vars)
3. Not wanting to store or write the key as a file during a pipeline run and not wanting to use a TF_VAR_* environment variable.

Point 3 is the actual reason for the need of support of a STACKIT_SERVICE_ACCOUNT_KEY environment variable.

Why not use a TF_VAR_* environment variable?
Again, circumstance no.2 and the general expectation that provider authentication can usually be done by using non TF_VAR_* environment variables.

Why not use the STACKIT_SERVICE_ACCOUNT_KEY_PATH env var and store the key in a file?
The desire for this comes from the gut feeling of "You shouldn't write secrets to a file. Secrets should be stored in environment variables." Now, since the terraform code usually runs inside a pipeline writing to a file it is probably ok to do if the runner/agent environment is properly cleaned up or deleted after the pipeline finished. This is usually the case, especially if the pipeline task are executed inside a container already. This environment is kind of a trusted zone, so you could also see this as a non-argument.

We could also use a consistency argument. If STACKIT_SERVICE_ACCOUNT_TOKEN exists for the token flow, why should STACKIT_SERVICE_ACCOUNT_KEY not exist for the key flow? We could also say, why not also support supplying a file when using he token flow?

Again, I don't have any arguments of substance besides this one about convenience and taste.
Hope this provides further context.

[marceljk]

Hey,
it is already possible to use the env STACKIT_SERVICE_ACCOUNT_KEY and as well optional STACKIT_PRIVATE_KEY. I created a small PR #883 to update the README.

It's important that the content in the envs are correctly formatted, otherwise the authentication fails. In the PR description, I added a small test and show how it works.

With these envs, it isn't required to have the service account key stored in a file within pipelines and build some workarounds.

[mardonner]

Ah, should've checked the sdk repo...
thx for the hint