Apologies if this is in the documentation, but I don’t think I’ve found it if it is.
From what I can tell, there is an assumption that both Kong and upstream Services live in a trusted domain - perhaps protected by perimeter defence. i.e. when a Service is added to Kong, the Service assumes the calls it gets are from Kong and carries on. Yes, Kong may have authenticated the Consumer, and added relevant headers to say so (e.g. https://getkong.org/plugins/jwt/?_ga=2.146476220.944991546.1525854809-1188234996.1525854809#upstream-headers) , but how can the Service tell (and trust) it is being called by Kong?
I want to setup a ‘trust no one’ environment, where the Service would need to authenticate whoever is calling it, which would in theory just be Kong. Nominally I’d chose to use a JWT using HS256, and a shared secret between the Kong (in this instance) and the Service. A secrets manager (like Vault) could be used to handle the shared secret sharing/rolling etc. Anyway. this approach means Kong essentially resigning the message, and adding a new JWT token to the header. This wouldn’t displace the Customer JWT from the message. Whilst having a different shared secret vs the Consumer JWT adds another secret to manage, it means the Customer JWTs secret is only shared between two parties (Consumer/Kong) instead of 3 (Consumer/Kong/Service). I’ve been advised that less sharing means less collateral damage if the secret was compromised.
Does such functionality exist? In my mind it would involve adding a (new, no doubt) JWT generation plugin (vs the existing JWT verification plugin) to what I presume is some internal workflow that Kong operates per call.
I hope that all makes sense. Thanks in advance for your patience.
Psst, or am I missing that setting up mutual TLS would solve this. If so, that’s a bit icky…I’ve been advised to steer clear of mutual TLS due to cert lifecycle maintenance (however a Secrets Manager could I guess mitigate that). I’ve been advised that one-way TLS and JWT/HS256 is sufficiently safe.