GCP Secrets Manager
The current version of Kong Gateway’s implementation supports
GCP Secrets Manager in two
- Environment variables
- Workload Identity
Configure GCP Secrets Manager
To configure GCP Secrets Manager, the
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 Secrets Manager with
on a GKE cluster, update your pod spec so that the service account is
attached to the pod. For configuration information, read the Workload
- 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.
To use a GCP Secret Manager
with the name
secret-name, create a JSON object in GCP that
contains one or more properties:
You can now reference the secret’s individual resources like this:
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:
Then you don’t need to repeat it in references:
Configuration via vaults entity
Once the database is initialized, a Vault entity can be created
that encapsulates the provider and the GCP project ID:
With the Vault entity in place, you can reference the GCP secrets
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
Configuration options for a GCP Secrets Manager vault in Kong Gateway:
|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.
|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.
|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.
|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.
|An optional description for your vault.
|The type of vault. Accepts one of:
gcp for GCP Secrets Manager.
|The reference prefix. You need this prefix to access secrets stored in this vault. For example,