Open Id Connect Issue

[dbfreem]

I am trying to convert an Open API Spec 3 file to a declarative kong yaml. I am struggling with getting the below file to generate the appropriate open id connect plugin in the declarative kong yaml. Here is the command I run.

deck file openapi2kong -s test.yaml -o test_kong_gh.yaml

Another note about this. This works when I export it from insomnia as Kong Declarative 3.x

$ deck version 
decK v1.27.1 (c589a3a)

Input test.yaml file

openapi: 3.0.0
info:
  title: test
  version: 2023-09-15 23:40:29UTC
  description: Test
servers:
  - url: ......
paths:
  /health:
    get:
      description: API Health Check
      operationId: test1
      responses:
        '200':
          description: "200 Health Response"
security:
  - openId: []
components:
  securitySchemes:
    openId:
      type: openIdConnect
      openIdConnectUrl: https://....../.well-known/openId-configuration
      x-kong-security-openid-connect:
        config:
          run_on_preflight: false 

Output test_kong_gh.yaml

_format_version: "3.0"
services:
- host: .....
  id: .....
  name: test
  path: /
  plugins: []
  port: 443
  protocol: https
  routes:
  - id: .....
    methods:
    - GET
    name: test_test1
    paths:
    - ~/health$
    plugins: []
    regex_priority: 200
    strip_path: false
    tags: []
  tags: []
upstreams: []

I really like the deaK cli tool.🚀️ Great job!!

[Tieske]

This was a deliberate choice to not include that functionality (which its predecessor inso did have).

There are multiple issues with it (which we're working on);

1. Incorrect OAS files
2. Ownership and trust

More details below. Definitely interested in thoughts about how to possibly deal with those, so feedback appreciated.

Incorrect OAS files

The input to the conversion is the OAS file that describes the API, as it lives internally in the back-end. Could be generated from code, etc.

Now if we want Kong to protect that API with basic-auth for example, then in the case of inso we would add security directives for that (and possibly x-kong-security-... for Kong specifics). The resulting file can be converted using the tools and generates the Kong output.

The problem however is that the OAS file now describes an API that doesn't exist. Since the file will in its servers block have internal hostnames, not accessible from the outside world. Yet it also describes security requirements that are not enforced on that internal service since they will be enforced by Kong (so on the external API, which probably lives on different hostnames).

So the file has become a weird mix of internal and external properties of the same service.

Ownership and trust

In large installations we typically see multiple roles or actors in the pipelines from development to production.

• platform team; operating the Kong installation, facilitating automated pipelines for developer teams to publish their APIs/services.
• developer teams (many!); build their products and continuously publish new versions on the platform.
• security team; validating configurations to ensure proper security guidelines are followed.
• product teams; requirements about API interactions and consistency between APIs

Now if the security directives are being used, how can bad-actors be prevented from injecting bad security directives into an OAS file. If there are hundreds of dev teams publishing to the same platform, then the platform and security teams cannot trust those developer teams.

The security requirements should be delivered separately (in their own flow, with their own authorizations and approvals for changes). This also allows the security folks to review only the files that input security stuff changes, instead of having to review the OAS file every time one of those many teams publishes a change.

[dbfreem]

Hey @Tieske thanks for the response. I actually agree with the above approach. Specifically for Incorrect OAS File I felt like this was a bit odd too me as well. Based on item number 2 Ownership and Trust I think I might break the auth plugin off into a kong declarative yaml with the OpenAPI Spec being separate.

The one recommendation I would have here is that if the deck openapi2kong hits a security directive it throws an exception or at a minimum a warning. To let some one know that the security directives would be ignored, since that would not be the expected behavior.