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.
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 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:
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:
3. For a full picture of how the specific scenario that motivated these feature requests would possibly end up being:
This specific scenario being described would need both these features, though their individual merits are foreseeable.
Thank you very much, for your attention.