area/rbachelp wanted
Metriche repository
- Star
- (27.997 star)
- Metriche merge PR
- (Merge medio 8g) (378 PR mergiate in 30 g)
Descrizione
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?
- Create a new upstream RBAC filter with its own .proto definition with the names fixed/relevant in the upstream context
- 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.