If you are running a k6 cloud test, you will be utilizing k6's cloud infrastructure. These are dynamically allocated from our cloud providers and we do not know the source IP until the test is running.
If you are streaming results to k6 Cloud utilizing k6 run -o cloud myscript.js you SHOULD NOT need to whitelist anything.
To open your firewall to k6 cloud traffic, you have multiple options. Depending on your business needs, one may be a better fit than another.
Open up your firewall to the whole range of AWS IP addresses used by the load zones where you want to run your load test from. To use AWS to generate traffic, you will have to open up your firewall to a large IP range.
Use HTTP headers, URL query parameters, or unique data that identifies the traffic as belonging to your load test, This requires that your firewall has support for scanning application payload data and apply rules based on what it finds.
Here is a more samples on how to complete the different options above:
We list the full range of IP addresses used in this article. You will need to whitelist the IP ranges for the load zones you are utilizing. Please note the JSON file at the bottom of the article.
You can add custom HTTP headers to any request in your script. You'll need to add the header to every single request.
If you're not dependent on having the simulated users in your load test to be a certain user agent, you can also use the userAgent option to set the "User-Agent" header for all subsequent requests. That header could then contain your token value and you would not have to modify every single HTTP request in your script. In the below example the user agent is set to MyK6UserAgentString/1.0
You might also use query parameters, if it doesn't interfere with the functionality of your application:
Another option would be to request content from a certain hostname that is not in the DNS, but your site would of course need to be configured to respond to requests for that hostname. This is how you do it on the k6 cloud's side:
Of course, this last solution requires that your firewall terminates SSL traffic, otherwise it will not see the Host header in unencrypted form. You could also use unencrypted HTTP, but get a bit less security.