What

Currently with RHCL you can enable mTLS between the gateway and the RHCL components if it is provided as part of a mesh (IE OSSM) that has side cars enabled. However with OCP ingress the mesh component is not enabled. 

Without side cars, you can configure TLS within the Authorino CRD via the Authorino CR

spec:
  listener:
    tls:
      enabled: true
      certSecretRef:
        name: authorino-server-cert

the but you cannot currently configure the Gateway to know about the CA needed to trust configured cert this is something that needs to be done manually by the cluster / gateway admin. 

We have defined a short term workaround using a second EnvoyFilter to patch the Authorino cluster defined by RHCL and set the priority so it executes after the EnvoyFilter managed by RHCL:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: authorino-cluster-tls
  namespace: ${GATEWAY_NAMESPACE}
spec:
  priority: 1
  workloadSelector:
    labels:
      app: [PLACEHOLDER]
  configPatches:
  - applyTo: CLUSTER
    match:
      context: ${CONTEXT_NAME}
      cluster:
        name: ${CLUSTER_NAME}
    patch:
      operation: MERGE
      value:
        transport_socket:
          name: envoy.transport_sockets.tls
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
            common_tls_context:
              validation_context:
                trusted_ca:
                  inline_string: "${CA_CERT}"
            sni: ${SNI}
 

This is just a work around and we need a longer term solution that will allow the CA to be configured in the gateway via a mounted secret and doesn't rely on patching a config managed by the RHCL operator

Options

• RHCL could be told via the Kuadrant CR during installation what secrets are needed and add these to both Authorino and the EnvoyFilter managed by the RHCL operator that registers the Authorino cluster.
  • One question on this is whether it should RHCL's responsibility to configure the Gateway or whether that should be an API provided by OSSM / Gateway API 
• Investigate BackendTLSPolicy to see does this fit the requirement

Open Question:

If a none rhcl workload wants to secure communication between the gateway and a workload how is that achieved are there use cases beyond external auth?