-
Story
-
Resolution: Done
-
Critical
-
1.22.0
-
8
-
False
-
None
-
True
Recently a customer faced an issue with setting up his own custom certificate with Serverless Operator. Slack discussion here. We need to clarify what we support in more detail. Our options seem to be:
a) Certificates can be either of ConfgiMap or Secret types. In the second case Serverless Operator will not reconcile the secret but the secret should be passed down to the Knative Operator which is also reconciles the Serving CR and it should load the secret in the Serving Controller. Thus user can set the custom certificate via a secret using the controller-custom-certs config in Serving CR as usual.
b) We support the case where a custom OCP CA is created (following https://docs.openshift.com/container-platform/4.9/networking/configuring-a-custom-pki.html) and then Serverless Operator will create automatically a config map based on that CA by adding the config.openshift.io/inject-trusted-cabundle annotation so that Openshift can inject the right content. In this case user has no controller-custom-certs settings defined in Serving CR. The S-O will add by default the right configuration in at the S-O operator side as already mentioned in docs if no configmap is defined.
The default configuration added is
controller-custom-certs:
name:
config-service-ca
type: ConfigMap
In our docs we use the same configuration to demonstrate an example config and so users are confused because they think they can create a custom configmap with the above config and that would stay untouched. This is not the case, see next.
c) If user sets controller-custom-certs with his own configmap already filled with content the Serverless Operator will try to reconcile it according to case b) this leads to issues as the configmap is modified.
rhn-support-knakayam could you verify/adjust if needed the above.
rhn-support-gilins let me know if that above is accurate enough.