envoyproxy/envoy

Support for upstream network filter

Open

#21 178 ouverte le 6 mai 2022

Voir sur GitHub
 (7 commentaires) (1 réaction) (0 assignés)C++ (5 373 forks)batch import
area/rbachelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

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.

Guide contributeur