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