Hello all,
I’ve stuck with trying to build a working sample of Kong Gateway on top of minikube with the Helm chart. The documentation is extremely confusing and, as I suspect, is outdated.
So the context: I need to evaluate the mTLS plugin which is available only with Kong Konnect subscription (aka Enterprise edition?). As I understand, I can evaluate it with a minimal setup which is DB-less with Kong Ingress Controller using CRD resources to create sample routes and mTLS plugin.
So I went with creating a trial account and provisioning the Runtime. Per documentation here I went with Helm 3 and the following values.yaml (exactly as it was auto-generated on the Runtime page)
image:
repository: kong/kong-gateway
tag: "2.4.1.1-alpine"
secretVolumes:
- kong-cluster-cert
- kong-cluster-ca
env:
role: data_plane
database: "off"
anonymous_reports: off
vitals_ttl_days: 732
cluster_mtls: pki
cluster_control_plane: <redacted>:443
cluster_server_name: <redacted>
cluster_telemetry_endpoint: <redacted>:443
cluster_telemetry_server_name: <redacted>
cluster_ca_cert: /etc/secrets/kong-cluster-ca/ca.crt
cluster_cert: /etc/secrets/kong-cluster-cert/tls.crt
cluster_cert_key: /etc/secrets/kong-cluster-cert/tls.key
lua_ssl_trusted_certificate: /etc/secrets/kong-cluster-ca/ca.crt
ingressController:
enabled: false
installCRDs: false
combining this with minikube tunnel I can get the response from the gateway:
$ curl http://127.0.0.1/echo
{"message":"no Route matched with those values"}
And here is where I am absolutely lost - how do you configure route mapping once the deployment is done? Absolutely nothing in the documentation works:
- There is no way to use
decK since Admin API is not exposed, and anyway it’s not clear if you can use it in DB-less mode
- The CRD way with
KongIngress does not seem to work at all - may be related to the ingressController.enabled: false line in the values.yaml? Then how do you suppose to configure routes?
I’ve tried:
- enable
ingressController - it fails to start its container with liveness probe exceptions
- enable Admin API and expose it via Kong itself - it refuses connections
- tried following these steps with no result - it seems outdated since it doesn’t use annotations for configuration
So my question is really - where do I find a minimal working example with DB-less Kong for Kubernetes Enterprise on minikube with routes configuration? Will have capability of enabling mTLS?
Which way you apply configuration is essentially personal preference. All are equally supported.
If you do want to use Ingresses and KongPlugins and such, you will need to set ingressController.enabled: true.
Not using the controller and using decK to apply configuration is probably simplest if you just want to quickly evaluate the mTLS plugin.
Your values.yaml has that instance configured as a data plane node. These don’t expose their admin API and instead receive configuration from a control plane node, which does expose its admin API. It looks your trial (and the associated generated configuration) is for our Konnect product, where we run managed control plane nodes on our infrastructure and push configuration to data plane nodes you run on your infrastructure.
The web interface you used to create the runtime configuration should also have a section to configure routes and plugins. Once you’ve started a data plane node with the provided configuration and see it registered, configuration you add there will be shipped to your instance automatically. You can alternately use deck to update configuration on the managed control plane.
I don’t believe that we currently have any self-service trial options that you can use to create mTLS plugin configuration on a standalone instance (where both the proxy and admin API run on the same node), but if that’s what you want, you can check with sales to see if they can provide you with a local trial license.
Yeah, I probably got confused between all these options. I generally go with the Infra-as-a-Code approach, so I can have a repeatable PoC, but from what I hear - I should use Web UI to create routes and configure plugins? Unless I want to give a try to the decK Konnect alpha?
So the chain of thoughts is this:
- I need an enterprise version of Kong to enable the mTLS plugin, without a valid license it won’t work
- If I don’t reach out to sales (just too long), the only other way is to go with Konnect free trial
- Konnect free trial limits my configuration abilities to the managed Control Plane and its Web UI or decK Konnect (no CRD)
It’s just damn unfortunate these things are not obvious from the documentation.
Anyway, thanks for your help, I’ll give it a try.
As I was trying out it, I have stumbled upon the following problem:
- I am trying to enable my self-signed TLS cert for the given hostname and cannot see it working
There seems to be no any sample guide for the deck syntax.
UPDATE: Playing with deck konnect dump and trying to derive decK syntax from Admin API guide I’ve ended up with this:
_format_version: "0.1"
service_packages:
- name: Echo
versions:
- implementation:
kong:
service:
connect_timeout: 60000
host: echo.mtls-poc
id: b939ce96-94e7-4337-82a9-3bbe8119ce90
path: /
port: 80
protocol: http
read_timeout: 60000
retries: 5
routes:
- hosts:
- mtls.auth.local
https_redirect_status_code: 426
id: 5a290e5f-4bf1-4023-b6c1-bde5679af14a
methods:
- GET
path_handling: v0
paths:
- /echo
preserve_host: false
protocols:
- https
regex_priority: 0
request_buffering: true
response_buffering: true
strip_path: true
write_timeout: 60000
type: kong-gateway
version: v1
certificates:
- cert: |
<full certificate chain up to the Root CA>
key: |
<private key>
id: 18cee516-6268-11eb-ae93-0242ac130012
tags: [ "mtls.key" ]
ca_certificates:
- cert: |
<Int CA>
id: 4f9eae4e-f929-11eb-a6bb-3ba849d88928
tags: [ "mtls.ca.int" ]
- cert: |
<Root CA>
id: 7e14f65c-f929-11eb-bbfc-df294126d642
tags: [ "mtls.ca.root" ]
Doing deck konnect sync I can see the route created, but the presented TLS cert is still the Kong’s default self-signed one. What I am doing wrong here?
UPDATE 2: ok, apparently adding snis attribute to the certificate does the magic. I really wish there would be just samples in the docs.
UPDATE 3: Now stuck with mTLS plugin:
plugins:
- name: mtls-auth
route: 5a290e5f-4bf1-4023-b6c1-bde5679af14a
config:
ca_certificates:
- 4f9eae4e-f929-11eb-a6bb-3ba849d88928
- 7e14f65c-f929-11eb-bbfc-df294126d642
skip_consumer_lookup: true
cache_ttl: 60
It says no such route was found. What should I supply there if not route ID?
UPDATE 4: again no specific doc on this, but luckily I found another plugin example here. Apparently you need to shove plugin config right in the service declaration. Again, wish that mTLS plugin page would mention the Konnect case, because declarative example there is different 
Well at this point it was a wild ride, but seems like I’ve got it configured.
If I may suggest improvements, then
- Consolidate documentation on how to get Enterprise features in a Free trial (like don’t use Ingress Controller, use decK instead)
- More, many more examples on decK and declarative configuration, please. Currently, I derive much of this from
Admin API, which is not always a 1-to-1 match.
- Update mTLS plugin page with
decK Konnect-specific example. There are decK and Konnect examples, but not decK Konnect which apparently differs from them both.
- Whatever samples you do - do all of the variants:
API, CRD, deck, deck konnect, konnect. Sometimes slight or not-so differences between them make the whole experience a hair-pulling contest.
Regards