Support for upstream network filter

[surki]

Title: We have a need for upstream RBAC or ext-authz filters

Description: We are using Envoy as forward proxy (i.e., "dynamic forward proxy"). We would like to apply some network policy, specifically on the IPs it is connecting to. So we would need support for that in the upstream context.

There was some discussion here, so I went ahead and made the changes to see if existing network RBAC filter would work in the context of upstream. The changes are here and it seems to work.

Few quick observations:

• Since the existing RBAC filter assumes ingress/downstream, the names are inverted, it looks bit confusing to use it this way.

  
  clusters:
  - name: foo
  ....
  ....
  ....
  filters:
  - name: envoy.filters.network.rbac
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.network.rbac.v3.RBAC
      rules:
        action: DENY
        policies:
          "loopback-linklocal":
            permissions:
            - any: true
            principals:
            - or_ids:
                ids:
                - remote_ip:
                    address_prefix: 127.0.0.0
                    prefix_len: 8
                - remote_ip:
                    address_prefix: 169.254.0.0
                    prefix_len: 16

- When policy is enforced (say by closing connection), the connection termination information is not propagated back (it is kept in the context of upstream connection context)

I am wondering what's the right approach should be here? 

1. Create a new upstream RBAC filter with its own .proto definition with the names fixed/relevant in the upstream context
2. Re-use the ingress filter as it is (like done  [here](https://github.com/surki/envoy/commit/25720a3229f1cbbf26487df0a29327121094b715)) and just fix up the documentation that when used in upstream context, fields are inverted etc.

Option 1 might be better for long term.

[lizan]

@yangminzhu @yanavlasov

[mattklein123]

I agree that (1) is the right approach, with sharing as much code as possible. It would be great to see this happen!

[surki]

FYI I just started looking into this, I will send a draft version for feedback soon

[wjrbetts]

We would love to see this feature so that we can limit the damage that a semi-trusted client/server can do via a dynamic forward proxy.

It looks like the PR that @surki raised was closed while waiting for changes around upstream filters to stabilise. Has this stabilised now @alyssawilk?

[alyssawilk]

HTTP upstream filters have stabilized but not sure how much that relates to network filters or what you need beyond https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/upstream_filters

[wjrbetts]

Thanks. I got the impression from the thread in https://github.com/envoyproxy/envoy/pull/21985 that progress on that stopped to let the http upstream filters stabilise, but perhaps not.

Thanks for the link. Is support for upstream filters out of the box something we are likely to see soon?

[alyssawilk]

As always with Envoy support is going to be determined by who needs what. Upstream filters largely work, and further functionality will be added as needed. Individual network and HTTP downstream filters will be ported to be upstream filters as needed by the community. There's no roadmap or timeline for this sorry.