# Kong plugin config with Secret

**URL:** <https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986>\
**Category:** Questions\
**Tags:** kubernetes\
**Created:** [August 26, 2020, 10:30am UTC](https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986 "2020-08-26T10:30:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![lafonte](https://avatars.discourse-cdn.com/v4/letter/l/c4cdca/32.png) [@lafonte](https://discuss.konghq.com/u/lafonte)\
**Post date:** [August 26, 2020, 10:30am UTC](https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986/1 "2020-08-26T10:30:13Z")

</div>

Hi,

I’m currently using kong-oidc plugin ([GitHub - nokia/kong-oidc: OIDC plugin for Kong](https://github.com/nokia/kong-oidc)) 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](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.

---

<div class="post-metadata">

**Author:** ![traines](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/traines/32/158_2.png) [@traines](https://discuss.konghq.com/u/traines)\
**Post date:** [August 26, 2020, 10:38pm UTC](https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986/2 "2020-08-26T22:38:33Z")

</div>

`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](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#envvar-v1-core):

```auto
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).

---

<div class="post-metadata">

**Author:** ![lafonte](https://avatars.discourse-cdn.com/v4/letter/l/c4cdca/32.png) [@lafonte](https://discuss.konghq.com/u/lafonte)\
**Post date:** [August 27, 2020, 1:55am UTC](https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986/3 "2020-08-27T01:55:31Z")

</div>

> [@traines](#):
>
> `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).

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.

> [@traines](#):
>
> We do require using the Secret for all plugin configuration

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.

> [@traines](#):
>
> Migrating to the more flexible version is something we’ll consider for a future breaking change (in a v2 KongPlugin CRD)

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

---

<div class="post-metadata">

**Author:** ![victork](https://avatars.discourse-cdn.com/v4/letter/v/dbc845/32.png) [@victork](https://discuss.konghq.com/u/victork)\
**Post date:** [December 9, 2021, 6:36pm UTC](https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986/4 "2021-12-09T18:36:32Z")

</div>

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,

---

<div class="post-metadata">

**Author:** ![traines](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/traines/32/158_2.png) [@traines](https://discuss.konghq.com/u/traines)\
**Post date:** [December 10, 2021, 5:54pm UTC](https://discuss.konghq.com/t/kong-plugin-config-with-secret/6986/5 "2021-12-10T17:54:01Z")

</div>

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.