Summary

When using Bitbucket Cloud Pipelines to interact with a remote instance, the IP address of the Pipeline does not meet expectations making it difficult to add to an IP allowlist.

Environment

Bitbucket Cloud Pipelines (this does not apply to self-hosted Runners)

Diagnosis

Adding a step within the pipeline's runtime can help identify/confirm the IP of the run. Each run/step is independent and thus will acquire a different IP.

script:
  - curl ifconfig.me

You can validate what AWS subnet a particular IP is from, based on your "curl ifconfig.me" output, via a tool like https://thameera.com/awsip/

Cause

Bitbucket Pipelines has two pools of potential IPs from which to pull from based on the configuration within your "bitbucket-pipelines.yml" file. If no customizations are provided, or if you are using a "size: 1x" (the default) or "size: 2x" container, then the build will default to any available IP within the AWS EC2 space within the us-east-1 or us-west-2 regions. You can see the full list of IPs available to AWS via this link, however, you can also use tools like "curl" to help filter this list to just the relevant IPs as shown below.

Raw IP CIDR blocks for AWS EC2

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes.[] | select(.service == "EC2" and (.region == "us-west-2" or .region == "us-east-1")).ip_prefix'

JSON formatted AWS EC2 details

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes.[] | select(.service == "EC2" and (.region == "us-west-2" or .region == "us-east-1"))'

Secondly, you can leverage the "atlassian-ip-ranges" IP pool by updating your pipelines yaml config to include the necessary flags. This secondary IP pool will consist of these IP CIDR blocks.

Solution

If you wish to use the smaller IP pool, you'll need to ensure that the "atlassian-ip-ranges" boolean flag is present and set to "true" as well as ensure that the step in question is set to "size: 4x" or larger ("8x", "16x"), as shown here.