Kong plugin config with Secret

Questions
1

Hi,

I’m currently using kong-oidc plugin (GitHub - nokia/kong-oidc: OIDC plugin for Kong) with the following KongPlugin resource yaml file to config it

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
   name: my-kong-oidc
   namespace: my-namespace
config:
   client_id: my-client
   client_secret: xxx
   introspection_endpoint: https://my-endpoint.com
   discovery: https://my-endpoint.com/.well-known/openid-configuration
   realm: my-realm
   bearer_only: "yes"
plugin: oidc

Because some of these value is sensitive so I wanted to move them to a Secret resource and reference them in the KongPlugin Resource. Following the github documentation on this (https://github.com/Kong/kubernetes-ingress-controller/blob/main/docs/references/custom-resources.md#kongplugin), which I think is just introduced in the latest releases, I created a Secret resource as follows:

apiVersion: v1
kind: Secret
metadata:
  name: plugin-conf-secret
  namespace: my-namespace
stringData:
  oidc-config: |
    client_id: my-client
    client_secret: xxx
    introspection_endpoint: https://my-endpoint.com
    discovery: https://my-endpoint.com/.well-known/openid-configuration
    realm: my-realm
    bearer_only: "yes"
type: Opaque

and refer it to the KongPlugin resource as:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: my-kong-oidc
  namespace: my-namespace
configFrom:
  secretKeyRef:
    name: plugin-conf-secret
    key: oidc-config
plugin: oidc

Everything works well following the docs.
My concerns are that

Can the value in the Secret resource be under data and encoded as:

apiVersion: v1
kind: Secret
metadata:
    name: plugin-conf-secret
    namespace: my-namespace
data:
    client_id: encoded-value
    client_secret: encoded-value
    introspection_endpoint: encoded-value
    discovery: encoded-value
    realm: encoded-value
    bearer_only: encoded-value
type: Opaque

and be refered to the KongPlugin resource as:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: my-kong-oidc
  namespace: my-namespace
configFrom:
  secretKeyRef:
    name: plugin-conf-secret
    key: client_id
  secretKeyRef:
    name: plugin-conf-secret
    key: client_secret
  secretKeyRef:
    name: plugin-conf-secret
    key: introspection_endpoint
  secretKeyRef:
    name: plugin-conf-secret
    key: discovery
  secretKeyRef:
    name: plugin-conf-secret
    key: realm
  secretKeyRef:
    name: plugin-conf-secret
    key: bearer_only
plugin: oidc

or just 1 as:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: my-kong-oidc
  namespace: my-namespace
configFrom:
  secretKeyRef:
    name: plugin-conf-secret
    key: client_id
plugin: oidc

I tried doing as above but the logs from the ingress controller read
error parsing config for KongPlugin 'my-kong-oidc/my-namespace': key 'bearer_only' in secret 'my-namespace/plugin-conf-secret' contains neither valid JSON nor valid YAML)
or
error parsing config for KongPlugin 'my-kong-oidc/my-namespace': key 'client_id' in secret 'my-namespace/plugin-conf-secret' contains neither valid JSON nor valid YAML)
Is using data in Secret and refer it to KongPlugin resource possible? Or it just accepts stringData for now?

Best regards.

2

stringData is just a convenience tool to write Secrets without encoding values in advance. Once you submit the Secret, those values are encoded and moved into data (you can check by using kubectl get secret SECRETNAME -o yaml after).

We do require using the Secret for all plugin configuration; you cannot use it for individual configuration settings while leaving the rest directly configured in the KongPlugin. That was a design choice to avoid breaking compatibility with older KongPlugins, and keep the config section the same as other YAML-based plugin configuration (namely decK).

To handle a mix of plain and Secret-masked config items, we’d need something like this (similar to how Kubernetes handles environment variables:

config:
- name: foo
  value: value1
- name: bar
  valueFrom:
    secretKeyRef:
      name: mysecret
      key: bar

Because KongPlugin uses configName: configValue pairs inside the config object, we don’t have the flexibility of using either a value or valueFrom, and have to assume that configValue is one or the other. Migrating to the more flexible version is something we’ll consider for a future breaking change (in a v2 KongPlugin CRD).

1 Like
3

Ah, thank you @traines, I’m just starting to get my hands dirty with Secret and was not clear about this point. Sorry it took you to point it out to me when it is already clearly metioned in the official Kubernetes docs.

So if I understand this correctly, even though the client_id and bearer_only are not really a secret, I will have to include it in the Secret anyway and refer the Secret in the KongPlugin resource as one and cannot be as individual keys.

Looking forward to this new version of KongPlugin CRD for more flexibility.

4

Hi,
Just checking if there is any update on this? Is it possible to specify both ‘config’ and ‘configFrom’. Or have you enabled valueFrom?
It there is a ticket that tracks this work a link to it would be great.

Thanks,

5

There are internal tickets for it/it’s something the KIC product manager has on their roadmap, but no public ticket yet. We don’t know as of yet when it will be prioritized versus other features.