Pipelines Failing Due to Bitbucket Using Unexpected IPs

[Iune]

We are currently developing a project where our resources are protected by a firewall that only allows traffic from whitelisted Bitbucket IPs, as specified in the official documentation (including the most recently updated 104.192.136.0/21 185.166.140.0/22 13.200.41.128/25). However, we are experiencing pipeline failures because Bitbucket seems to be using IPs that are not included in the official Bitbucket IP ranges (note that we don't use custom runners).

Here are some of the unexpected IPs we've identified in our logs:

54.236.243.250, 3.89.197.161, 44.204.86.241, 3.236.182.171, 44.212.34.113, 54.242.231.227, 54.145.173.150, 44.192.120.9, 3.231.55.79, 34.226.203.174, 98.80.175.170, 3.81.12.0

We are concerned about the security of our environment and would like to understand what might be causing this issue before making any changes to the IPs allowed by our firewall. Could you please confirm whether these IPs are valid Bitbucket IPs? If not, what could be happening?

[Alfonso Fernández Perdiguero]

Hello Lune! We're also having exactly the same issue.

In our case the IPs that are being shown are these:

75.101.235.132

3.81.17.66

44.202.51.50

These are only for 3 pipeline executions, I bet that if I keep launching them, I will receive a completely different IP everytime, from both your results and mine.

Bitbucket Team, let us know if we can be of more help, we'll gladly support you!

Kind regards, AFP.

[Theodora Boudale]

Hi @Iune and @Alfonso Fernández Perdiguero,

We recently migrated 1x- and 2x-size build steps to a new runtime and they now operate from new, broader IP ranges. This was announced here:

• https://bitbucket.org/blog/evolving-bitbucket-pipelines-to-unlock-faster-performance-and-larger-builds
• https://bitbucket.org/blog/announcing-our-new-ci-cd-runtime-with-up-to-8x-faster-builds

The machines that execute all steps on Atlassian Cloud Infrastructure are hosted on Amazon Web Services.

An exhaustive list of IP addresses that the traffic may come from on AWS can be found by using the following endpoint:

• https://ip-ranges.amazonaws.com/ip-ranges.json

filtering to records where the service equals EC2 or S3, and using the us-east-1 and us-west-2 regions.

Important Note: The IP addresses provided via this endpoint are managed by Amazon and are subject to change. We recommend regularly checking this endpoint and updating your firewall's IP list accordingly. Additionally, consider exploring automation options to streamline updating IPs in response to changes.

You can use https://thameera.com/awsip/ to check which CIDR block a given IP belongs to and confirm it's from Amazon Web Services. I checked the IPs provided by both of you and they all belong to ranges listed in https://ip-ranges.amazonaws.com/ip-ranges.json.

If you require your builds to run from a more limited set of IP addresses, you can use the atlassian-ip-ranges runtime configuration in your yml file, available only on 4x/8x steps and only with the Standard or Premium plan. This configuration is documented here:

• https://support.atlassian.com/bitbucket-cloud/docs/step-options/#Runtime

You will then need to whitelisted only a more limited set of IP ranges, listed here:

• https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/#Atlassian-IP-ranges

Please Note: Using larger step sizes may have billing implications. 4x steps use four times the number of build minutes of 1x steps and 8x steps use eight times the build minutes of 1x steps.

Please feel free to reach out if you have any questions.

Kind regards,
Theodora