You are browsing documentation for an outdated version.
See the latest documentation here.
Using decK with Kong Konnect
You can manage Kong Gateway core entity configuration in your Konnect organization using decK.
decK can only target one control plane at a time.
Managing multiple control planes requires a separate state file per control plane.
You cannot use decK to publish content to the Dev Portal, manage application registration, or configure custom plugins.
You can use
deck commands such as
--konnect flags to interact with Konnect.
If you don’t pass a Konnect flag to decK, decK looks for a local Kong Gateway instance instead.
- Address of the Konnect endpoint. (Default:
- Konnect runtime group name.
- Personal access token associated with your Konnect account (
kpat_*), or with a system account (
spat_*). This takes precedence over the
- File containing the personal access token to your Konnect account, or to a system account.
Note: Prior to decK 1.12, decK provided
deck konnect commands.
Those commands are deprecated and have been replaced with the flags in this guide.
Authenticate with Konnect
decK looks for Konnect credentials in the following order of precedence:
- Credential set with the
- decK configuration file, if one exists (default lookup path:
- Credential file passed with the
For example, if you have both a decK config file and a Konnect token file, decK uses the token in the config file.
Note: decK also includes flags to authenticate to Konnect via email and password. This is no longer supported by Konnect; instead, use a token as described below.
Authenticate using a decK config file
By default, decK looks for a configuration file named
.deck.yaml in the
This file lets you specify flags to include with every decK command.
You can create the file at the default location, or set a custom filename and path with
If you store a Konnect token in the file, decK uses the token for every command.
konnect-token-file in the decK config file.
konnect-token to store Konnect credentials directly in the configuration file:
Store your token in a separate file, then specify the path to
konnect-token-file instead of a literal token:
decK automatically uses the token from
$HOME/.deck.yaml in any subsequent calls:
Successfully Konnected to the Example-Name organization!
Authenticate using a token
You can generate a token in Konnect for authentication with decK commands.
There are two types of tokens available for Konnect:
- Personal access tokens associated with user accounts (PATs)
- System account access tokens associated with system accounts (SPATs)
Learn more about system accounts in the Konnect System Accounts documentation.
Before you generate a token, keep the following in mind:
- A token is granted all of the permissions that the user or system account has access to via their most up-to-date role assignment.
- The token has a maximum duration of 12 months.
- There is a limit of 10 personal access tokens per user.
- Unused tokens are deleted and revoked after 12 months of inactivity.
Important: The access token is only displayed once, so make sure you save it securely.
You can use the
--konnect-token flag to pass the PAT directly in the command:
deck ping \
You can save your Konnect
token to a file, then pass the filename to decK with
deck ping \
Target a Konnect API
--konnect-addr to select the API to connect to.
The default API decK uses is
https://us.api.konghq.com, which targets the
Kong Gateway supports AU, EU, and US geographic regions.
To target a specific geo, set
konnect-addr to one of the following:
- AU geo:
- EU geo:
- US geo:
Each state file targets one control plane.
If you don’t provide a control plane, decK targets the
default control plane.
If you have a custom control plane, you can specify it in the state file,
or use a flag when running any decK command.
Authentication with a Konnect token file is not working
If you have verified that your token is correct but decK can’t connect to your account, check for conflicts with the decK config file (
$HOME/.deck.yaml) and the Konnect token file.
A decK config file is likely conflicting with the token file and passing another set of credentials.
To resolve, remove one of the duplicate sets of credentials.
Workspace connection refused
When migrating from Kong Gateway to Konnect, make sure to remove any
_workspace tags. If you leave
_workspace in, you get the following error:
Error: checking if workspace exists
_workspace key to resolve this error.
You can now sync the file as-is to apply it to the default control plane or add a key to apply the configuration to a specific control plane.
To apply the configuration to custom control planes, replace
For example, to export the configuration from workspace
staging to control plane
staging, you would change:
ACL, Key Auth, or OpenID Connect plugins and app registration
You may encounter one of the following scenarios with the ACL, Key Authentication, or OpenID Connect (OIDC) plugins:
This is intentional. When you have application registration enabled, decK doesn’t manage these plugins, and doesn’t let you create duplicates of the plugin entries.
When setting up app registration, Konnect enables two plugins automatically: ACL, and either Key Authentication or OIDC, depending on your choice of authentication.
These plugins run in the background to support application registration for an API product.
They are managed entirely by Konnect, so you can’t manage these plugins directly.
Read Manage application registration for more information.
decK targets Kong Gateway instead of Konnect
decK can run against Kong Gateway or Konnect.
By default, it targets Kong Gateway, unless a setting tells decK to point to Konnect instead.
decK determines the environment using the following order of precedence:
If the declarative configuration file contains the
_konnect entry, decK runs
--kong-addr flag is set to a non-default value, decK runs against Kong Gateway.
If Konnect token is set in any way (flag, file, or decK config), decK runs against Konnect.
If none of the above are present, decK runs against Kong Gateway.