Add limited trust configuration capabilities to Gloo Mesh

[mihmatache]

Problem Statement

The current SMH trust model implies changing the root certificate in all managed clusters. This is not a desired trust model, especially when dealing with multiple entities, each with it's own security requirements

Proposal

Each mesh should have it's own trust domain, and different TLS exchanges should happen at the cluster edge.

A possible solution would be configuring the ingress gateway in each cluster as an edge proxy that supports mTLS connection from the request originator, and initiates a new different mTLS connection to forward the request to the desired server.

This would help in the context where different clusters use different authentication protocols, and would limit the scope of any security change to the gateways.

Problems to solve:

• Managing certificates from multiple CA sources
• Managing different types of ingress gateways
• Passing/Persisting the configuration to the Ingress Gateways

Steps

• [ ] Propose implementation general design
• [ ] Discuss proposal with the community
• [ ] Start implementing this feature for Istio first (since Istio is already supported by SMH)

[christian-posta]

Here's some reference to Istio spiffe bundle support:

https://github.com/istio/istio/blob/ef0336e6b5c986d43bed8b2be71908d37984930b/pkg/spiffe/spiffe.go#L274

https://github.com/istio/istio/blob/ef0336e6b5c986d43bed8b2be71908d37984930b/pilot/pkg/features/pilot.go#L323

[danielvladco]

Here is how a potential istio implementation might look like:

Cluster 1 is set up with a secure gateway configured with TLS mode MUTUAL and a secret containing the certificate, the key (generated by CA: A) and the certificate authorities of clusters that it should trust (CA: B).

Cluster2 is set up with destination rules configured with TLS mode MUTUAL, certificate and key generated by CA:B and a reference to CA: A. We also might need to specify the sni option in destination rules.

This approach allows each workload to authenticate rather than authenticate at the egress level. Also we might authenticate only certain service accounts rather than an entire cluster

ref: https://istio.io/latest/docs/reference/config/networking/gateway/#ServerTLSSettings-TLSmode https://istio.io/latest/docs/reference/config/networking/destination-rule/#ClientTLSSettings

[john-a-joyce]

FWIW - the current documentation on "limited trust" is here: https://github.com/solo-io/service-mesh-hub/blob/08a189e63f2bf6003ab8e0bd719591adc4a9318e/api/networking/v1alpha2/virtual_mesh.proto#L78 and has this model:

                        cluster 1 MTLS                   shared MTLS                            cluster 2 MTLS

client/workload <-----------> egress gateway <----------> ingress gateway <--------------> server

[liorokman]

Maybe using the procedure for cross-certification between two CAs is useful here?

Each side would have its own CA, but the private key pair used by CA belonging to one side would be reused to generate a CSR that can be signed by the CA on the remote side. That would mean that each certificate generated by each one of the CAs can be verified using two paths - the local CA and the remote CA.

This would allow mTLS to work directly between workloads, with the gateway performing TLS passthrough, based on SNI.