Enable automated security plugins at the service (root spec) level #5378
Conversation
|
rebased with latest develop |
|
tagging someone else from @Kong/team-insomnia for a second pass |
|
It's not clear to me if this aligns with the vision for deprecating plugin inference in o2k. @Tieske |
|
No it doesn't. Let's not add this. I'll follow up with @ttyS0e |
|
Had a closer look at the issue, and it is indeed a bug. The fix seems correct. So I'm changing my opinion on this one; no objections to merge it. But.... the input OAS is the one that describes the "backend" api (the api that Kong will proxy towards). Which is not necessarily the same as the one exposed by Kong, since Kong will live at a different hostname for example. The discrepancy here is that the security directive will describe the checks as implemented by Kong. So now it becomes a weird mix of backend and entry-point config. That is the reason that in the new ApiOps tools we will not include generation of those security directives. We need a better way to solve this. |
…ong#5378) * feat(plugins): enable support for service-level security definition plugins * feat(plugins): add tests for service-level security plugins * fix(syntax): match regexes to last commit * fix lint Co-authored-by: Filipe Freire <[email protected]>
changelog(Improvements): Added ability to enable automated security plugins at service-level (root of spec) when generating Kong (or Kubernetes) declarative configs
FIXES #3389
This enhancement adds the ability to use openapi-2-kong to create service-level (root of spec) security plugins, specifically OpenID-Connect, whilst generating Kong (or Kubernetes) declarative config.
It works with other security definition types also.
You will see in the tests what this is doing:
security:definition is present at the root of the document, it now creates a service-level Kong plugin to go with this declarationsecurity:on a route/method level, then a plugin will additionally be created at that levelx-kong-plugin-declarations.