envoyproxy/envoy

Support for upstream network filter

Open

#21,178 opened on 2022年5月6日

GitHub で見る
 (7 comments) (1 reaction) (0 assignees)C++ (5,373 forks)batch import
area/rbachelp wanted

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (平均マージ 8d) (30d で 378 merged PRs)

説明

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) and just fix up the documentation that when used in upstream context, fields are inverted etc.

Option 1 might be better for long term.

コントリビューターガイド