Static accounts (keeping same credential)

[emilymye]

Copied from upstream issue: hashicorp/vault#6872

Is your feature request related to a problem? Please describe.
The Service Account portion of the Google Secrets Engine does not work for me. I have a cluster of jenkins worker nodes, and a bunch of jobs that request a service account from vault. The issue is that there's a limit of 10 service account keys per service account. Even with a mildly busy job, that limit is quickly reached.

I know that there are customizable TTLs for the service account keys, but with a limit of 10 keys, there isn't really a suitable TTL to choose. Let's say we have a job that can last for anywhere between 1-15 minutes. If we choose a 15 minute TTL, then running 1 job per minute would exhaust it.

I also know that you suggest using Access Tokens over service accounts. But realistically, there are many applications that must use service accounts. For example, your own Terraform Google provider requires service account authentication.

Describe the solution you'd like
There should be another option/feature in vault for service-account based Google Secrets Engine. I'd like my jobs to be able to independently request tokens from vault, and vault would give those jobs the same token, with a rotation.

For example, I set the TTL for the service account keys to 48 hours. Within a 24 hour period, 100s of jobs request that service account key, and they're all given the exact same key. After 24 hours are up, vault creates a new service account key, and starts giving that out to any jobs that request it. The previous day's service account keys automatically expire in another 24 hours.

This allows arbitrary numbers of jobs to use a service account, while also still allowing for automatic rotation.

Describe alternatives you've considered

Build a caching layer for my jenkins jobs such that all the workers pull from a centralized cache, and that centralized cache pulls 1 new token from vault every 24 hours. This seems like a lot of extra infrastructure for something so simple.
Build a sidecar to vault, that uses the key-value V2 secrets engine. Basically every 24 hours, it gets a new service account key from google, puts it as the latest KV-V2 secret value, and expires the old key after 48 hours. This is probably what I'd go with in lieu of a better solution.
Explain any additional use-cases

Additional context
If there's a better way to do this, I'd be happy to try that out!

[sethvargo]

For example, your own Terraform Google provider requires service account authentication.

That's incorrect - Terraform can accept access tokens or service accounts.

The behavior your described is exactly what tokens were designed for. If you have specific services that require service accounts instead of accepting access tokens, we should get support added to those tools.

[roobert]

@sethvargo - just to add: the major reason we're still using Vault with service accounts in our deployment pipeline is due to kubectl not supporting access tokens.

[rvdh]

@sethvargo We would also benefit from these 'static' keys. We have a number of kubernetes pods running that request a service account key on startup, they use this to access buckets for example. If we scale the deployment to over 10 pods, the new pods can't request service account keys anymore.

We also can't use access tokens, because you can't generate signed urls with them (https://googleapis.dev/python/storage/latest/blobs.html#google.cloud.storage.blob.Blob.generate_signed_url) - they require a service account private key.

I guess the primary issue here is that it's not scalable when used in kubernetes pods using the vault agent.

[jclarksnps]

@sethvargo We would also benefit from these 'static' keys. We have a number of kubernetes pods running that request a service account key on startup, they use this to access buckets for example. If we scale the deployment to over 10 pods, the new pods can't request service account keys anymore.

We also can't use access tokens, because you can't generate signed urls with them (https://googleapis.dev/python/storage/latest/blobs.html#google.cloud.storage.blob.Blob.generate_signed_url) - they require a service account private key.

I guess the primary issue here is that it's not scalable when used in kubernetes pods using the vault agent.

Why not use workload identity for your use case @rvdh, this use case is exactly what it was designed for.

[pgollangi]

Any updates on this? I have exact scenario with GitLab pipelines, where I wouldn't want new key generated for each READ of secret from vault.
@emilymye you found any workarounds to move forward?

[npvinhphat]

Same issue on this: we want to "reuse" the key instead of having a new key each generated from Vault, and manage rotation by ourselves. The only way forward is to hack something up by using key-value store to store the service account key instead, which is not ideal.

[adrianmoisey]

This would be a great feature. We're trying to roll out Vault to our business, and being able to use a service account key lowers the cost of us having to change to a different type of key