GCP secrets: please support issuing keys/tokens for static service accounts

[rvandegrift]

Feature request
I'd like a way to have vault issue keys/tokens for service accounts created outside of vault.

The GCP roleset concept is really cool, but it isn't always ideal. Some examples:

1. Sometimes I may not be able to accommodate a changing service account. For instance, the service account may need to be used in a third-party's IAM policy. Any updates to the roleset will cause vault to regenerate the service account, thus breaking the policy on the third-party's side where I cannot fix it.

2. I'd like to use vault to manage service account keys for many resources in my org, regardless of when those resources are created. But a roleset requires that the resources already exist due to Cloud IAM limitations. Thus, I'd need to trigger rotation of the service account every time someone deploys a new resource that vault should be able to grant access to. This would be tedious and difficult.

3. Vault's uniform format for Cloud IAM policy is really clever (better than anything Google offers!) but idiosyncratic. Most of our folks would prefer to manage using Google's tools or terraform. Having a uniform org-wide management of service accounts & IAM policies in terraform is a desirable goal for compliance reasons as well.

4. To manage the IAM policies on resources in a project, vault's service account needs quite a lot of access to check the current policy. Cloud IAM doesn't provide a *.getIamPolicy, so providing this access to vault can be very tedious - it either involves binding lots of roles, or managing a custom role that much change anytime Google adds a new policy controlled resource type.

Proposed solution
A GCP secrets mount should support a peer of roleset/, perhaps named static/ to support the management of access to static service accounts. vault will not create or manage the policy on the associated service account. The user is responsible for ensuring that vault has access to issue keys/tokens. This should be simple to document.

Here's an approximate API that I think could work. Assume that the GCP secret backend is mounted at gcp/ using service account [email protected].

To configure a static service account:

$ vault write gcp/static/my-application \
    [email protected]

Then, the user could request a key or token:

$ vault read gcp/static/my-application/token
$ vault read gcp/static/my-application/key

In this case, [email protected] must be added to the policy for [email protected]. It will need roles/iam.serviceAccountKeyAdmin and roles/iam.serviceAccountTokenCreator to issue keys and tokens respectively.

In most of the use-cases above, I think this is natural for the operator. For instance, if my organization is managing policy via terraform, it's clear exactly what should be updated and how.

If the required setup was missing or wrong, vault should return a 400 with the Google API error in the body. This is similar to what happens today if you try to create a roleset without vault having the required permissions.

[chrishoffman]

Can you please reopen this request in https://github.com/hashicorp/vault-plugin-secrets-gcp?

[rvandegrift]

Thanks for moving @kalafut - didn't know there was a separate repo.

Looking open issues, I believe this feature could address the use-cases in:

• Make suffix optional to SA #41
• FR: Allow option to disable key rotation on existing roleset binding updates #50

[lawliet89]

I would like to chime in that another use case is that some users might not like the idea of having Vault manage the IAM policies of a resource. In many scenarios, this would mean giving Vault the ability to manage a Project's which might not be palatable.

A similar situation exist in the AWS secrets engine but they now have support for having Vault use a "pre-created" IAM Role.