Isolate the Portal to use with my own Kong Deployment

[IuriGarcia]

Hello everyone,

I am still looking around to manage to just use the api portal deployment of helm charts and dependencies in order to make it run with my kong deployment. But i will already ask for tips to help me out.

already thankful.

[DonMartin76]

In principle, it should be possible to make wicked work with an existing Kong deployment (of a suitable version, i.e. 0.14.1). BUT: wicked assumes it is allowed to take over Kong completely and will rigorously delete anything from Kong which it does not deem belong in there. I.e., any services or route definitions which were manually added will be deleted automatically.

If this still is interesting to you, I can dig out what kind of configuration would need to be done to make wicked talk to an existing Kong installation.

[IuriGarcia]

Hm, in the first place, ty so much for your time! That's an important info, since i am using Kong Ingress in a K8s and do often deploy customized APIs and CRDs.

I've been testing the portal and it is just great, and i am looking to use it as my API portal. Well, i will discuss with the team and be back soon, ty again Mr!

[DonMartin76]

What you can/should do in that case is probably to have a separate API gateway for your publicly available APIs, and keep the internal/private ones in the instance you already have. Depending on your setup, you can still re-use the Postgres instance (in a separate database on the same instance) if that makes it easier, but still let the wicked/Kong Postgres instance be the same as the one you are using.

[andrevtg]

Me and Iuri are still trying to figure this out. Kong Ingress Controller is a db-less Kong instance in itself. There is no postgres around, it uses CRD objects instead (CRDs are synced to Kong admin automagically).

This is a Kong deployment style that is gaining lot of traction lately. We are wondering if Wicked could be adapted for it. Looking at its architecture it should be the case to focus on "Kong Adapter" and "Portal API" components.

https://github.com/Haufe-Lexware/wicked.haufe.io/blob/master/doc/images/deployment-architecture.png

We are willing to put some energy on this. What do you think?

[DonMartin76]

Sounds intriguing. I have not yet looked at the Kong Ingress controller in detail, so I can't quite tell if this would work, or how much effort it would be.

Here are some things to check out, and I am throwing in some ideas which might be leading somewhere:

• Supposedly, it would be possible to replace the "kong-adapter" with a "kong-ingress-adapter" (or similar) which talks to the Kubernetes API (creating objects via the CRDs) instead of using the Kong API (which is probably not even there anymore?)
• By labelling the CRDs accordingly, it should be possible to distinguish between manually added API/CRDs and the ones maintained by wicked
• I have no clue whether and/or how the Kong Ingress controller supports OAuth2 in one way or the other - the docs are a little vague on this. Simple key auth is probably pretty simple to get up and running in a stripped down version.
• Additional routes should probably map pretty okay to ingress paths; whether there are additional options there I have not yet checked.

The biggest caveat which I see is how wicked/Kong currently deals with OAuth2 - which is a core part of how the portal works. The API (portal-api) is also accessed via Kong normally, and this will probably require some fiddling to make it work.

[andrevtg]

That sounds promising. The Kong Admin API still works, but it's read-only. That is why we can still plug Konga (for example) to Kong Ingress Controller (the API endpoint is still there). All objects created by CRDs show up (r/o) in Kong Admin API eventually (background syncing).

OAuth should work too, if it is based on a Kong plugin.

[DonMartin76]

OAuth is based on the (pretty shitty) Kong oauth2 plugin, yes. But I have plans to implement a more direct approach which just injects credentials via the /oauth2_tokens endpoint, as the actual oauth2 implementation only has very weird support for the actual flows. You end up implementing them yourself anyway (wicked.auth), and Kong 1.0+ removed support for querying for the refresh token.

So this could be an issue - the access token management for OAuth2.

[IuriGarcia]

So, looking at the architecture and part of the schemas in the database , it seems that PortalAPI is not accessing any Kong schema but isn't PortalAPI suposed to manage the same data that Kong is managing? I want to confirm if Portal Api and Kong are accessing the same schemas, eventually ,or if it is never happening.

[DonMartin76]

wicked and Kong are never accessing the same schema in the database. wicked only works with the API of Kong, "remote controlling" Kong via the 8001 port administration API. In the end, wicked has all the data, and configures Kong so that it reflects the state of the database of Kong. In principle, you could delete the Kong schema entirely, start Kong, and restart the Kong Adapter container, and wicked would recreate the entire Kong schema via the administration API again.

The only thing which would go missing are current access tokens (and refresh tokens of course).