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:

Common options: