Add EgressMITMTrustReconciler

[haiyanmeng]

It Watches ate-system/egress-mitm-ca-pool, unmarshals it with localca.Unmarshal, and server-side-applies a ClusterTrustBundle whose spec.trustBundle is the PEM concatenation of every CA's RootCertificate.Raw, in pool order, and nothing else.

A part of #823

Context:
#932 plans to add a clusterTrustBundle data source to SystemInfo volumes (#802) that projects the trust anchors of a named ClusterTrustBundle (certificates.k8s.io/v1beta1) to a PEM file in the volume, the substrate analog of the [Kubernetes clusterTrustBundle projected volume source] (https://kubernetes.io/docs/concepts/storage/projected-volumes/#clustertrustbundle).

After both #823 and #932 land, Substrate users will be responsible for wiring the provided ClusterTrustBundle for ate-egress-trust into its trust store.

It's a good idea to open an issue first for discussion.

• Tests pass
• Appropriate changes to documentation are included in the PR

[Eitan Yarmush (EItanya)]

Can you give a little more context in the PR description of why this change is necessary and how it fits into the broader MITM effort

[haiyanmeng]

Can you give a little more context in the PR description of why this change is necessary and how it fits into the broader MITM effort

Added a Context section in the PR description. Let me know if it helps.

[Eitan Yarmush (EItanya)]

Can you give a little more context in the PR description of why this change is necessary and how it fits into the broader MITM effort

Added a Context section in the PR description. Let me know if it helps.

It does, but honestly this feels like a slightly overcomplicated solution. These are really an implementation detail of the system. Do we need this type of controller, or can we just have a flag or something to automount. Not to mention we're going to need to set special env vars etc, to get this to work.

[haiyanmeng]

Can you give a little more context in the PR description of why this change is necessary and how it fits into the broader MITM effort

Added a Context section in the PR description. Let me know if it helps.

It does, but honestly this feels like a slightly overcomplicated solution. These are really an implementation detail of the system. Do we need this type of controller, or can we just have a flag or something to automount. Not to mention we're going to need to set special env vars etc, to get this to work.

Taahir Ahmed (@ahmedtd) , Bowei Du (@bowei) , WDYT?

[Taahir Ahmed (ahmedtd)]

Can you give a little more context in the PR description of why this change is necessary and how it fits into the broader MITM effort

Added a Context section in the PR description. Let me know if it helps.

It does, but honestly this feels like a slightly overcomplicated solution. These are really an implementation detail of the system. Do we need this type of controller, or can we just have a flag or something to automount. Not to mention we're going to need to set special env vars etc, to get this to work.

Atelet can't depend on internal implementation details of the egress controller if we expect implementers to be swapping in their own egress implementations. So there needs to be a contract for how the egress implementation publishes the roots.

If there's a simpler way to do this, we're open to suggestions.

[Eitan Yarmush (EItanya)]

Can you give a little more context in the PR description of why this change is necessary and how it fits into the broader MITM effort

Added a Context section in the PR description. Let me know if it helps.

It does, but honestly this feels like a slightly overcomplicated solution. These are really an implementation detail of the system. Do we need this type of controller, or can we just have a flag or something to automount. Not to mention we're going to need to set special env vars etc, to get this to work.

Atelet can't depend on internal implementation details of the egress controller if we expect implementers to be swapping in their own egress implementations. So there needs to be a contract for how the egress implementation publishes the roots.

If there's a simpler way to do this, we're open to suggestions.

That makes sense, can I think about this a bit before we merge?

I was hoping the user wouldn’t have to think about injecting the CA everywhere, and what env vars/files to think about.

I do agree that we need a way to explain this to the system, but I’m wondering put loud whether it should be a higher level API.