You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Functionality was added to enable the configuration of Ingress resources to support OpenShift to enable a streamlined way of integrating these charts to support their ecosystem.
These opinionated configurations work great for the simple use case. However, challenges have been experienced when customizing for more complex configurations and improvements can be made to support additional integrations.
Certain properties, such as path and pathPrefix cannot be defined
Opinionated TLS
OpenShift manages certain configurations via annotations along with applying certain defaults. For example, if route.openshift.io/termination annotation is set to edge, it is still possible to define the TLS certificate that will be applied to the ingress
Holistic alignment of Ingress Configurations
These charts include several Ingress resources exposing varying capabilities. The configurations and options are currently not uniform which causes challenges when looking to apply certain configurations
OpenShift Logic
OpenShift enables the "upconverting" of native Ingress resources to OpenShift Routes. The logic that is employed is located here
The following are several valid examples that can be defined within OpenShift to expose access to resources using Ingress resources
Passthrough Termination
No TLS termination occurs at the Ingress Controller as the backend pod is serving SSL certificates
Edge Termination using default Ingress Certificate
TLS termination occurs at OpenShift Ingress Router using the default certificate defined within the Ingress Controller. Traffic to the backend pod is unencrypted
Reencrypt using default Ingress certificate and trusted destination certificate
TLS reencryption occurs using the default Ingress certificate and destination certificate that is trusted within the cluster. Most likely using a certificate generated via Service Serving Certificates
Reencrypt using provided ingress certificate and trusted destination certificate
TLS reencryption occurs using provided ingress certificate and destination certificate that is trusted within the cluster. Most likely using a certificate generated via Service Serving Certificates
Thanks for the good overview of the issues you've hit.
To help prioritize solutions, are there any of these that are more of a problem for you then others?
I think there are probably some cases where supporting every permutation of options is undesirable. For example, spire-server's port must be passed through. Configuring it for retermination will only produce an unusable install. We need to identify the gaps in configuration options along with the softwares constraints.
Functionality was added to enable the configuration of Ingress resources to support OpenShift to enable a streamlined way of integrating these charts to support their ecosystem.
These opinionated configurations work great for the simple use case. However, challenges have been experienced when customizing for more complex configurations and improvements can be made to support additional integrations.
Challenges
Annotations that are set on Ingress resources are overwritten by opinionated configurations
Certain properties, such as
path
andpathPrefix
cannot be definedOpenShift manages certain configurations via annotations along with applying certain defaults. For example, if
route.openshift.io/termination
annotation is set toedge
, it is still possible to define the TLS certificate that will be applied to the ingressThese charts include several Ingress resources exposing varying capabilities. The configurations and options are currently not uniform which causes challenges when looking to apply certain configurations
OpenShift Logic
OpenShift enables the "upconverting" of native Ingress resources to OpenShift Routes. The logic that is employed is located here
The following are several valid examples that can be defined within OpenShift to expose access to resources using Ingress resources
No TLS termination occurs at the Ingress Controller as the backend pod is serving SSL certificates
TLS termination occurs at OpenShift Ingress Router using the default certificate defined within the Ingress Controller. Traffic to the backend pod is unencrypted
TLS termination occurs at OpenShift Ingress Router using the a provided certificate. Traffic to the backend pod is unencrypted
TLS reencryption occurs using the default Ingress certificate and destination certificate that is trusted within the cluster. Most likely using a certificate generated via Service Serving Certificates
TLS reencryption occurs using provided ingress certificate and destination certificate that is trusted within the cluster. Most likely using a certificate generated via Service Serving Certificates
TLS reencryption occurs using provided ingress certificate along with a provided certificate served by the pod
TLS reencryption occurs using provided ingress certificate along with a provided certificate served by the pod
The text was updated successfully, but these errors were encountered: