Introduction
See Secrets Management for how to register a store and reference it. This page covers theconfig object for each store type, registered under kv.stores in the configuration file for each Tyk component:
Environment Variables (env)
Reads secrets from environment variables of the Tyk component process.
The
prefix is required unless explicitly omitted using allow_no_prefix. This is a security feature to avoid references from reaching arbitrary process variables such as cloud credentials or PATH. You should always enforce a prefix unless every reference is as trusted as the host itself.
Tyk Gateway automatically registers a built-in store named
env, in addition to any store you register yourself, configured with prefix: "TYK_SECRET_" and uppercase: true. This matches the legacy $secret_env. notation, and the legacy env:// notation as used in the Target URL, Listen Path, and Gateway configuration file fields. A reference kv://env/MY_VAR (or $kv{env:MY_VAR}) therefore reads the environment variable TYK_SECRET_MY_VAR. It does not match legacy env:// used in other API definition fields, which reads the variable name exactly as written with no prefix. See Legacy Key-Value Syntax for the full breakdown before migrating an existing reference.Inline (inline)
Reads secrets from a literal key/value map in the configuration file within the store’s own config block:
Because the values sit in the configuration in plain text, this suits development, testing and values that aren’t genuinely sensitive. It’s the direct replacement for the local secrets functionality of the legacy syntax.
Local Files (file)
Reads secrets from files on the Tyk component’s filesystem, including Kubernetes Secrets mounted as files.
A reference
kv://<store>/db/password with base_path set to /etc/tyk/secrets reads the file /etc/tyk/secrets/db/password, with trailing newlines trimmed from the value. For security reasons, the keys used in references cannot be absolute paths, contain .., or resolve through a symlink to somewhere outside base_path.
This is also how a Kubernetes Secret mounted into a component’s container can be used to supply a certificate: point base_path at the mount directory and reference the mounted file by name.
HashiCorp Vault (hashicorp_vault)
Keys in references must always include the
mount_path, for example if mount_path is set to secret a reference must take the form kv://vault-prod/secret/my-app/db. A key that doesn’t sit under mount_path is rejected.
HashiCorp Consul (hashicorp_consul)
Every field is optional; an empty config connects to a Consul agent on the same host.
AWS Secrets Manager (aws_secrets_manager)
Enterprise Edition only.
profile, access_key_id/secret_access_key, role_arn and version_id are shown above only to give their field names. Each is an alternative to the field(s) next to it above, not something to combine with them.
Azure Key Vault (azure_key_vault)
Enterprise Edition only.
tenant_id through federated_token_file above are left empty because the example uses managed_identity, which needs none of them. Fill in only the fields required by whichever credential_type you choose.
GCP Secret Manager (gcp_secret_manager)
Enterprise Edition only.
quota_project_id through impersonate_delegates above are left empty because the example uses Application Default Credentials. Fill in only the fields your authentication approach needs.