Service Account Key TTL value missing when read from roleset config

[technologik]

This issue is to request functionality for setting a TTL on a single roleset on the GCP Secrets Backend, and not against the entire mount itself.

While rolesets with the access_token type provide credentials with a fixed interval of 1 hour, rolesets of type service_account_key create keypairs and have a variable TTL that can be set. However, this TTL must be set against the entire backend (either in the config or by tuning the mount point).

Ideally in the majority of cases, we set TTLs for these keys to be sufficiently short (ie - TTL of minutes), as they're used primarily for discrete operations like provisioning (say via TF), deployment (via CD services), init (cloud init, cronjobs, or analogous), etc. That said, we have seen quite a few one-off usecases where these discrete operations tend to be longer lived than the short TTL intervals that the majority of other deploy-time operations require, and even longer than the 1-hour interval that access_tokens are set to. In this way, we'd like individual rolesets for GCP SAs to have their own TTLs, so that we don't need to increase the lifetime of all GCP SA keys provisioned by this backend simply to support these usecases.

This would be a much better operational, management, and GitOps experience than creating N number of GCP Backends to support these usecases; we should basically only ever need 1 backend per GCP domain/org.

[sethvargo]

Like #54? That should be available and released in recent Vault versions.

[technologik]

Oh nice, I must have missed it in the changelog. Just tested it, and it looks like it's working. Keyfile from the gcp/key/foo endpoint came back with the set TTL. Awesome. Thanks for that Seth!

Couple of noteworthy comments on usability though, if I may:

• When reading the roleset config in Vault, it makes no mention of what the TTL is. I think this is notable because in a GitOps flow where we're looking to check the state of the roleset in Vault against the config in a file/source, there will always be a mismatch (making it difficult for operators to confirm the state in Vault is accurate).

Example:

Creating the Roleset

vault write gcp/roleset/my-vault-roleset \
project="my-gcp-project-123"  \
secret_type="service_account_key" \
[email protected] \
ttl=1h

Success! Data written to: gcp/roleset/my-vault-roleset

Reading the Roleset

vault read gcp/roleset/my-vault-roleset

Key                      Value
---                      -----
bindings                 map[//cloudresourcemanager.googleapis.com/projects/my-gcp-project-123:[]]
project                  my-gcp-project-123
secret_type              service_account_key
service_account_email    vaultmy-vault-roleset-1579824353@my-gcp-project-123.iam.gserviceaccount.com

I'd expect the TTL to be defined when read, so it can be in parity with the source file that would create the role. Looks like this bit of source is probably were it'd be added?

• It doesn't look like the official Vault Docs nor the API docs have been updated to reflect the TTL change. Happy to make a PR against the Vault repo to update docs and API with some examples.

[sethvargo]

Sure - PRs welcome. The reason it's not reported on out is that it's difficult to get that value if it's not set (it's inherited from a bunch of possible locations in Vault)

[technologik]

Updated the title of the issue to reflect the missing TTL value in the roleset config

[technologik]

Also Updated api docs

[zarko-a]

@sethvargo When I tried specifying service account key TTL in a roleset it doesn't seem to reflect in lease_duration.

Am I missing something? I would expect lease_duration in the below example to be equal to ttl.

vault secrets tune --default-lease-ttl=3h --max-lease-ttl=24h gcp

 vault write gcp/roleset/test-compute-admin \
> project="test-project" \
> ttl=3600 \
> secret_type="service_account_key"  \
> bindings=-<<EOF
> resource "//cloudresourcemanager.googleapis.com/projects/test-project" {
> roles = ["roles/compute.admin"]
> }
> EOF
Success! Data written to: gcp/roleset/test-project-compute-admin


vault read -format json gcp/key/test-project-compute-admin | jq '.'
{
  "request_id": "XXXX",
  "lease_id": "gcp/key/test-project-compute-admin/J1plCIv2ANZRc2OuCeN45VIh",
  "lease_duration": 10800,
  "renewable": true,
  "data": {
    "key_algorithm": "KEY_ALG_RSA_2048",
    "key_type": "TYPE_GOOGLE_CREDENTIALS_FILE",
    "private_key_data": "XXXXXXX"
  },
  "warnings": null
}