Improved service mesh integration

[Travis Groth]

Is your feature request related to a problem? Please describe.

Presently, our insecure option changes a number of deployment time options, primarily optimized for running in a service mesh where all TLS is offloaded to the mesh.

However, as pointed out in pomerium/pomerium#2387, our TCP tunneling does not work correctly if we don't terminate the HTTP connection ourselves. More generally, users having to maintain service mesh configuration objects in front of the pomerium proxy is additional configuration and performance overhead that is no longer necessary with the introduction of the ingress controller and our general pattern of being the user-facing edge proxy of any zero trust topology.

Concretely - our helm chart, as it is today, does not have all the right knobs to allow pomerium proxy to terminate inbound TLS/HTTP at edge, while offloading internal communication to a secure service mesh.

Describe the solution you'd like

• Add configuration to enable/disable downstream TLS on the proxy service independently of the rest of the services
• Add per-deployment pod label customization settings
• Default proxy downstream TLS to enabled even in insecure mode
• Example istio deployment with new settings and labels as some istio specific labels are required

Describe alternatives you've considered

N/A

Explain any additional use-cases

Though the primary test case is istio, these settings should hopefully be useful in other service mesh deployments.

Additional context

n/a

[Travis Groth]

Related - #234

[Le Anh Duc]

Istio

For Istio ServiceMesh, one of the thing we can do is leverage the existing mTLS of Envoy pod via these tweaks to the pod itself.

containers:
  - name: a-server
    ...
    volumeMounts:
      mountPath: /etc/certs/
      name: istio-certs
volumes:
  - emptyDir:
      medium: Memory
    name: istio-certs

And also with the annotations:

spec:
  template:
    metadata:
      annotations:
        traffic.sidecar.istio.io/includeInboundPorts: ""   # do not intercept any inbound ports
        traffic.sidecar.istio.io/includeOutboundIPRanges: ""  # do not intercept any outbound traffic
        proxy.istio.io/config: |  # configure an env variable `OUTPUT_CERTS` to write certificates to the given folder
          proxyMetadata:
            OUTPUT_CERTS: /etc/istio-output-certs
        sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]' # mount the shared volume at sidecar proxy

But currently there is no way to point via Helm values to a different location of the TLS. The only way to reference existing TLS from another secret.

This work around is documented on: https://istio.io/latest/docs/ops/integrations/prometheus/#tls-settings but the same can be done with Pomerium I guess.

Not sure about others but currently my deployment of Pomerium with Istio is like this: values.yaml.

[Travis Groth]

Hi @anhdle14 thanks for chiming in.

I'd seen that volume approach but it seemed under-documented. To leverage it properly I think we'd need some changes to core in addition to the helm chart. Specifically:

• I don't think we allow setting a single client certificate for all proxy->upstream traffic
• I don't believe our grpc clients support setting a TLS certificate presently

#238 should facilitate inbound TLS bypassing istio but leans on the istio envoy proxy for outbound traffic. Docs to leverage it are in progress.

[Travis Groth]

Closing. Documentation is in place and chart changes made.