envoyproxy/envoy

Support for upstream network filter

Open

#21.178 aberto em 6 de mai. de 2022

Ver no GitHub
 (7 comments) (1 reaction) (0 assignees)C++ (5.373 forks)batch import
area/rbachelp wanted

Métricas do repositório

Stars
 (27.997 stars)
Métricas de merge de PR
 (Mesclagem média 8d) (378 fundiu PRs em 30d)

Description

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.

Guia do colaborador