You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need a mechanism to prevent malicious use of the probe service. For example the probes will often be running within customers own networks, but connected to the outside world. We need to ensure that users cant craft nasty checks that could be used to attach internal servers that the prove server may have access to.
The basic thought here is to proved a way to set a whitelist and blacklist of IP address/ranges.
When checks are executing, they should consult these lists to determine if they can perform the check on the target IP address.
The text was updated successfully, but these errors were encountered:
we may want to make the main org an exception to this restriction.
because using a tool like env-load you typically want to use a dummy local endpoint (ideally localhost on each collector) for efficiency reasons to aim your large workload on.
i would rather not complicate the entire process for such a single rare use case.
If you want to do load testing, then dont use an IP that is blacklisted. A simple solution would be to just configure a dummy interface on each of the collectors with a non-blacklisted ip.
We need a mechanism to prevent malicious use of the probe service. For example the probes will often be running within customers own networks, but connected to the outside world. We need to ensure that users cant craft nasty checks that could be used to attach internal servers that the prove server may have access to.
The basic thought here is to proved a way to set a whitelist and blacklist of IP address/ranges.
When checks are executing, they should consult these lists to determine if they can perform the check on the target IP address.
The text was updated successfully, but these errors were encountered: