Creating consumers with basic-auth using kong ingress

I have Kong 2.0.2 and Kong ingress controller 0.7.1 deployed in DB-less mode, and I’m trying to figure out how to provision a consumer using the new secret-based methods. The documentation is sparse on this topic, and with it being new in v0.7 of the ingress controller, there’s not a whole lot of working examples out there.

I have the following k8s resources (along with 2 other sets following the same pattern) created:

apiVersion: v1
data:
  kongCredType: YmFzaWMtYXV0aA== # basic-auth
  password: ...
  username: ...
kind: Secret
metadata:
  name: kong-global-config-s3-repo-consumer-test-basic-auth
  namespace: infra
type: Opaque
---
apiVersion: configuration.konghq.com/v1
credentials:
- kong-global-config-s3-repo-consumer-test-basic-auth
kind: KongConsumer
metadata:
  name: kong-global-config-s3-repo-consumer-test
  namespace: infra
username: test

However, the kong ingress controller seems to choke on this config:

E0326 19:27:56.322072       1 controller.go:119] unexpected failure updating Kong configuration:
posting new config to /config: 400 Bad Request {"fields":{"consumers":[{"basicauth_credentials":[{"@entity":["all or none of these fields must be set: 'password', 'consumer.id'"]}]},{"basicauth_credentials":[{"@entity":["all or none of these fields must be set: 'password', 'consumer.id'"]}]},{"basicauth_credentials":[{"@entity":["all or none of these fields must be set: 'password', 'consumer.id'"]}]}]},"name":"invalid declarative configuration","code":14,"message":"declarative config is invalid: {consumers={{basicauth_credentials={{[\"@entity\"]={\"all or none of these fields must be set: 'password', 'consumer.id'\"}}}},{basicauth_credentials={{[\"@entity\"]={\"all or none of these fields must be set: 'password', 'consumer.id'\"}}}},{basicauth_credentials={{[\"@entity\"]={\"all or none of these fields must be set: 'password', 'consumer.id'\"}}}}}}"}

Can anyone tell me what I’m missing here? Thanks.

Is that how you are applying the secret manifest?
If yes, then it won’t work.
You need to use stringdata field of the Secret resource.
https://kubernetes.io/docs/concepts/configuration/secret/

That is the result of running “kubectl get secret” after creating it using the “stringData” field. It does not matter how it was initially created. There API only ever returns “data”.

From the docs you linked:

The stringData field is a write-only convenience field. It is never output when retrieving Secrets.

Correct.

Can you share the command you have used to create the secret?

Here is how I use it:

 kubectl create secret generic foo1  --from-literal=credType=basic-auth  --from-literal=username=foo --from-literal=password=bar

The secret is being created by a custom helm chart. Here is the relevant section of the helm template:

apiVersion: v1
kind: Secret
metadata:
  name: {{ $.Chart.Name }}-s3-repo-consumer-{{ $consumerName }}-basic-auth
type: Opaque
stringData:
  kongCredType: basic-auth
  username: {{ $consumer.username }}
data:
  password: {{ $consumer.password | b64enc }}

Also, you use “credType” in your example above, but the docs say “kongCredType”.

I’ve tried falling back to using the deprecated KongCredential type, and I’m getting the exact same error in the ingress controller logs.

There seems to be more going on here. I tried reproducing the issue locally (in k3d) with only the consumer/credential config, and it works fine. My production config also contains a lot of other config for services/routes. Could I potentially be running into a bug here?

I deleted all of the “Ingress” and “KongPlugin” resources that weren’t directly associated with what I was trying to do here, and now it’s generating the config properly. However, this is not an actual solution, as I need those other configs.

I seem to have narrowed this down to a problem with some of the unrelated “Ingress” resources for kong that use the “basic-auth” (and apparently “key-auth”) plugins. If I delete them, the kong config is suddenly fixed. Those “Ingress” resources do not break the config when my KongConsumer is not defined, so there’s some weird interaction here.

I managed to narrow down the circumstances under which this happens and created a small reproducing test case. I created the following Github issue with the details: