Please help me to whitelist the ranges for BItbucket pipeline

[Bhanu Mulamalla]

We have whitelisted all the IP ragnes which are mentioned for bitbucket pipeline still we are getting the whitleist IP range . For each run the IP address is changing please help

current outbound ip 35.174.153.169 is not whitelisted (34.199.54.113, 34.232.25.90, 34.232.119.183, 34.236.25.177, 35.171.175.212, 52.54.90.98, 52.202.195.162, 52.203.14.55, 52.204.96.37, 34.218.156.209, 34.218.168.212, 52.41.219.63, 35.155.178.254, 34.216.18.129, 35.160.177.10, 34.216.18.129)

[Theodora Boudale]

Hi Bhanu and welcome to the community!

We have recently updated our 1x/2x size option builds to operate from new, broader IP ranges.

If you need your pipeline builds to operate from a more limited set of IP addresses, consider using the atlassian-ip-ranges configuration available with our 4x/8x steps. These size options are only available for builds running under a paid Bitbucket Cloud plan (Standard or Premium). This setup offers better security by narrowing down the IP addresses used. You can find more information about this configuration here.

To provide some extra context on this change and the requirement for 4x/8x steps to access restricted IPs, please see the discussion re: this topic from the Pipelines community space here.

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.

If the 4x/8x step sizes are not suitable for you, you can use 1x/2x and access the full list of IP ranges in AWS JSON format. This list can be filtered specifically for EC2 or S3 resources in the us-east-1 and us-west-2 regions.

Note: The IP ranges listed are managed by Amazon and are subject to change. Therefore, 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). Allowlisting the entire range of AWS IPs can potentially expose your system to risks.

Having said that, we suggest using the 4x/8x runtime option. By choosing the 4x/8x runtime, you benefit from increased performance and a more controlled network environment. This makes it an excellent choice if you want to prioritize security and efficiency in your CI/CD processes.

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

Kind regards,
Theodora

[Basiel Smitz]

Hello Theodora,

I’m encountering a similar issue where my pipeline is unable to SSH into our AWS EC2 instances from Bitbucket Pipelines presumably due to the recent IP changes. I added all suggested IPs from the Atlassian IP Ranges documentation to a security group associated with our EC2 instances, and this setup worked until recently. However, now I’m getting timeout errors, seemingly because the pipeline is using an IP not listed in the documentation.

To confirm, I temporarily allowed 0.0.0.0/0 in the security group, and the SSH connection worked as expected—I've since removed this rule for security.

I understand your suggestion to use OpenID Connect (OIDC) for secure authentication, but I’m unclear on how OIDC would facilitate direct SSH access to our EC2 instances. My current setup uses rsync for deployment, which could potentially be replaced by an AWS CLI deployment option or related pipe. However, I still need SSH access to run a post-deploy bash script on the EC2 instance. 

Would you be able to clarify whether there is a recommended approach to enable secure SSH access from Bitbucket Pipelines without opening the security group to all IPs

[Theodora Boudale]

Hi Basiel,

The Atlassian IP ranges are used only by 4x and 8x size steps that have the atlassian-ip-ranges: true flag.

You can adjust the step that performs rsync as follows:

pipelines:
  default:
    - step:
        size: 4x
        runtime:
          cloud:
            atlassian-ip-ranges: true
        script:
          - echo "This step with rsync will use atlassian-ip-ranges"

I have highlighted in bold the options you need to add to the step so that it uses the more restricted set of IPs in Atlassian IP ranges.

The example is from this documentation:

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

Kind regards,
Theodora

[Cyrus Chan]

delete

[Basiel Smitz]

Hello Theodora, 

Thank you for the clarification. My main issue has been resolved. SSH does work again by implementing the x4 size in my pipeline step. 

However, I would appreciate clarification on the second part of my original question. Specifically, would utilizing OpenID Connect with the default step size facilitate SSH access to an EC2 instance? My understanding is that OIDC primarily aids in authorizing AWS CLI commands and may not directly support SSH connections. Is this correct? What about including an STS command? I am inclined to believe this will have no impact on the SSH connection.

- aws sts assume-role-with-web-identity --role-arn arn:aws:iam::XXXXXX:role/projectx-build --role-session-name build-session  --web-identity-token "$BITBUCKET_STEP_OIDC_TOKEN" --duration-seconds 100

Until recently, I was able to SSH into EC2 instances protected by security groups without issues. Can I conclude that the recent changes have made SSH access to secured EC2 instances a feature available only with paid plans?

[Theodora Boudale]

Hi Basiel,

OIDC indeed cannot facilitate SSH access.

Can I conclude that the recent changes have made SSH access to secured EC2 instances a feature available only with paid plans?

Access to secured EC2 instances from 1x and 2x steps (either on the free or on a paid plan) is still possible, but it would require allowlisting a much larger number of IP ranges (and for that reason, it is not a recommended approach). See from my answer above:

If the 4x/8x step sizes are not suitable for you, you can use 1x/2x and access the full list of IP ranges in AWS JSON format. This list can be filtered specifically for EC2 or S3 resources in the us-east-1 and us-west-2 regions.

One of Bitbucket's Product Managers has posted an article to provide more context on these changes:

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

If you have any questions or feedback related to this article, you are more than welcome to post a comment right below the article.

Kind regards,
Theodora

[Theodora Boudale]

Hi Basiel,

I had one more suggestion from my team, in case you don't want to use SSH: you could use OIDC with AWS session manager.

This is our documentation about OIDC:

• https://support.atlassian.com/bitbucket-cloud/docs/integrate-pipelines-with-resource-servers-using-oidc/
  
• https://support.atlassian.com/bitbucket-cloud/docs/deploy-on-aws-using-bitbucket-pipelines-openid-connect/

You can find info on how to set up AWS session manager here:

• https://blowstack.com/blog/how-to-set-up-aws-session-manager

Kind regards,
Theodora