Centrally-managed Consumers exist outside of a Control Plane. To create one, you must first create a realm using the Konnect API as well as a Consumer associated with the realm. Then, create a key for the centrally-managed Consumer that they can use for authentication. Enable the Key Authentication plugin, configuring identity_realms. Centrally-managed Consumers can then authenticate via key auth with their key.
This is a Konnect tutorial and requires a Konnect personal access token.
Create a new personal access token by opening the Konnect PAT page and selecting Generate Token.
Export your token to an environment variable:
export KONNECT_TOKEN='YOUR_KONNECT_PAT'
Run the quickstart script to automatically provision a Control Plane and Data Plane, and configure your environment:
curl -Ls https://get.konghq.com/quickstart | bash -s -- -k $KONNECT_TOKEN --deck-output
This sets up a Konnect Control Plane named quickstart, provisions a local Data Plane, and prints out the following environment variable exports:
export DECK_KONNECT_TOKEN=$KONNECT_TOKEN
export DECK_KONNECT_CONTROL_PLANE_NAME=quickstart
export KONNECT_CONTROL_PLANE_URL=https://us.api.konghq.com
export KONNECT_PROXY_URL='http://localhost:8000'
Copy and paste these into your terminal to configure your session.
This tutorial requires Kong Gateway Enterprise. If you don’t have Kong Gateway set up yet, you can use the quickstart script with an enterprise license to get an instance of Kong Gateway running almost instantly.
Export your license to an environment variable:
export KONG_LICENSE_DATA='LICENSE-CONTENTS-GO-HERE'
Run the quickstart script:
curl -Ls https://get.konghq.com/quickstart | bash -s -- -e KONG_LICENSE_DATA
Once Kong Gateway is ready, you will see the following message:
Kong Gateway Ready
decK is a CLI tool for managing Kong Gateway declaratively with state files. To complete this tutorial you will first need to install decK.
For this tutorial, you’ll need Kong Gateway entities, like Gateway Services and Routes, pre-configured. These entities are essential for Kong Gateway to function but installing them isn’t the focus of this guide. Follow these steps to pre-configure them:
Run the following command:
echo '
_format_version: "3.0"
services:
- name: example-service
url: http://httpbin.konghq.com/anything
routes:
- name: example-route
paths:
- "/anything"
service:
name: example-service
' | deck gateway apply -
To learn more about entities, you can read our entities documentation.
First, export your Control Plane ID and region (for example, us) so we can use it in the request. You can find these under your Control Plane settings in Gateway Manager:
export KONNECT_CONTROL_PLANE_ID={control-plane-id}
export DECK_CONTROL_PLANE_REGION={region}
Centrally-managed Consumers are assigned to realms instead of Control Planes. Realms exist outside of the Control Plane.
Use the /realms endpoint to create a realm and associate it with allowed Control Planes:
curl -X POST "https://us.api.konghq.com/v1/realms" \
-H "Authorization: Bearer $KONNECT_TOKEN" \
--json '{
"name": "prod",
"allowed_control_planes": [
"'$KONNECT_CONTROL_PLANE_ID'"
]
}'
Export the ID of the realm from the response:
export DECK_REALM_ID={realm-id}
Use the create a Consumer endpoint to create a centrally-managed Consumer:
curl -X POST "https://us.api.konghq.com/v1/realms/$DECK_REALM_ID/consumers" \
-H "Authorization: Bearer $KONNECT_TOKEN" \
--json '{
"username": "Ariel"
}'
Export the ID of the Consumer from the response:
export CONSUMER_ID={consumer-id}
Centrally-managed Consumers require a key for authentication. Configure authentication keys for Consumers using the create a key endpoint:
curl -X POST "https://us.api.konghq.com/v1/realms/$DECK_REALM_ID/consumers/$CONSUMER_ID/keys" \
-H "Authorization: Bearer $KONNECT_TOKEN" \
--json '{
"type": "new"
}'
Export the Consumer key from the secret field in the response:
export CONSUMER_KEY={consumer-key}
Consumers require authentication. Currently, you can only use the Key Auth plugin to authenticate centrally-managed Consumers. In this example, we’ll configure identity_realms on first the realm and then the Control Plane. By doing it this way, the Data Plane will first reach out to the realm. If the API key is not found in the realm, the Data Plane will look for the API key in the Control Plane config.
Enable the Key Auth plugin on the example-service:
echo '
_format_version: "3.0"
plugins:
- name: key-auth
service: example-service
config:
key_names:
- apikey
identity_realms:
- id: "${{ env "DECK_REALM_ID" }}"
scope: realm
region: "${{ env "DECK_CONTROL_PLANE_REGION" }}"
- id:
scope: cp
' | deck gateway apply -
identity_realms are scoped to the Control Plane by default (scope: cp). The order in which you configure the identity_realms dictates the priority in which the Data Plane attempts to authenticate the provided API keys. See identity realms precedence for more information.
After configuring the Key Authentication plugin, you can verify that it was configured correctly and is working, by sending requests with and without the API key you created for your centrally-managed Consumer.
Send a request with a valid API key:
curl -i "$KONNECT_PROXY_URL/anything" \
-H "apikey:$CONSUMER_KEY"
You will see a successful 200 response.
When we send the wrong API key, it won’t be authorized:
curl -i $KONNECT_PROXY_URL/anything \
-H "apikey:another_key"
This request returns a 401 error with the message Unauthorized.
If you created a new control plane and want to conserve your free trial credits or avoid unnecessary charges, delete the new control plane used in this tutorial.
When should I use centrally-managed Consumers instead of Consumers scoped to control planes?
You should use centrally-managed Consumers in the following scenarios: