Will the atlassian-ip-ranges option available for 1x and 2x sizes after the 17th of September

[Benjamin Fichtner]

Bitbucket Pipelines recently announced a new feature of 4x and 8x step sizes and the migration of 1x and 2x step size machines to a new runtime[1].  I like this feature very much,  though the dynamic IP ranges that need to be allow-listed are a little downer.

The documentation states that if you are using IP allow listing for your corporate firewall, need to allow > 4000 IP address ranges of AWS. Certain firewalls, e.g. AWS security could not store this amount of IP addresses easily (60 rules are the maximum here). So as one option you would need to create a security group, with 60 sub security groups and keep them up to date. I suspect this is also not possible on certain hardware appliances.

According to the documentation there is another option for the sizes 4x and 8x. You can us the "atlassian-ip-ranges" option to ensure, that request are coming from a limited pool of IP addresses.

From the documentation it is not clear, if this will be also rolled out to 1x and 2x size steps after those steps are migrated of the 1x and 2x sizes to the new run time after 17th of September or if this is exclusive for 4x and 8x steps.

1) Could you clarify on that? Will the atlassian-ip-ranges opt-in option be also available for 1x and 2x step sizes after the migration on?

2) Does the use of atlassian-ip-ranges have limitations in comparison to not using it?

Thank you very much for your time and this new feature.

[1] -  https://bitbucket.org/blog/announcing-our-new-ci-cd-runtime-with-up-to-8x-faster-builds

[2] - https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/

[Theodora Boudale · Accepted solution]

Hi Benjamin and welcome to the community.

The atlassian-ip-ranges will be available only to 4x and 8x steps after the migration of 1x and 2s steps to the new runtime.

If you prefer to use the limited range of IPs after this migration, the step will need to be either a 4x or an 8x step. Please note you only have to add this configuration for steps that must use the restricted IP range, this may not be all of your steps.

There are no limitations when using atlassian-ip-ranges.

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

Kind regards,
Theodora

[Benjamin Fichtner]

Thank you very much for the answer. That clarifies my open question.

This is unfortunate. It multiply the costs of such requests by 4x / 8x. Allowing the amount of IP ranges can cause compliance issues and is also not easily possible for systems running inside AWS.

Furthermore, If I understand it correct, also anyone who setup OIDC with IP restrictions following the Atlassian example would encounter failed OIDC connections after the migration.

[Theodora Boudale]

Hi Benjamin,

For steps using OIDC and remaining at 1x or 2x size, the new IP address ranges will need to be whitelisted prior to 17th September 2024 so that the builds don't fail.

Kind regards,
Theodora

[stanchev]

I also find it very unfortunate. Why do you have to pay significantly more for steps that only require static IP's and are not CPU-intensive...

Why not just add a new option to use the “atlassian-ip-ranges” in a 1x or 2x sizes?

Regards

[Theodora Boudale]

Hi @stanchev,

Thank you for reaching out.

One of Bitbucket's Product Managers created an article in community providing some context on this:

• https://community.atlassian.com/t5/Pipelines-articles/Sharing-Some-Context-On-Our-New-Pipelines-Step-Sizes/ba-p/2751524

If you have any questions, you are more than welcome to post them as a comment in this article I shared.

Kind regards,
Theodora