Google Cloud Secret Manager vault

You can set up a Google Cloud Secret Manager vault in one of the following ways:

The Vault entity can only be used once the database is initialized. Secrets for values that are used before the database is initialized can’t make use of the Vaults entity.

GCP Secret Manager authentication

To configure GCP Secret Manager, the GCP_SERVICE_ACCOUNT environment variable must be set to the JSON document referring to the credentials for your service account:

export GCP_SERVICE_ACCOUNT=$(cat gcp-project-c61f2411f321.json)

Kong Gateway uses the key to automatically authenticate with the GCP API and grant you access.

To use GCP Secret Manager with Workload Identity on a GKE cluster, update your pod spec so that the service account is attached to the pod. For configuration information, read the Workload Identity configuration documentation.

Notes:

  • With Workload Identity, setting the GCP_SERVICE_ACCOUNT isn’t necessary.
  • When using GCP Vault as a backend, make sure you have configured system as part of the lua_ssl_trusted_certificate configuration directive so that the SSL certificates used by the official GCP API can be trusted by Kong.

Create a Google Cloud Secret Manager vault

The following example creates a gcp Vault entity:

Vault configuration options

The following table lists the available configuration parameters for a GCP Secret Manager Vault:

Field name

Parameter format

Description

Google Project ID
  • Vault entity: vaults.config.project_id
  • kong.conf parameter: vault_gcp_project_id
  • Environment variable: KONG_VAULT_GCP_PROJECT_ID
The project ID from your Google API Console. You can find it by visiting your Google API Console and selecting “Manage all projects” in the projects list.
TTL
  • Vault entity: vaults.config.ttl
  • kong.conf parameter: vault_gcp_ttl
  • Environment variable: KONG_VAULT_GCP_TTL
Time-to-live (in seconds) for a cached secret. A value of 0 (default) disables rotation. For non-zero values, use a minimum of 60 seconds.
Negative TTL
  • Vault entity: vaults.config.neg_ttl
  • kong.conf parameter: vault_gcp_neg_ttl
  • Environment variable: KONG_VAULT_GCP_NEG_TTL
Time-to-live (in seconds) for caching failed secret lookups. A value of 0 (default) disables negative caching. Kong will retry fetching the secret after neg_ttl expires.
Resurrect TTL
  • Vault entity: vaults.config.resurrect_ttl
  • kong.conf parameter: vault_gcp_resurrect_ttl
  • Environment variable: KONG_VAULT_GCP_RESURRECT_TTL
Time (in seconds) that secrets remain in use after expiration (config.ttl ends). Useful if the vault is unreachable or the secret is deleted but not yet replaced. Kong continues to retry for resurrect_ttl seconds before giving up. The default is 1e8 seconds (~3 years) to support uninterrupted service during outages.
Base64 Decode
v3.11+
  • Vault entity: vaults.config.base64_decode
  • kong.conf parameter: vault_gcp_decode_base64
  • Environment variable: KONG_VAULT_GCP_DECODE_BASE64
Decode all secrets in this vault as base64. Useful for binary data. If some of the secrets in the vault are not base64-encoded, an error will occur when using them. We recommend creating a separate vault for base64 secrets.

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!