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

[FR] Create direct datasource for reading from GCP secrets #352

Open emilymye opened 5 years ago

emilymye commented 5 years ago

Proposal

Add data-sources vault_gcp_credentials:

Outputs:
${vault_gcp_credentials.token_creds.token}
${vault_gcp_credentials.key_creds.key}
# single data sources
data "vault_gcp_credentials" "token_creds" {
  backend = "${vault_gcp_secret_backend.gcp.path}"
  roleset    = "my-role"
  type = "token"
  scopes = [ "https://www.googleapis.com/auth/cloud-platform" ]
}

data "vault_gcp_credentials" "key_creds" {
  backend = "${vault_gcp_secret_backend.gcp.path}"
  roleset    = "my-role"
  type = "key"
  ttl = "3600s"
}

or multiple datasources, i'd prefer this because a lot of the arguments ended up not overlapping - for example, access token doesn't allow for TTL and requires scopes, vise versa for key.

data "vault_gcp_token_credentials" "creds" {
  backend = "${vault_gcp_secret_backend.gcp.path}"
  roleset   = "my-role"
  scopes = [ "https://www.googleapis.com/auth/cloud-platform" ]
}

data "vault_gcp_token_credentials" "creds" {
  backend = "${vault_gcp_secret_backend.gcp.path}"
  roleset    = "my-role"
  ttl       = 3600s
}

Background

Not sure if the Vault provider has just decided to default to the generic_secrets datasource, but someone has asked why there is an AWS credentials endpoint and not a GCP endpoint. I'm just posting this for reference/to get feedback, since I'm looking into doing this and #253.

Cross-post https://github.com/hashicorp/vault-plugin-secrets-gcp/issues/32

cvbarros commented 5 years ago

@emilymye This is just my opinion here - as contributor. I think there's no value in settling for generic_secrets for this provider, or a "catch all resource" for any other provider. Or else, Terraform becomes just a "fancy curl". It is known that generic secrets can close in that gap from proper resources until they are available, but native resources are a way better abstraction for end users dealing with the provider.

In that sense, there is still no support for the GCP secret engine as there is for AWS. I'd say go for it as it will greatly benefit the project as whole to support GCP secret engine.

husunal commented 3 years ago

Having vault_gcp_token_credentials data resource would be great, generic_secrets data resource doesn't allow to specify the TTL value for service account keys https://www.vaultproject.io/api/secret/gcp#generate-secret-iam-service-account-creds-service-account-key @emilymye

wagnst commented 2 years ago

any progress here?