You are browsing documentation for an older version. See the latest documentation here.

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