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:

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:

{
  "foo": "bar",
  "snip": "snap"
}

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

{vault://gcp/secret-name/foo?project_id=project_id}
{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:

export KONG_VAULT_GCP_PROJECT_ID=project_id

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

{vault://gcp/secret-name/foo}
{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

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

Result:

{
    "config": {
        "project_id": "project_id"
    },
    "created_at": 1657874961,
    "description": "Storing secrets in GCP Secret Manager",
    "id": "90e200be-cf84-4ce9-a1d6-a41c75c79f31",
    "name": "gcp",
    "prefix": "gcp-sm-vault",
    "tags": null,
    "updated_at": 1657874961
}

Secrets management is supported in decK 1.16 and later.

Add the following snippet to your declarative configuration file:

_format_version: "3.0"
vaults:
- config:
    project_id: project_id
  description: Storing secrets in GCP Secret Manager
  name: gcp
  prefix: gcp-sm-vault

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

{vault://gcp-sm-vault/secret-name/foo}
{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:

Parameter	Field name	Description
`vaults.config.project_id`	Google Project ID	The 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.ttl`	TTL	Time-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_ttl`	Negative TTL	Time-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_ttl`	Resurrect TTL	Time (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:

Parameter	Field name	Description
`vaults.description` optional	Description	An optional description for your vault.
`vaults.name`	Name	The type of vault. Accepts one of: `env`, `gcp`, `aws`, or `hcv`. Set `gcp` for GCP Secret Manager.
`vaults.prefix`	Prefix	The reference prefix. You need this prefix to access secrets stored in this vault. For example, `{vault://gcp-sm-vault/<some-secret>}`.