Support Service Account Impersonation

[lawliet89]

The access_token secret type should support impersonating a chain of one or more service accounts.

The impersonation can be done via:

• The service account that the secrets engine was mounted with
• Creating a new service account and making sure the operator configures the first service account in the impersonation chain to give the Vault created service account the right permission
• A pre-created service account as requested in Support for importing Service Accounts managed outside of Vault #83 and GCP secrets: please support issuing keys/tokens for static service accounts #60

[glebsts]

Note: Only users with access to the Admin APIs can access the Admin SDK Directory API, therefore your service account needs to impersonate one of those users to access the Admin SDK Directory API.

https://developers.google.com/admin-sdk/directory/v1/guides/delegation#go

So, how could I get service token while impersonating certain user account? Otherwise a) can't get access to API b) audit is usually built per impersonated account (checked with JWT access to API), so it is kinda must have.

[salrashid123]

i've implemented a variation of this FR here as a side feature of Credential Access Boundary with vault (not as part of true gcp secrets engine)

https://github.com/salrashid123/vault-plugin-secrets-gcp-cab#impersonated-token

usage is like this

vault write gcpcab/cab/config/mytotallyunrestrictedconfig  \
 project="$PROJECT_ID"  \
 target_service_account="$IMPERSONATED_SERVICE_ACCOUNT"  \
 scopes="https://www.googleapis.com/auth/cloud-platform"  \
 restricted=false \
 raw_token=true

vault policy write impersonated-policy -<<EOF
path "gcpcab/cab/certname62020" {
    capabilities = ["update", "delete"]
    allowed_parameters = {    
      "config" = ["mytotallyunrestrictedconfig"]
  }
}
EOF

# acquire impersonated token
vault token create -policy=impersonated-policy

export VAULT_TOKEN=...
vault write gcpcab/cab/certname62020 config="mytotallyunrestrictedconfig"
$ vault write gcpcab/cab/certname62020 config="mytotallyunrestrictedconfig"
Key             Value
---             -----
access_token    ya29.c.KtMCCAhvrOzXe9Yr10PAjIDEaNKn....the impersonated token

---

note, the code in that repo is not officially supported by google (its really a POC/demonstration of CAB where i threw in impersonation for good measure)

---

edit: one way to add it into vault gcp secrets maybe with a diff secret_type="impersonated_access_token" which also accepts parameters for impersonation (eg, target_service_account, lifetime, delegates, scope, etc).

the following variation of gcp secrets handles returning OIDC and JWTAccessTokens
#46 (comment)

which could be adapted with the cab impersonation thing

[salrashid123]

here's a sample POC support for impersonation on a fork of this repo

https://github.com/salrashid123/vault-plugin-secrets-gcp#impersonated

(to note, thats just alpha stage code as i've ran that w/o that much testing and its def unsupported by google as well)

[mdgreenfield]

For our case, we create the same static-account using the same GCP SA across multiple mounts/clusters. Unfortunately, because every static-account creates a new GCP SA key we quickly run into the 10 key hard quota limit. Our use case is certainly unique but I really like the idea of being able to create a static-account/roleset with secret_type=impersonated_access_token which would instruct the plugin not to create a GCP SA key and instead use the mount's configured GCP SA to create an access token.

This obviously puts an onus on the operator to ensure that GCP permissions are configured such that the plugin can impersonate a SA to create an access token but I think having this as an option to work around the 10 key limit is a great idea.

Additionally, this seems more in line with how the AWS secret plugin works for credential_type=assumed_role. The AWS plugin uses the mount's configured principal to call STS AssumeRole to retrieve credentials for the configured AWS role.

[austingebauer]

Closing this as done by #129.