GCP Secrets Manager
- Environment variables
- Workload Identity
To configure GCP Secrets Manager, the environment variable must be set to the JSON document referring to the credentials for your service account:
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 Identity configuration documentation.
To use a GCP Secret Manager secret with the name my-secret-name
, create a JSON object in GCP that contains one or more properties:
{
"foo": "bar",
"snip": "snap"
}
{vault://gcp/my-secret-name/foo?project_id=my_project_id}
{vault://gcp/my-secret-name/snip?project_id=my_project_id}
Note that both the provider (gcp
) as well as the GCP project ID (my_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:
Once the database is initialized, a Vault entity can be created that encapsulates the provider and the GCP project ID:
Admin API
Declarative configuration
HTTPie
curl -i -X PUT http://HOSTNAME:8001/vaults/my-gcp-sm-vault \
--data name=gcp \
--data description="Storing secrets in GCP Secrets Manager" \
--data config.project_id="my_project_id"
Result:
{
"config": {
"project_id": "my_project_id"
},
"created_at": 1657874961,
"description": "Storing secrets in GCP Secrets Manager",
"prefix": "my-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: my_project_id
description: Storing secrets in GCP Secrets Manager
name: gcp
With the Vault entity in place, you can reference the GCP secrets through it: