FeatureRequests: (1) Key rename and (2) cross-object mirror reflection

[lazarusllong]

0. Motivation

On OpenShift a custom certificate to serve the default ingress requires two different objects; a custom CA and a custom TLS certificate:

• The custom CA is stored in a configMap under the key ca-bundle.crt.
• The custom certificate is a regular TLS secret with the certificate chain under key tls.crt.

The custom certificate on this scenario has a RFC1422 compliant full certificate chain, though OpenShift ignores it and instead uses the chain from the custom CA key ca-bundle.crt.

The custom CA configMap is currently being generated by manually exporting the tls.key content from the custom certificate secret and importing it into the key ca-bundle.crt.

Automating this task isn't currently supported by Reflector since it doesn't support neither key renaming nor cross-object mirroring.

Though being suggested here together these are two distinct and independent feature requests:

1. Key renaming:

Addition of a new annotation on the mirror object (i.e. reflector.v1.k8s.emberstack.com/key-mapping: "source-key1:mirror-key1,source-key2:mirror-key2 ...") for something like:

apiVersion: v1
kind: Secret
metadata:
  name: mirror-secret
  namespace: default
  annotations:
    reflector.v1.k8s.emberstack.com/reflects: "default/source-secret"
    reflector.v1.k8s.emberstack.com/key-mapping: "src.key:dst.key,src.other:dst.other"
data:
  dst.key: ...
  dst.other: ...
...

2. Cross-object mirroring:

Addition of a new annotation on the mirror object (i.e. reflector.v1.k8s.emberstack.com/source-type: "secret|configMap") for something like:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mirror-cm
  namespace: default
  annotations:
    reflector.v1.k8s.emberstack.com/reflects: "default/source-secret"
    reflector.v1.k8s.emberstack.com/source-type: "secret"
data:
...

3. For a full picture of how the specific scenario that motivated these feature requests would possibly end up being:

apiVersion: v1
kind: Secret
metadata:
  name: custom-tls-certificate
  namespace: openshift-config
  annotations:
    reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
    reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "openshift-config"
data:
  tls.crt: ...
...
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca
  namespace: openshift-config
  annotations:
    reflector.v1.k8s.emberstack.com/reflects: "openshift-config/custom-tls-certificate"
    reflector.v1.k8s.emberstack.com/source-type: "secret"
    reflector.v1.k8s.emberstack.com/key-mapping: "tls.crt:ca-bundle.crt"
data:
  ca-bundle.crt: |
...

This specific scenario being described would need both these features, though their individual merits are foreseeable.

Thank you very much, for your attention.

[antonio-rezende-necam-com]

This is exactly the scenario we're facing.

We use a combination of cert-manager with an Issuer in a single namespace (kube-system) and Kubernetes Reflector to replicate the TLS secret to the namespaces requiring it.

This is a standard procedure we apply to all Kubernetes we manage, and it's a hands-off from sysadmin point of view for every platform except for OpenShift, which requires us to manually copy the TLS chain to the CM whenever the secret is updated with a new certificate.

KUDOS for the idea.