400 response from kong admin api when posting declarative config

Hi,

I’m running kong using the official helm chart (chart version 0.13.0, app version 1.2) configured in db-less mode.

I’m getting a load of logs in the ingress-controller container about request validation for the /config route.

W0626 06:00:11.216162       1 queue.go:113] requeuing alchemy/cm-acme-http-solver-698mv, err posting new config to /config: 400 Bad Request {"fields":{"certificates":[{"cert":"length must be at least 1"}]},"name":"invalid declarative configuration","code":14,"message":"declarative config is invalid: {certificates={{cert=\"length must be at least 1\"}}}"}
E0626 06:00:14.549898       1 controller.go:125] unexpected failure updating Kong configuration: 
posting new config to /config: 400 Bad Request {"fields":{"certificates":[{"cert":"length must be at least 1"}]},"name":"invalid declarative configuration","code":14,"message":"declarative config is invalid: {certificates={{cert=\"length must be at least 1\"}}}"}

This log repeats for every kube service in the cluster.
I’m unable to find out what certificates it’s referring to and how/where to remedy this.

Thanks for any help.

The issue was that the secret referenced by tls.secretName on one of my ingress rules had no tls.crt configured like so:

data:
  ca.crt: null
  tls.crt: null
  tls.key: <some key>

This is the default tls secret created by cert-manager (I’m guessing).
I had to manually edit the tls.crt field to some random certificate, just so kong won’t reject the config.
From there cert-manager’s ingress rules were configured in kong and it was able to generate a real certificate and replace the random one I had in the secret.

There must have been a change in kong to add that validation that breaks compatibility with cert-manager.

I’ve opened up https://github.com/Kong/kubernetes-ingress-controller/issues/321 to track.
Indeed, this is an unexpected case and strictly not a bug but I’ve marked it as such for now.

Thank you for reporting this.

1 Like