Get Started with Dynamic Plugin Ordering
Here are some common use cases for dynamic plugin ordering.
Rate limiting before authentication
Let’s say you want to limit the amount of requests against your service and route before Kong requests authentication. You can describe this dependency with the token before
.
The following example uses the Rate Limiting Advanced plugin with the Key Authentication plugin as the authentication method.
Admin API
Kubernetes
decK (YAML)
Call the Admin API on port 8001
and enable the rate-limiting
plugin, configuring it to run before key-auth
:
cURL
HTTPie
curl -i -X POST http://<admin-hostname>:8001/plugins \
--data name=rate-limiting \
--data config.minute=5 \
--data config.policy=local \
--data config.limit_by=ip \
--data ordering.before.access=key-auth
http -f post :8001/plugins \
name=rate-limiting \
config.minute=5 \
config.policy=local \
config.limit_by=ip \
ordering.before.access=key-auth
apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
name: limit-before-key-auth
labels:
global: "true"
annotations:
kubernetes.io/ingress.class: "kong"
config:
minute: 5
policy: local
limit_by: ip
plugin: rate-limiting
ordering:
before:
access:
- key-auth
Add a new
plugins
section to the bottom of yourkong.yaml
file. Enablerate-limiting
and set the plugin to run beforekey-auth
:plugins:
- name: rate-limiting
config:
minute: 5
policy: local
limit_by: ip
ordering:
before:
access:
- key-auth
Your file should now look like this:
_format_version: "3.0"
services:
- host: mockbin.org
name: example_service
port: 80
protocol: http
routes:
- name: mocking
paths:
- /mock
strip_path: true
plugins:
- name: rate-limiting
config:
minute: 5
policy: local
limit_by: ip
ordering:
before:
access:
- key-auth
This plugin will be applied globally, which means the rate limiting applies to all requests, including every Service and Route in the Workspace.
If you pasted the plugin section under an existing Service, Route, or Consumer, the rate limiting would only apply to that specific entity.
Note: By default,
enabled
is set totrue
for the plugin. You can disable the plugin at any time by settingenabled: false
.Sync the configuration:
deck sync
Authentication after request transformation
The following example is similar to running rate limiting before authentication.
For example, you may want to first transform a request, then request authentication after transformation. You can describe this dependency with the token after
.
Instead of changing the order of the Request Transformer plugin, you can change the order of the authentication plugin (Basic Authentication, in this example).
Admin API
Kubernetes
decK (YAML)
Call the Admin API on port 8001
and enable the basic-auth
plugin, configuring it to run after request-transformer
:
cURL
HTTPie
curl -i -X POST http://<admin-hostname>:8001/plugins \
--data name=basic-auth \
--data ordering.after.access=request-transformer
http -f post :8001/plugins \
name=basic-auth \
ordering.after.access=request-transformer
apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
name: auth-after-transform
labels:
global: "true"
annotations:
kubernetes.io/ingress.class: "kong"
plugin: basic-auth
ordering:
after:
access:
- request-transformer
Add a new
plugins
section to the bottom of yourkong.yaml
file. Enablebasic-auth
and set the plugin to run afterrequest-transformer
:plugins:
- name: basic-auth
config: {}
ordering:
after:
access:
- request-transformer
Your file should now look like this:
_format_version: "3.0"
services:
- host: mockbin.org
name: example_service
port: 80
protocol: http
routes:
- name: mocking
paths:
- /mock
strip_path: true
plugins:
- name: basic-auth
config: {}
ordering:
after:
access:
- request-transformer
Note: By default,
enabled
is set totrue
for the plugin. You can disable the plugin at any time by settingenabled: false
.Sync the configuration:
deck sync