Open emilymye opened 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.
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
any progress here?
Proposal
Add data-sources
vault_gcp_credentials
: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.
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