WiP Add Bumping filter

[liverbirdkte]

Implement bumping filter

Add a new network filter bumping filter
Implement cert prefetch based on tcp proxy filter

Risk Level: Low
Testing:
Docs Changes: N/A
Release Notes: N/A
Fixes #22581

Signed-off-by: leizhang [email protected]

[repokitteh-read-only]

Hi @liverbirdkte, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #22582 was opened by liverbirdkte.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @lizan
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #22582 was opened by liverbirdkte.

see: more, trace.

[liverbirdkte]

should I add a writeDisable method to connection to stop triggering write event? I have to make sure prefetch cert happens before downstream handshake.

[yanavlasov]

@liverbirdkte Thank you for the contribution. However you did not indicate if this extension is sponsored by an existing maintainer. Please see the guideline https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md

Without sponsorship you can add this extension to the contrib directory. However you still need to add tests and documentation.

[jmarantz]

assigning to Matt to first validate whether this should be an 'extension' or should be in 'contrib'.

Also you need to fix format before CI can really run.

/wait

[LuyaoZhong]

@liverbirdkte is on vacation, he will be back next week. I believe he was to ask for comments, this PR is not ready for test and merge.

It seems not only us require this feature. During discussion on #18928, others want this feature as well. So maybe we should let it be a core extension.

Not sure how to define if a filter is worth to be a core extension. But if it is not worth after your evaluation, contrib extensions still require an end-user sponsor according to https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md, then VMware can support us, we are collaborating with them.

cc @yanavlasov @jmarantz @mattklein123

[mattklein123]

Then VMware can support us, we are collaborating with them.

VMware is not an end user. Unless there is a known production use case this will need to go into contrib, and it can only go into contrib if there is a vetted end user sponsor. I'm becoming increasingly uncomfortable with the number of Intel extensions that have no known use production case. Feel free to follow up over email. Thanks!

[sergiopozoh]

VMware is not an end user. Unless there is a known production use case this will need to go into contrib, and it can only go into contrib if there is a vetted end user sponsor. I'm becoming increasingly uncomfortable with the number of Intel extensions that have no known use production case. Feel free to follow up over email. Thanks!

@mattklein123 hi, VMware users of this extension here. We have been using for years now Envoy as part of the Istio distribution that is embedded in Tanzu Service Mesh (SaaS). Contour also uses Envoy. Now, Envoy is a core component of a new product in the multi-cloud security space that runs in a PoP and is a SaaS service (user to app, and app to app traffic). If the inclusion criteria (as Users) is the one in https://github.com/envoyproxy/envoy/blob/main/SECURITY.md#membership-criteria then I believe that we fit in at least one of these categories

• An actively maintained distribution of Envoy components. An example is "SuperAwesomeLinuxDistro" which offers Envoy pre-built packages. Another example is "SuperAwesomeServiceMesh" which offers a service mesh product that includes Envoy as a component.
• Offer Envoy as a publicly available infrastructure or platform service, in which the product clearly states (e.g. public documentation, blog posts, marketing copy, etc.) that it is built on top of Envoy. E.g., "SuperAwesomeCloudProvider's Envoy as a Service (EaaS)". An infrastructure service that uses Envoy for a product but does not publicly say they are using Envoy does not generally qualify (see option 3 that follows). This is essentially IaaS or PaaS. If you use Envoy to support a SaaS, e.g. "SuperAwesomeCatVideoService", this does not generally qualify.
• Note that in this context "end user" is defined as an organization that directly operates Envoy in order to serve traffic for 1st party use cases. The 1st party use case can be either internal or external facing. Critically, vendors of cloud native software and solutions can also be end users. Being a vendor does not preclude an organization from being an end user as long as it satisfies the 1st party usage criteria.

There is a lot of documentation of VMware regarding these initiatives, including the full disclosure of the use of Envoy.

If VMware does meet the inclusion criteria now, it may be worth reviewing VMware as the last review was more than a year ago (06/21). If VMware does not meet it, could you please add more detail / help me better understand the criteria?

[mattklein123]

If VMware is going to use this in a product, then it probably shouldn't be in contrib. But either way I would prefer to get some bake time on it as it has unclear usage to me. So since you will need to compile this yourself anyway, why don't you just maintain a private extension for a bit and then we can circle back for upstream inclusion once it has been vetted? Thank you.

[sergiopozoh]

If VMware is going to use this in a product, then it probably shouldn't be in contrib. But either way I would prefer to get some bake time on it as it has unclear usage to me. So since you will need to compile this yourself anyway, why don't you just maintain a private extension for a bit and then we can circle back for upstream inclusion once it has been vetted? Thank you.

Yes we can do that. What would be an estimated baking time (with very high error margin)? I just want to make sure that if we use an "internal" extension, it can be upstreamed or in the end we would end up with a custom Envoy (and we do not want this in a production release of our products).

Just to be clear: any product that uses Envoy in a data plane that manages inter cloud or user to cloud traffic needs TLS interception. I believe that's the reason of the interest of the community.

[mattklein123]

If this is going to be in a public product and you are going to use public envoy, by definition it can't be in contrib. At the same time, if the feature never ships, we are left with code that very likely no one will use as we have not received this request before now.

So I'm happy to see this as a non-contrib feature with intel/vmware sponsorship, but let's get a little internal testing time and then we can circle back in a couple of weeks to a month? Feel free to email me if you want to discuss further. Thank you.

[sergiopozoh]

If this is going to be in a public product and you are going to use public envoy, by definition it can't be in contrib. At the same time, if the feature never ships, we are left with code that very likely no one will use as we have not received this request before now.

So I'm happy to see this as a non-contrib feature with intel/vmware sponsorship, but let's get a little internal testing time and then we can circle back in a couple of weeks to a month? Feel free to email me if you want to discuss further. Thank you.

that makes sense, Matt. Thank you.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[github-actions]

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[liverbirdkte]

Hi @mattklein123 @lizan @ggreenway , to demonstrate how the bumping filter works, we have submitted a patch to demo all the related components(bumping filter, cert provider framework, local cert provider instance) at #23192. We tested it with some sites and things work fine. Could you take a look if the patch is on the right direction? Then we could polish and update each components separately for further review. Thanks.