Make ssl.conf a Go template with overridable cipher suite and protocol

[fmount]

Whether we decide to keep hardcoded default values that perform a graceful downgrade when a protocol or cipher suite cannot be negotiated, or inject the lines proposed by this patch as a template from openstack-operator, this change does not introduce any regression to the current model.

Jira: OSPRH-30239
Jira: OSPRH-31347

[stuggi]

@fmount how would we expose the customization of this? via the ctlplane tls section?

using the OCP cluster config? from an OCP PM roadmap session. for openshift there will be a single place in the cluster to configure tls across all operators (core & layered products). https://redhat.atlassian.net/browse/OCPSTRAT-2611

[fmount]

@fmount how would we expose the customization of this? via the ctlplane tls section?

using the OCP cluster config? from an OCP PM roadmap session. for openshift there will be a single place in the cluster to configure tls across all operators (core & layered products). https://redhat.atlassian.net/browse/OCPSTRAT-2611

@stuggi yes, the OCPSTRAT you mentioned (I still have to look at it) is exactly the reason of templating this file.
My idea (I have a private POC but we should discuss about that first) is to either not expose any parameter in the ctlplane, or eventually, in case an explicit override is required, use the tls section of the ctlplane.

Here's a tl;dr that we can use as a base to discuss:

1. Service operators won't expose any TLS parameter (you can't make an override from the services)
2. openstack-operator will get the TLSProfile looking at the ocp config (this is an example where I get it from the APIServer, but it could be any new common CR [1]
3. a tls-config ConfigMap is populated and contains the rendered strings that we're templating in this patch: these values could be intercepted directed by lib-common, so you don't have to look for the ConfigMap and resolve these parameters from the services

I would manage this process entirely from openstack-operator and be consistent w/ the OCP plan. In the end we expose services through Routes that should inherit the OCP configuration: I can't see right now a use case where we need httpd config to diverge from that, and that's why unless explicitly requested, these parameters can be computed behind the scene by inheriting from openshift.

@stuggi I think we should sync more about the overall plan, but I guess the template here would be required regardless of the implementation details or the strategy we select.

[1] https://paste.opendev.org/show/buCpPvWmbFnIg1zTIgQX/

[stuggi]

@fmount how would we expose the customization of this? via the ctlplane tls section?
using the OCP cluster config? from an OCP PM roadmap session. for openshift there will be a single place in the cluster to configure tls across all operators (core & layered products). https://redhat.atlassian.net/browse/OCPSTRAT-2611

@stuggi yes, the OCPSTRAT you mentioned (I still have to look at it) is exactly the reason of templating this file. My idea (I have a private POC but we should discuss about that first) is to either not expose any parameter in the ctlplane, or eventually, in case an explicit override is required, use the tls section of the ctlplane.

Here's a tl;dr that we can use as a base to discuss:

1. Service operators won't expose any TLS parameter (you can't make an override from the services)
2. openstack-operator will get the TLSProfile looking at the ocp config (this is an example where I get it from the APIServer, but it could be any new common CR [1]
3. a tls-config ConfigMap is populated and contains the rendered strings that we're templating in this patch: these values could be intercepted directed by lib-common, so you don't have to look for the ConfigMap and resolve these parameters from the services

I would manage this process entirely from openstack-operator and be consistent w/ the OCP plan. In the end we expose services through Routes that should inherit the OCP configuration: I can't see right now a use case where we need httpd config to diverge from that, and that's why unless explicitly requested, these parameters can be computed behind the scene by inheriting from openshift.

@stuggi I think we should sync more about the overall plan, but I guess the template here would be required regardless of the implementation details or the strategy we select.

@fmount sounds good. maybe we can meet next week on this to discuss it.

Update: An initial description of this work can be found here [0], and we can use it to dig more into this topic.

[1] https://paste.opendev.org/show/buCpPvWmbFnIg1zTIgQX/

[0] https://gist.github.com/fmount/f6d473bca1cb8d3bb9a52b9883c7dcf5