Lack of documentation: mTLS between client app and Kong and upstream

I went through Kong documentation, basic labs and community but did not find proper documentation required to configure mTLS in kong.
If you look at Apigee documentation for mTLS, you will easily understand how to implement the same in API gateway, link given below.
https://docs.apigee.com/api-platform/system-administration/about-ssl

What I (realistically most of us) am looking for is step by step presentation on how to implement mTLS in Kong that should cover below topics.

  1. Client app to Kong (1-way and 2-way TLS)
  2. Kong to Upstream (1-way and 2-way TLS)
  3. Example/lab for above two steps
  4. Troubleshooting tips

If you think documentation is already there but I missed, request you to share the same with me.

Would something like my latest blog post at Kong and (m)TLS both downstream and upstream - SvenWal help you?

Thanks @SvenWal . your blog post gives answer of many questions. However, I still feel there is need of more detailed documentation.
I tried to understand your post and made below conclusion. Please correct if necessary.

I also made few comments on your topics.

For topic #1 Certificate presented by Kong to the client - Certificate Per Route :

  • Apart from SNI, we can utilize SAN (Subject Alternate Name) feature of the SSL certificate. Here, Kong’s cert will be only one though there are more than one hostnames of the kong. Just need to add all hostnames in the certificates SAN section.

  • As per my understanding, ssl_cert and ssl_cert_key are the kong gateway’s ssl cert and key.

For top #3 Certificate presented by Kong to the upstream:

  • As per my understanding client_ssl_cert and client_ssl_key mentioned here are the Kong gateway’s certficates. These can be the same as mentioned above (ssl_cert and ssl_cert_key)

For topic #3 Certificate presented by Kong to the upstream - Certificate per service

  • If ssl_Cert and ssl_cert_key are the kong’s certs then there is no chance to have different certificates to be presented to the upstream. The upstream should hold only one gateway’s cert as gateway is the client app and upstream is the server.

Apart from the above points, here is what I summarize. Here we are not bothering about how and where client and upstream systems are installing certs. Only concern is Kong

Flow is:
client app<–>Kong<–> upsteam

Explanation:

  • For client app <–> kong communication, kong will share it’s public cert (mentioned in ssl_cert) to client app to install this in client’s trustore. Kong will install client app’s ssl cert in kong’s truststore (using ca_certificates API endpoint)

  • For kong <–> upstream communication, kong will share it’s public cert (mentioned in client_sll_cert or ssl_cert) to the upstream app to install this in upstream’s truststore. Upstream will provide it’s public cert to kong and kong will install this using ca_certificates admin api.

Please correct if above understanding is wrong w.r.t. Kong.

Hi Sachin,

jumping in here - your understanding is right however:

  • For kong <–> upstream communication, kong will share it’s public cert (mentioned in client_ssl_cert or as the client_certificate property of the service) to the upstream app to install this in upstream’s truststore. Upstream will provide it’s public cert to kong and kong will install this using ca_certificates admin api.(alternatively this can be specified at the Kong level using the nginx properties in this link

Essentially you can set this in 2 places - either at the Kong proxy level as a configuration property or at the per service level


© 2019 Kong Inc.    Terms  •  Privacy  •  FAQ