GCP Secret Manager

The current version of Kong Gateway’s implementation supports configuring GCP Secret Manager in two ways:

  • Environment variables
  • Workload Identity

Configure GCP Secret Manager

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:

  1. 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.

Examples

To use a GCP Secret Manager secret with the name secret-name, create a JSON object in GCP that contains one or more properties:

  1. {
  2. "foo": "bar",
  3. "snip": "snap"
  4. }

You can now reference the secret’s individual resources like this:

  1. {vault://gcp/secret-name/foo?project_id=project_id}
  2. {vault://gcp/secret-name/snip?project_id=project_id}

Note that both the provider (gcp) as well as the GCP project ID (project_id) need to be specified. You can configure the project ID with an environment variable before starting Kong Gateway:

  1. export KONG_VAULT_GCP_PROJECT_ID=project_id

Then you don’t need to repeat it in references:

  1. {vault://gcp/secret-name/foo}
  2. {vault://gcp/secret-name/snip}

Configuration via vaults entity

Once the database is initialized, a Vault entity can be created that encapsulates the provider and the GCP project ID:

Admin API

Declarative configuration

  1. curl -i -X PUT http://HOSTNAME:8001/vaults/gcp-sm-vault \
  2. --data name=gcp \
  3. --data description="Storing secrets in GCP Secret Manager" \
  4. --data config.project_id="project_id"

Result:

  1. {
  2. "config": {
  3. "project_id": "project_id"
  4. },
  5. "created_at": 1657874961,
  6. "description": "Storing secrets in GCP Secret Manager",
  7. "id": "90e200be-cf84-4ce9-a1d6-a41c75c79f31",
  8. "name": "gcp",
  9. "prefix": "gcp-sm-vault",
  10. "tags": null,
  11. "updated_at": 1657874961
  12. }

Secrets management is supported in decK 1.16 and later.

Add the following snippet to your declarative configuration file:

  1. _format_version: "3.0"
  2. vaults:
  3. - config:
  4. project_id: project_id
  5. description: Storing secrets in GCP Secret Manager
  6. name: gcp
  7. prefix: gcp-sm-vault

With the Vault entity in place, you can reference the GCP secrets through it:

  1. {vault://gcp-sm-vault/secret-name/foo}
  2. {vault://gcp-sm-vault/secret-name/snip}

Vault entity configuration options

Use the following configuration options to configure the vaults entity through any of the supported tools:

  • Admin API
  • Declarative configuration
  • Kong Manager
  • Konnect

Configuration options for a GCP Secret Manager vault in Kong Gateway:

ParameterField nameDescription
vaults.config.project_idGoogle Project IDThe project ID from your Google API Console. Visit your Google API Console and select Manage all projects in the projects list to see your project ID.
vaults.config.ttlTTLTime-to-live (in seconds) of a secret from the vault when it’s cached. The special value of 0 means “no rotation” and it’s the default. When using non-zero values, it is recommended that they’re at least 1 minute.
vaults.config.neg_ttlNegative TTLTime-to-live (in seconds) of a vault miss (no secret). Negatively cached secrets will remain valid until neg_ttl is reached, after which Kong will attempt to refresh the secret again. The default value for neg_ttl is 0, meaning no negative caching occurs.
vaults.config.resurrect_ttlResurrect TTLTime (in seconds) for how long secrets will remain in use after they are expired (config.ttl is over). This is useful when a vault becomes unreachable, or when a secret is deleted from the Vault and isn’t replaced immediately. On this both cases, the Gateway will keep trying to refresh the secret for resurrect_ttl seconds. After that, it will stop trying to refresh. We recommend assigning a sufficiently high value to this configuration option to ensure a seamless transition in case there are unexpected issues with the Vault. The default value for resurrect_ttl is 1e8 seconds, which is about 3 years.

Common options:

ParameterField nameDescription
vaults.description
optional
DescriptionAn optional description for your vault.
vaults.nameNameThe type of vault. Accepts one of: env, gcp, aws, or hcv. Set gcp for GCP Secret Manager.
vaults.prefixPrefixThe reference prefix. You need this prefix to access secrets stored in this vault. For example, {vault://gcp-sm-vault/<some-secret>}.