Our firewall requires allow listing the IPs bitbucket pipelines uses. We have had these configured for quite some time but in the last week the IPs seem to have changed. I have checked documentation here
I added a step to confirm public IP
```
Hi everyone,
We have recently updated our 1x/2x size option builds to operate from new, broader IP ranges.
The documentation of Bitbucket Pipelines Cloud IP addresses is divided into two sections:
Section 1: Valid IP addresses for Bitbucket Pipelines build environments
This section applies to 1x/2x step sizes (or 4x/8x steps that have not been explicitly flagged to use atlassian-ip-ranges). An exhaustive list of IP addresses from which the traffic may originate on AWS can be obtained by using the following endpoint. You should filter records where the service equals EC2 or S3, and focus on the us-east-1 and us-west-2 regions. However, we do not recommend using these IP ranges as a security control due to their broad nature.
Please keep in mind that the endpoint https://ip-ranges.amazonaws.com/ip-ranges.json includes CIDR blocks, so you may not find the exact IP address such a step uses in that list.
You can use this tool https://thameera.com/awsip/ to confirm that a certain IP address is from AWS and which CIDR block it belongs to. When you get the CIDR block, you can search it in https://ip-ranges.amazonaws.com/ip-ranges.json to confirm it's listed there.
Section 2: Atlassian IP Ranges
This section pertains to steps specifically configured to use Atlassian IP ranges. These are applicable only to 4x and 8x size steps that have the atlassian-ip-ranges: true
flag enabled. The step sizes 4x and 8x are only available for builds running under a paid Bitbucket Cloud plan (Standard or Premium).
For teams who need their builds to run from a more restricted set of IP addresses, we recommend using this option. This option provides enhanced security by limiting the IP addresses to a smaller, more manageable list. This configuration does not need to apply to all steps in a pipeline, just the steps that access secure resources.
Please Note: Opting for larger step sizes (4x/8x) may impact billing. We encourage you to review the relevant documentation on step sizes here to understand these implications fully.
Important Note: Relying solely on IP-based firewalls for securing your infrastructure is not recommended. Instead, consider implementing secure authentication methods for any services exposed to Bitbucket Pipelines, such as using OpenID Connect (OIDC).
Alternatively, you may consider utilizing Bitbucket's pipeline runners. Runners enable you to execute builds in Pipelines on your own infrastructure. Additionally, as your runner is hosted on your own infrastructure, you will have greater flexibility regarding the list of IP addresses to permit.
I hope this helps. Please let me know if you have any additional questions.
Kind regards,
Theodora
The same thing.
Bitbucket public IPs are: 3.239.227.205, 107.20.98.94, 3.219.33.11, 34.205.69.158, 54.167.148.39.
But no one of them is presented in https://ip-ranges.amazonaws.com/ip-ranges.json;
Same here.
I'm getting: 18.205.154.203 & 107.23.204.99 which isn't found in the whitelist.
All our pipelines are failing due to this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi everyone,
We have recently updated our 1x/2x size option builds to operate from new, broader IP ranges.
The documentation of Bitbucket Pipelines Cloud IP addresses is divided into two sections:
Section 1: Valid IP addresses for Bitbucket Pipelines build environments
This section applies to 1x/2x step sizes (or 4x/8x steps that have not been explicitly flagged to use atlassian-ip-ranges). An exhaustive list of IP addresses from which the traffic may originate on AWS can be obtained by using the following endpoint. You should filter records where the service equals EC2 or S3, and focus on the us-east-1 and us-west-2 regions. However, we do not recommend using these IP ranges as a security control due to their broad nature.
Please keep in mind that the endpoint https://ip-ranges.amazonaws.com/ip-ranges.json includes CIDR blocks, so you may not find the exact IP address such a step uses in that list.
You can use this tool https://thameera.com/awsip/ to confirm that a certain IP address is from AWS and which CIDR block it belongs to. When you get the CIDR block, you can search it in https://ip-ranges.amazonaws.com/ip-ranges.json to confirm it's listed there.
Section 2: Atlassian IP Ranges
This section pertains to steps specifically configured to use Atlassian IP ranges. These are applicable only to 4x and 8x size steps that have the atlassian-ip-ranges: true
flag enabled. The step sizes 4x and 8x are only available for builds running under a paid Bitbucket Cloud plan (Standard or Premium).
For teams who need their builds to run from a more restricted set of IP addresses, we recommend using this option. This option provides enhanced security by limiting the IP addresses to a smaller, more manageable list. This configuration does not need to apply to all steps in a pipeline, just the steps that access secure resources.
Please Note: Opting for larger step sizes (4x/8x) may impact billing. We encourage you to review the relevant documentation on step sizes here to understand these implications fully.
Important Note: Relying solely on IP-based firewalls for securing your infrastructure is not recommended. Instead, consider implementing secure authentication methods for any services exposed to Bitbucket Pipelines, such as using OpenID Connect (OIDC).
Alternatively, you may consider utilizing Bitbucket's pipeline runners. Runners enable you to execute builds in Pipelines on your own infrastructure. Additionally, as your runner is hosted on your own infrastructure, you will have greater flexibility regarding the list of IP addresses to permit.
I hope this helps. Please let me know if you have any additional questions.
Kind regards,
Theodora
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Reddit has your answer:
https://www.reddit.com/r/sysadmin/comments/1grrh0w/comment/lx8rmo8/
The solution is to open ssh ports on your firewalll to the world or get an other task runner. I'm thinking about the latter, so are the others I know that can't deploy for yet another day.
The thing I don't understand is how this is affecting loads of people I personally know that work with pipelines and extrapolating from that there must be scores of people being bitten by this and seeing their CI/CD that worked fine for years fail. How come it's so quiet about this on this fun community site where people get all kinds of awards for helping? Don't they care, doesn't Atlassian care?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.