Use p12 instead of rsa_public_key for jwt plugin

Kubernetes
1

Is it possible to use a p12 file instead of rsa_public_key for the jwt plugin?
If yes what would i put in the K8s secret stringData field? do i need to change the consumer too?

---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: app-jwt-k8s
plugin: jwt
---
apiVersion: v1
kind: Secret
metadata:
  name: app-jwt-k8s
type: Opaque
stringData:
  kongCredType: jwt
  key: devk8s-issuer
  algorithm: RS256
  rsa_public_key: |-
    -----BEGIN PUBLIC KEY-----
    mypublickeystuffhere
    -----END PUBLIC KEY-----
---
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  annotations:
    kubernetes.io/ingress.class: kong
  name: app-jwt-k8s
username: app-jwt-k8s
credentials:
  - app-jwt-k8s
---
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
  name: echo-svc
  annotations:
    konghq.com/strip-path: "true"
    konghq.com/plugins: app-jwt-k8s, allowed-src
    kubernetes.io/ingress.class: kong
spec:
  rules:
    - http:
        paths:
          - path: /echo
            backend:
              serviceName: echo
              servicePort: 80
2

You cannot store that key in a file, but you can store the entire plugin configuration in a Secret.

The format is the same, however: the stringData in the Secret is just what you’d normally place directly under config in the KongPlugin. For fields that need to include line breaks, you’ll use a YAML multiline string as in your example.

That feature is more intended for plugins that include sensitive data, e.g. the AWS key used in the aws-lambda plugin. Since the key in the JWT plugin is public, it’s fine to leave in the KongPlugin itself.

We had wanted to provide a way to include individual config fields in a Secret or ConfigMap, but doing so wouldn’t allow us to preserve the existing config format due to the underlying implementation. That’d be a significant breaking change, so we opted to create configFrom as an alternative that still allows configuration in Secrets without breaking config.

We may revisit that decision in the future as part of creating a new version of the KongPlugin custom resource. Any such change would still use YAML multiline strings for configuration like this, as that’s what Secrets require, but it would allow you to see non-sensitive configuration in the KongPlugin itself while still keeping sensitive configuration in a Secret.

1 Like