Dynamic Plugin Ordering

You are browsing documentation for an older version. See the latest documentation here.

Dynamic Plugin Ordering

The order in which plugins are executed in Kong Gateway is determined by their static priority. As the name suggests, this value is static and can’t be easily changed by the user.

You can override the priority for any Kong Gateway plugin using each plugin’s ordering field. This determines plugin ordering during the access phase, and lets you create dynamic dependencies between plugins.

Concepts

Dependency tokens

Use one of the following tokens to describe a dependency to a plugin:

before: The plugin will be executed before a specified plugin or list of plugins.
after: The plugin will be executed after a specified plugin or list of plugins.

Phases

When a request is processed by Kong Gateway, it goes through various phases, depending on the configured plugins. You can influence the order in which plugins are executed for each phase.

Currently, Kong Gateway supports dynamic plugin ordering in the access phase.

API

You can use the following API to express dependencies for plugins within a certain request phase (examples are in decK-formatted YAML):

ordering:
  $dependency_token:
    $supported_phase:
      - pluginA
      - ...

For example, if you want to express that PluginA’s access phase should run before PluginB’s access phase, you would write something like this:

PluginA:
  ordering:
    before:
      access:
        - PluginB

Known limitations

Consumer scoping

Dynamic plugin ordering cannot coexist with consumer-scoped plugins, even if they are applied to entirely different service and route pairs or are running globally. If you have consumer-scoped plugins anywhere in your workspace, you can’t use dynamic plugin ordering.

Consumer mapping and dynamic plugin ordering both run in the access phase, but the order of the plugins must be determined after consumer mapping has happened. Kong Gateway can’t reliably change the order of the plugins in relation to consumer mapping.

Cascading deletes & updates

There is no support to detect if a plugin has a dependency to a deleted plugin, so handle your configuration with care.

Performance implications

Dynamic plugin ordering requires sorting plugins during a request. This naturally adds latency to the request. In some cases, this might be compensated for when you run rate limiting before an expensive authentication plugin.

Re-ordering any plugin in a workspace has performance implications to all other plugins within the same workspace. If possible, consider offloading plugin ordering to a separate workspace.

Validation

Validating dynamic plugin ordering is a non-trivial task and would require insight into the user’s business logic. Kong Gateway tries to catch basic mistakes but it can’t detect all potentially dangerous configurations.

If using dynamic ordering, manually test all configurations, and handle this feature with care.