Problem description
Currently, having access to the Terraform state (e.g. through an Object Storage bucket) is equivalent to having access to all the databases, service accounts, object storages, and so on that are created/configured in that Terraform state. This ends up creating a cybersecurity risk and means that the Terraform state needs to be guarded very carefully.
Proposed solution
The Terraform documentation currently suggests using ephemeral resources as a way to hide values without storing them in state.
However, the STACKIT Terraform provider does not currently support ephemeral resources for
Therefore, I propose that the STACKIT Terraform provider support ephemeral equivalents for the resources that have secret/sensitive outputs. I hope we would then be able to use those ephemeral resources to populate Secrets Manager / Vault / etc. secrets, without the sensitive values ever touching the Terraform state.
Example with a Postgres user:
ephemeral "stackit_postgresflex_user" "example_user" {
project_id = ..
instance_id = ..
username = ..
cleanup = false // disable cleaning up the ephemeral resource so that the password can remain valid after Terraform "closes" the resource
}
resource "vault_kv_secret_v2" "example_secret" {
path = ...
data_json_wo = jsonencode({
password = stackit_postgresflex_user.example_user.password // Ephemeral resources may be used in write-only properties
})
}Alternative solutions (optional)
- Encrypt state - the older approach, which just pushes the problem further away, as now you need to now just have access to the state file but to the decryption key too. However, developer machines are likely to have both, so it does not protect secrets stored in state against malware running there.
- Workload identities - remove all secrets, and instead use JWT tokens that can be validated against JWKS public keys. This seems like the future solution of all auth problems, but sadly, we aren't there yet.
Additional information
I am not convinced that this is a good solution, but I wanted to create a issue discussing just this topic in isolation. Ephemeral resource discussions for things other than short-lived access tokens have previously been scattered in #1120 (comment), #1098 (comment), and #1563.
A potential problem is that when Terraform recreates things that depend on an ephemeral resource, it would re-create the ephemeral resource. For certain resources having a duplicate resource might be "fine" (e.g. you just need to wait for an old service account keys's expiry to complete the secret rotation), for others we might get away with modifying/recreating the old resource (e.g. regenerating a Postgres user's password given its username), but anything else would leak resources (e.g. valkey credentials don't have any user-set value one might find the old credential by, nor do they have an expiration date).
Problem description
Currently, having access to the Terraform state (e.g. through an Object Storage bucket) is equivalent to having access to all the databases, service accounts, object storages, and so on that are created/configured in that Terraform state. This ends up creating a cybersecurity risk and means that the Terraform state needs to be guarded very carefully.
Proposed solution
The Terraform documentation currently suggests using ephemeral resources as a way to hide values without storing them in state.
However, the STACKIT Terraform provider does not currently support ephemeral resources for
Therefore, I propose that the STACKIT Terraform provider support ephemeral equivalents for the resources that have secret/sensitive outputs. I hope we would then be able to use those ephemeral resources to populate Secrets Manager / Vault / etc. secrets, without the sensitive values ever touching the Terraform state.
Example with a Postgres user:
Alternative solutions (optional)
Additional information
I am not convinced that this is a good solution, but I wanted to create a issue discussing just this topic in isolation. Ephemeral resource discussions for things other than short-lived access tokens have previously been scattered in #1120 (comment), #1098 (comment), and #1563.
A potential problem is that when Terraform recreates things that depend on an ephemeral resource, it would re-create the ephemeral resource. For certain resources having a duplicate resource might be "fine" (e.g. you just need to wait for an old service account keys's expiry to complete the secret rotation), for others we might get away with modifying/recreating the old resource (e.g. regenerating a Postgres user's password given its username), but anything else would leak resources (e.g. valkey credentials don't have any user-set value one might find the old credential by, nor do they have an expiration date).