We had made a topic in the past regarding our Upstream JWT plugin, but now as we plan to release plenty of plugins into the wild we figured it would be appropriate to make one topic to expose them all! We intend to edit this topic and update with every release we make.
Without further adieu, lets begin:
Kong OIDC Auth - Provides authentication against IDPs following conventional OIDC methodology!
Side-note: We would love community feedback/PRs against this one ^. It is our first time implementing OIDC and the quirks we found working with SPA apps that need to use OIDC. I am sure there is room for improvement .
Kong Spec Expose - Provides API service provider spec/contract exposure on proxies protected by auth!
Kong Splunk Log - Provides HTTP collector logging in a Splunk consumable format!
Upstream JWT Plugin - Provides AAA for API providers validating transactions from Kong!
Path Based Routing Plugin - A plugin for Kong which dynamically sets the upstream hostname at runtime, based on the request URI path.
As a continuation of our dedication to release helpful tools and plugins/scripts to the community behold our latest additions to the Optum GitHub!
Kong Service Virtualization Plugin
This plugin can help you mock API request and response data before your service is actually available using just the Kong API Gateway!
Kong Expired Token Cleanup (For Cassandra Database)
This will help keep your Cassandra OAuth2 table clean of old expired tokens as well as keep you in the loop when consumers are not behaving properly and caching their generated OAuth2 tokens!
Kong Cluster Drain Plugin
A Plugin that enables the ability for an admin to induce failed health checks against their load-balancers fronting Kong. This can be helpful when you would like to divert traffic away from a given data center without actually taking down your lb (which would hurt active connections at that moment in time). This way you can divert traffic first, and then take your lb down safely as you begin specific cluster work! We are currently using an environment variable we define based on the Splunk plugin in this thread as well, but you can fork it and name your specific environment variable you intend to use separately if you do not want to declare a SPLUNK_HOST .
-Edit, does not look like I can modify my original post to include these new repo links so I guess people will just have to scroll .
New plugin hot off the press(special thanks to @thibaultcha and @James_Callahan for suggestions on this one too!) -
This plugin will protect the client from consuming API responses that are deemed too large within the Kong API Gateway that they rather not receive at all for stability concerns or memory constraints on their application end. Small caveat currently being the backend service needs to pass the standard Content-Length header upon response. PRs welcome to further enhance this plugin!
Thanks a lot for sharing @jeremyjpj0916! Weâll eventually be implementing OIDC at my client as well. I was curious, is there a reason you didnât build off of https://github.com/nokia/kong-oidc?
@jerney Thanks for checking the topic out . To speak to what we do internally we use a modified nokia one internally that supports multiple OpenID Connect identity providers on top of a single proxy for Introspection code flow driven by a REST header that dictates which OpenID Connect IDP to use. We use the one we built mostly for teams that want the gateway to use the full Authorization code flow albeit we are not really using the plugin that heavily and its probably not as thoroughly vetted as the Nokia plugin. If I was picking one to go with I would probably use the Nokia one if it fit my needs out of the box, if I wanted to implement more custom logic and get granular I would use my plugin more as it has no major dependencies and I personally follow my own plugin code a bit better . Just my 2 cents, no real major reason we did not build off nokiaâs, matter of fact I have chatted with the Nokia dev a few times, nice fellow!
We have a new plugin for the community to tinker with .
The goal of this plugin for us was to expose L4 errors NGINX throws when proxing with upstream/backend API services. We wanted a way to expose it to lua land and consume it within other logging plugins(which we leveraged our Splunk logging plugin to store the errors).
I have reserves around putting this on the Kong hub in its current state because its very early in design and has a few flaws that I would like to see improved upon before it becomes anything to display on Kong hub(which I would consider to generally be polished plugins).
The current implementation of multiple services are being proxies and say a 500 level error occurs from one backend service whereas the other backend service threw a L4 500 level error at the same instance in time, it is currently possible to mix up which tx log message âclaimsâ the error.
Current implementation is a little heavy on the processing and potential for looping on irrelevant errors.
These issues could eventually be cleaned up with a professional parser of nginx logs and a way for the underlying OpenResty dependency ângx.errlogâ to have a more granular way to capture these on a transaction level basis as opposed to a global shm where a single GET flushes all logs. I figure Kong has plans down the road to integrate more with NGINX generated logs for historical record of why transaction issues may have occurred, but this plugin is a good first shot and generally meets our needs as it does a âbest effortâ capture tying webserver error logs to tx level logs. We currently just compare the tx timestamp to what the error message timestamp had to know if it needs to be disregarded as irrelevant .
We welcome community or Kong PRâs around this plugin, just wanted to get something out there in the wild to get the whole community thinking.
And you probably thought you had already gotten all your Christmas gifts .
We recently open sourced another fresh Kong plugin for a logging requirement we faced:
This plugin can help folks log to Kafka, we added a new feature to the underlying dependency that allows for logging to occur over TLS and of course ported higher level configurations to the plugin we released:
We appreciate doujiang24 for helping push our PR through quickly to enable us to begin leveraging his library.
The purpose of this plugin helps validate SiteMinder user session tokens. Generally for companies that leverage siteminder, there is a webservice they bundle with the product that you can call as an API to ensure session tokens you receive are valid and user information about that token(similar to OIDC but the request/response payloads are all application/xml with custom payloads so we had to work around that and figuring out how we wanted to validate success/failures). Hope those who use siteminder get some value out of it and run Kong gateway to proxy those âuser in browserâ API calls logged in via SiteMinder sessions .
One lib it also leverages is the resty.cookie lib which is luckily already packaged in with Kong!
Another plugin we have had internally for awhile but thought it good to get out into the public for easier maintaining and to grow users and improve it for any issues seen.
We generally use Splunk for API tx metadata, but say we run into a situation as moderator for API Consumer and API Provider, or Kong is somehow adding something to the payload causing backend API problems? Well we wanted a âdebuggerâ that would just show us what request data was going to the backend as well as raw response data. All headers and bodies. We run this on a specific route or service to prevent it causing global slowdowns on the gateway. You can also log by specific http response status to help hone in on specific errors. Simple logging to the Kong nodes stdout so you donât have to worry about shipping it out somewhere, quick and dirty which is usually my style of getting things done . Hope it helps someone debug some Kong transactions down the road:
.
, but may help someone sometime .
.
. To speak to what we do internally we use a modified nokia one internally that supports multiple OpenID Connect identity providers on top of a single proxy for Introspection code flow driven by a REST header that dictates which OpenID Connect IDP to use. We use the one we built mostly for teams that want the gateway to use the full Authorization code flow albeit we are not really using the plugin that heavily and its probably not as thoroughly vetted as the Nokia plugin. If I was picking one to go with I would probably use the Nokia one if it fit my needs out of the box, if I wanted to implement more custom logic and get granular I would use my plugin more as it has no major dependencies and I personally follow my own plugin code a bit better 
. Just my 2 cents, no real major reason we did not build off nokiaâs, matter of fact I have chatted with the Nokia dev a few times, nice fellow!
.
.
. Hope it helps someone debug some Kong transactions down the road: