-
Notifications
You must be signed in to change notification settings - Fork 64
Description
we operate the application in kubernetes and want to avoid access to internal ressources via request-baskets, as it can be turned into an open proxy. the most flexible use is probably to provide the ability to allow/deny domains and ip ranges.
example use cases:
-
request-baskets --allow-domain example.com --deny-domain dev.example.com
baskets can only be configured with URLs withexample.com
as domain (e.g.https://api.prod.example.com),
except URLs pointing todev.example.com
(e.g.https://api.dev.example.com) -
request-baskets --deny-domain cluster.local
baskets can forward any URL except to URLS under the
cluster.localdomain -
request-baskets --deny-address 127.0.0.0/8
baskets can not forward URLs pointing to the loopback
interface -
request-baskets --deny-private-address
shortcut for denying forwards to all addresses designated
for private use (192.168.0.0/16,172.16.0.0/12,
10.0.0.0/8) by the IANA -
request-baskets --allow-address 192.168.1.0/24 --deny-address 192.168.1.1/32 --deny-address 192.168.1.254/32
only URLs resolving to a class B private net are allowed,
except192.168.1.1and192.168.1.254
by default, everything is allowed and nothing is denied (just as
before). denials are applied after allowances, so that you
can allow on a broad scale and deny granular.
given that the validation only has to be performed on basket
creation/updates, the resource overhead for domain resolution
should be relatively low.