Kong comes with a fairly rich plugin system, and not all available plugins are distributed the same way. Some are limited to the enterprise edition, some are contributed by the community, and many are maintained by Kong itself and included in the community edition.
As of 2018-09-30 14:33:03, the community edition included the following Kong-maintained plugins.
Built-in plugin categories in Kong
Authentication
- Basic Auth
- HMAC Auth
- JWT Auth
- Key Auth
- LDAP Auth
- OAuth 2.0 Auth
Security
- Bot Detection (crawler and bot detection)
- CORS (cross-origin requests)
- IP Restriction (IP-based access restriction)
Traffic control
- ACL (access control)
- Rate Limiting （request rate limiting）
- Request Size Limiting（request size limiting）
- Request Termination （terminate requests）
- Response Rate Limiting (response throttling)
Microservices and serverless integration
- AWS Lambda（serverless computing platform）
- Azure Functions（a serverless compute service that runs code on demand without explicitly provisioning or managing infrastructure）
- Apache OpenWhisk（an open-source, event-driven computing platform）
- Serverless Functions（serverless architecture）
Analytics and monitoring
- Datadog（captures API metrics such as request count, request size, response status, and latency, and visualizes those metrics）
- Prometheus（monitoring and alerting platform）
- Zipkin（an open-source distributed real-time tracing system used to collect monitoring data across heterogeneous systems and help track latency issues in microservice architectures）
Content transformation
- Correlation ID(uses a unique ID in HTTP headers to correlate requests and responses)
- Request Transformer（modifies the request before it is forwarded upstream）
- Response Transformer（modifies the response before the upstream response is returned to the client）
Logging
- File Log
- HTTP Log
- Loggly
- StatsD
- Syslog
- TCP Log
- UDP Log
Building your own plugin
The official development guide for Kong 0.14.x is here:
https://docs.konghq.com/0.14.x/plugin-development/
Before writing any code, Kong itself should already be installed and running. Once that is in place, the next step is locating the directory where Kong plugins live. A typical path is:
1
/usr/local/share/lua/5.1/kong/plugins/
This directory contains Kong's plugins, and your custom one should be created there as well.
Create a folder for the plugin:
1
touch /usr/local/share/lua/5.1/kong/plugins/testplugin
Then add the two required files. These are the minimum pieces of a Kong plugin:
1
handler.lua schema.lua
handler.lua contains the core plugin logic. It implements hooks that run at specific points in the request lifecycle. schema.lua defines the plugin configuration.
Defining plugin configuration
Kong uses schema.lua to declare plugin configuration. The file returns a Lua table with three properties: no_consumer, fields, and self_check.
A sample schema.lua looks like this:
1 2 3 4 5 6 7 8 9 10
return { no_consumer = true, -- this plugin will only be applied to Services or Routes, 此插件是否用于所有用户 fields = { -- Describe your plugin's configuration's schema here. 描述你的配置文件 }, self_check = function(schema, plugin_t, dao, is_updating) -- perform any custom verification 执行任何自定义的验证 return true end }
Implementing plugin logic
A Kong plugin can inject custom behavior at several stages of the request and response lifecycle. In handler.lua, you implement one or more interfaces defined by base_plugin.lua.
The main hook methods are:
<table> <thead> <tr> <th>Function</th> <th>LUA-NGINX-MODULE Context</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>:init_worker()</td> <td>init_worker_by_lua</td> <td>Runs when each Nginx worker process starts</td> </tr> <tr> <td>:certificate()</td> <td>ssl_certificate_by_lua</td> <td>Runs during the SSL certificate serving phase of the SSL handshake</td> </tr> <tr> <td>:rewrite()</td> <td>rewrite_by_lua</td> <td>Runs for each incoming request during the rewrite phase. At this point neither the API nor the consumer has been identified, so this handler only executes when the plugin is configured globally</td> </tr> <tr> <td>:access()</td> <td>access_by_lua</td> <td>Runs for every client request before it is proxied to the upstream service</td> </tr> <tr> <td>:header_filter()</td> <td>header_filter_by_lua</td> <td>Runs when all response header bytes have been received from the upstream service</td> </tr> <tr> <td>:body_filter()</td> <td>body_filter_by_lua</td> <td>Runs on each chunk of the response body received from the upstream service. Because the response is streamed back to the client and may exceed buffer size, this method can be called multiple times for large responses</td> </tr> <tr> <td>:log()</td> <td>log_by_lua</td> <td>Runs after the last response byte has been sent to the client</td> </tr> </tbody> </table>Registering the plugin in Kong
After the plugin files are ready, edit the Kong configuration file:
1
vim /etc/kong/kong.conf
Find the plugin configuration line, remove the leading comment marker, and change it to:
1
plugins = bundled, testplugin
Next, inside the testplugin directory, run:
1
luarocks write_rockspec
This generates a file named testplugin-scm-1.rockspec.
At that point, the most basic plugin layout looks like this:
1 2 3 4
testplugin/ ├── handler.lua ├── schema.lua └── testplugin-scm-1.rockspec
Restart Kong afterward:
1 2
kong stop kong start -c /etc/kong/kong.conf
Once Kong starts again, the plugin should appear in the plugin list on the admin panel at http://localhost:8080.
Logs
The default log path is:
1
/usr/local/kong/logs/error.log
If needed, the log path can also be changed in /etc/kong/kong.conf.