Can a global plugin be applied to all workspaces?
A plugin that isn’t associated with any Service, Route, or Consumer is considered global and runs on every request, but only within its own Workspace. There is no way to set up a plugin that automatically applies to all Workspaces.
How do I retrieve a secret with Kong Gateway secret management in the Request Transformer Advanced plugin?
You can fetch a token from a Kong Gateway Vault and pass it to the upstream service in the Authorization header as Bearer <token>:
- Enable
KONG_UNTRUSTED_LUA="on"in your Kong Gateway configuration. -
Add the following under the plugin’s
config.add_headers:Authorization:$((function() local value, err = kong.vault.get("{vault://env/kong-token}") if value then return "Bearer " .. value end end)())
Make sure you have made the required changes to the Vault reference. This configuration dynamically retrieves the token from a Kong Gateway Vault and appends it to the Authorization header as a Bearer token.
What are the hit_level definitions for caching in custom plugins?
When you implement caching in a custom plugin, hit_level indicates which cache level a value was fetched from. The cache level hierarchy is:
-
L1: Least-Recently-Used Lua VM cache using
lua-resty-lrucache. Provides the fastest lookup if populated, and uses LRU eviction to avoid exhausting the workers’ Lua VM memory. -
L2:
lua_shared_dictmemory zone shared by all workers. This level is only accessed if L1 was a miss, and prevents workers from requesting the L3 cache. -
L3: A custom function that is only run by a single worker to avoid the dog-pile effect on your database or backend (via
lua-resty-lock). Values fetched via L3 are set to the L2 cache for other workers to retrieve.
This is also defined in the lua-resty-mlcache repo on GitHub.