Vaults

Uses: Kong Gateway Admin API decK KIC Konnect API Terraform

What is a Vault?

Vaults allow you to securely store and then reference secrets from within other entities. This ensures that secrets aren’t visible in plaintext throughout the platform, in places such as kong.conf, declarative configuration files, logs, or the UI.

For example, you could store a certificate and a key in a Vault, then reference them from a Certificate entity. This way, the certificate and key are not stored in the entity directly and are more secure.

How do I add secrets to a Vault?

You can add secrets to Vaults in one of the following ways:

  • Environment variables
  • Konnect Config Store
  • Supported third-party backend vault

What can be stored as a secret?

You can store and reference the following as secrets in a Vault:

Konnect Config Store limitations:

  • 1: You can’t reference secrets stored in a Konnect Config Store Vault in kong.conf because Konnect resolves the secret after Kong Gateway connects to the Control Plane. For this same reason, you can’t use Konnect Config Store secrets directly in Lua code via the Kong PDK, for example.
  • 2: In Konnect, the Kong Gateway license is managed and stored by Konnect, and doesn’t need to be stored manually in any Vault.

Referenceable plugin fields

The following plugin fields can be stored and referenced as secrets:

Supported Vault backends

Each vault has its own required configuration. You can provide this configuration by creating a Vault entity, or by configuring specific environment variables before starting Kong Gateway.

For more information, choose a Vault below to see the specific configuration required.

Backend Kong Gateway OSS Kong Gateway Enterprise Konnect supported
Environment variable
Konnect Config Store
AWS Secrets Manager
Azure Key Vaults
Google Cloud Secret
HashiCorp Vault

How do I reference secrets stored in a Vault?

When you want to use a secret stored in a Vault, you can reference the secret with a vault reference. You can use the vault reference in places such as kong.conf, declarative configuration files, logs, or in the UI.

The Vault backend may store multiple related secrets inside an object, but the reference should always point to a key that resolves to a string value. For example, the following reference:

{vault://hcv/pg/username}

Would point to a secret object called pg inside a HashiCorp Vault, which may return the following value:

{
  "username": "john",
  "password": "doe"
}

Kong Gateway receives the payload and extracts the "username" value of "john" for the secret reference of {vault://hcv/pg/username}.

Vault references must be used for the whole referenced value. Imagine that you’re calling a upstream service with the authentication token ABC123:

Works Configuration Value Vault Value
Bearer {vault://hcv/myservice-auth-token} ABC123
{vault://hcv/myservice-auth-token} Bearer ABC123

Secret rotation in Vaults

By default, Kong Gateway automatically refreshes secrets once every minute in the background. You can also configure how often Kong Gateway refreshes secrets using the Vault entity configuration.

There are two types of refresh configuration available:

  • Refresh periodically using TTLs: For example, check for a new TLS certificate once per day.
  • Refresh on failure: For example, on a database authentication failure, check if the secrets were updated, and try again.

For more information, see Secret management.

Schema

The Vault entity can only be used once the database is initialized. Secrets for values that are used before the database is initialized can’t make use of the Vaults entity.

Vault provider-specific configuration parameters

When you set up a Vault, each provider has specific parameters that you can or must configure to integrate the Vault entity with a provider.

Set up a Vault

Store secrets as environment variables

You can store secrets as environment variables instead of configuring a Vault entity or third-party backend vault.

Use case

Environment variable example

Secret reference example

Single secret value export MY_SECRET_VALUE=example-secret {vault://env/my-secret-value}
Multiple secrets (flat JSON string) export PG_CREDS='{"username":"user", "password":"pass"}' {vault://env/pg-creds/username}

{vault://env/pg-creds/password}

FAQs

Vaults work with “referenceable” fields. All fields in kong.conf are referenceable and some fields within entities (for example, plugins, certificates) are also. Refer to the appropriate entity documentation to learn more.

Yes. The plugin development kit (PDK) offers a Vaults module (kong.vault) that can be used to resolve, parse, and verify Vault references.

A secret reference points to a string value. No other data types are currently supported.

If you have a secret with multiple versions, you can access the current version or any previous version of the secret by specifying a version in the reference.

In the following AWS example, AWSCURRENT refers to the latest secret version and AWSPREVIOUS refers to an older version:

# For AWSCURRENT, not specifying version
{vault://aws/secret-name/foo}

# For AWSCURRENT, specifying version == 1
{vault://aws/secret-name/foo#1}

# For AWSPREVIOUS, specifying version == 2
{vault://aws/secret-name/foo#2}

This applies to all providers with versioned secrets.

The slash symbol (/) is a valid character for the secret name in AWS Secrets Manager. If you want to reference a secret name that starts with a slash or has two consecutive slashes, transform one of the slashes in the name into URL-encoded format. For example:

  • A secret named /secret/key should be referenced as {vault://aws/%2Fsecret/key}
  • A secret named secret/path//aaa/key should be referenced as {vault://aws/secret/path/%2Faaa/key}

Since Kong Gateway tries to resolve the secret reference as a valid URL, using a slash instead of a URL-encoded slash will result in unexpected secret name fetching.

You can create multiple Vault entities, one per region with the config.region parameter. You’d then reference the secret by the name of the Vault:

{vault://aws-eu-central-vault/secret-name/foo}
{vault://aws-us-west-vault/secret-name/snip}

To use GCP Secret Manager with Workload Identity on a GKE cluster, update your pod spec so that the service account (GCP_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 Gateway.

Kong Gateway retrieves secrets from HashiCorp Vault’s HTTP API through a two-step process: authentication and secret retrieval.

Step 1: Authentication

Depending on the authentication method defined in config.auth_method, Kong Gateway authenticates to HashiCorp Vault using one of the following methods:

  • If you’re using the token auth method, Kong Gateway uses the config.token as the client token.
  • If you’re using the kubernetes auth method, Kong Gateway uses the service account JWT token mounted in the pod (path defined in the config.kube_api_token_file) to call the login API for the Kubernetes auth path on the HashiCorp Vault server and retrieve a client token.
  • v3.4+ If you’re using the approle auth method, Kong Gateway uses the AppRole credentials to retrieve a client token. The AppRole role ID is configured by field config.approle_role_id, and the secret ID is configured by field config.approle_secret_id or config.approle_secret_id_file.
    • If you set config.approle_response_wrapping to true, then the secret ID configured by config.approle_secret_id or config.approle_secret_id_file will be a response wrapping token, and Kong Gateway will call the unwrap API /v1/sys/wrapping/unwrap to unwrap the response wrapping token to fetch the real secret ID. Kong Gateway will use the AppRole role ID and secret ID to call the login API for the AppRole auth path on the HashiCorp Vault server and retrieve a client token.

By calling the login API, Kong Gateway will retrieve a client token and then use it in the next step as the value of X-Vault-Token header to retrieve a secret.

Step 2: Retrieving the secret

Kong Gateway uses the client token retrieved in the authentication step to call the Read Secret API and retrieve the secret value. The request varies depending on the secrets engine version you’re using. Kong Gateway will parse the response of the read secret API automatically and return the secret value.

Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!