Goal

• The OpenShift Logging Components should honor the global apiservice TLS security Profile configuration.
• The OpenShift Logging Components should honor at minimum the intermediate TLS Security Profile.

Background

Cluster-wide TLS configuration with the ability to configure ciphers that would apply to all OpenShift components.

There are four TLS security profile types:

• Old: https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility
• Intermediate: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29
• Modern: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
• Custom

The Old, Intermediate, and Modern profiles are based on recommended configurations. The Custom profile provides the ability to specify individual TLS security profile parameters.

Why is this important?

• Customers have varying security requirements and therefore their security teams can set different minimum TLS versions and Ciphers that are allowed. 
• Currently we don't make any explicit definitions on used MinTLSVersion or Ciphers for any of our components. We simply trust inherited upstream defaults.
• Furthermore, users would want to select the same minimum TLS versions and Ciphers allowed for all components in the OpenShift cluster. Therefore use the existing tlsSecurityProfile (see https://docs.openshift.com/container-platform/4.6/rest_api/config_apis/apiserver-config-openshift-io-v1.html)

Scenarios

• As a cluster admin, I would like to set the crypto policy once in OpenShift and have it apply to any component inside the Logging stack using TLS.

Acceptance Criteria

• All Logging components honor the tlsSecurityProfile setting from the global apiservers.config.openshift.io resource.

Previous Work (Optional):

• Enhancement proposal
• Example: Ingress Operator

Documentation Considerations

• Note that logging components do honor the tlsSecurityProfile field from the global apiservers.config.openshift.io/cluster resource when configuring endpoints that support TLS connections. Maybe we can point to another section in the docs that highlights what that actually means.
• OCP core docs: https://docs.openshift.com/container-platform/4.12/security/tls-security-profiles.html

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>