vault_gcp_secret_impersonated_account resource does not support ttl parameter

[itspngu]

Terraform Version

terraform -v
Terraform v1.4.3-dev
on linux_amd64

Affected Resource(s)

• vault_gcp_secret_impersonated_account

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "vault_gcp_secret_impersonated_account" "impersonated_account" {
  backend        = vault_gcp_secret_backend.gcp.path

  impersonated_account  = "this"
  service_account_email = google_service_account.this.email
  token_scopes          = ["https://www.googleapis.com/auth/cloud-platform"]
}

Debug Output

n/a

Panic Output

n/a

Expected Behavior

The vault_gcp_secret_impersonated_account resource should support the ttl parameter exposed by the corresponding Vault API endpoint.

Actual Behavior

The vault_gcp_secret_impersonated_account resource does not expose the ttl parameter.

Steps to Reproduce

n/a

Important Factoids

n/a

References

n/a

[ambis]

This would be essential especially in the case where the TTL could be configured to be less than 1h (not sure yet if this is possible), since the static_account TTL is always 1h.

This would be beneficial for places like CI which runs fast and only needs a short TTL token.

[itspngu]

This would be beneficial for places like CI which runs fast and only needs a short TTL token.

Hey there @ambis 👋

I've not tried it myself because our CI runs on Github and there's a "native" means of having workflows in Github Actions authenticate to Google Cloud called Workload Identity Federation (pretty much just a fancy wrapper around OIDC).

If that's not an option you might want to look into making the tokens returned by the auth method your CI system uses short-lived (instead of setting short TTLs on the secrets themselves), Vault will periodically clean up "dangling" secret leases (for secrets from dynamic secrets engines, for static secrets there's nothing to clean up) after the token used to create them has expired.

This could possibly be further optimized by using non-renewable Batch Tokens with a fixed TTL for the CI usecase specifically, but I've not experimented with those yet and I'm not 100% sure they properly work with dynamic secrets.