nytimes/gcp-vault

A client for securely retrieving secrets from Vault in Google Cloud infrastructure

gcpvault

gcpvault provides a function for securely retrieving secrets from HashiCorp Vault while running on the Google Cloud Platform or in your local development environment.

To use this library, users must follow the Vault instructions for enabling GCP authentication: https://www.vaultproject.io/docs/auth/gcp.html.

Under the hood, when deployed to Google Cloud this tool will use the default application credentials to login to Vault and retrieve the specified secrets.

Since the login to Vault can be a heavy and relatively slow operation, we recommend users of the legacy Google App Engine Standard Environment (Go <=1.9) call this library during start up requests for manual scaling systems or in warm up requests for users of automatic scaling to prevent exposing public traffic to such latencies.

Local Development

For local development, users should use a Github personal access tokens or some similar method to login to Vault before injecting their Vault login token into the local environment.

Unit Testing

For mocking out the services required for interacting with Vault, a gcpvaulttest package has been included to provide httptest.Servers for each dependency.

Examples

Check out the examples directory for examples on how to use this package.

Vault Token Caching

The library has an option to enable Vault Token Caching. Currently, Redis or GCS is supported for token storage. To enable token caching, one the following environment variables should set:

TOKEN_CACHE_STORAGE_REDIS - Host and port for Redis '10.200.30.4:6379'

TOKEN_CACHE_STORAGE_GCS - GCS bucket location where token can be stored for caching purposes. Care should be taken to make sure bucket permissions are set such that vault token is not leaked to the world.

Additional optional environment variables that control cache.

TOKEN_CACHE_REFRESH_THRESHOLD - How long before the token expiration should it be regenerated (in seconds). Default is 300 seconds.

TOKEN_CACHE_KEY_NAME - The object name to store. Default value is token-cache.

TOKEN_CACHE_CTX_TIMEOUT - This value is in seconds. Default value is 30 seconds.

TOKEN_CACHE_STORAGE_REDIS_DB - Database for Redis. Default is 0.

TOKEN_CACHE_REFRESH_RANDOM_OFFSET - Random refresh offset in seconds to avoid all the instances refreshing at once. Default is 1/2 the duration in seconds of the TOKEN_CACHE_REFRESH_THRESHOLD.

gcp-vault's Issues

Use berglas for securely retrieving vault host and token

Passing in the vault host/token in environment variables show in plain text in the GCP console (for cloud functions at least, I think this is true across all their products though).

It looks like there are other ways to pass in the config outside of environment variables, but have you all considered including berglas and using Google KMS + a GCS bucket for storing the encrypted host/token? It allows for easy rotation of the auth token and avoids insecure environment variables.

I tried checking out the cloud function example to see how you were handling that but I'm pretty new to golang and struggled to tell how you were dealing with it, it looked like env vars though.

I have an example of how to handle Vault with berglas in cloud functions if you haven't already decided against it, I'd be happy to share some code.

Thanks!

fyi point of optimization

since most (if not all?) gcp services are now being run within infrastructure that has a colocated metadata server, there are two things that can change here that make this faster:

1. not using the IAM server to sign JWTs but use the JWTs the metadata server can make you special for vault
2. by doing (1) you no longer need to figure out the service account email so you can skip a call to the metadata server for the email (if you've been using that)

simply doing (1) should also speed things up because it's the difference between going somewhere to get something and having it next to you.

Default Values In Docs Can Be Misleading

https://godoc.org/github.com/NYTimes/gcp-vault#Config documentation is a little misleading.

AuthPath mentions that it

// Defaults to 'auth/gcp'.

However, that's only if the client uses envconfig.Process which the docs don't mention that anywhere at all besides seeing the envconfig tags which only if you know the envconfig library, you know need to use this.

We should either mention that "defaults only work if you use envconfig" or remove the default tag and just manually write defaults.

FYI, when AuthPath is an empty string, the error that comes back is this:

unable to login to vault: unable to make login request: Error making API request

Which is unhelpful

Use Batch Tokens

This issue is made in response to the announcement of Vault Throttling.

Internal discussion, internal doc with more info.

Docs:

• Token Type Comparison
• Token Type Param

Ideally, we could make a way for gcp-vault to use batch tokens.

Transport reuse breaks VAULT_CACERT

Currently when connecting to the IAM API this library reuses the transport from the already initialized HTTP client. Is there a reason for this? This breaks connecting to the IAM API if we set VAULT_CACERT to something that does not include the google root certificate (which is usually the case).

My suggestion would just be to not reuse hc.Transport there.