search

hashicorp / terraform-provider-vault

Terraform Vault provider
https://www.terraform.io/docs/providers/vault/
Mozilla Public License 2.0
458 stars 540 forks source link

vault_gcp_secret_impersonated_account resource does not support `ttl` parameter #1812

Open itspngu opened 1 year ago

itspngu commented 1 year ago

Terraform Version

terraform -v Terraform v1.4.3-dev on linux_amd64

Affected Resource(s)

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 commented 1 year ago

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 commented 1 year ago

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

Hey there @ambis :wave:

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.