Atlassian Data Center products connect securely to Atlassian Cloud through Application Tunnels, which provide an encrypted link to your Cloud organization without opening inbound ports on your network. Tunnels support only Atlassian products, so for third-party tools such as Jenkins you need alternatives like secure webhooks or an API gateway.
When moving Atlassian tools to the cloud or integrating cloud services with on-premises systems, organizations face a dual challenge: migrating their data and connecting their systems securely. In this post, we break down key strategies for seamless cloud connectivity in an Atlassian environment. We’ll explore how to securely link on-premises Atlassian Data Center products with Atlassian Cloud, how to set up Single Sign-On and automated user provisioning, and how to integrate third-party tools, all while following best practices to keep your data safe. The goal is to ensure your team can enjoy the benefits of cloud services without compromising on security or functionality.
One major connectivity hurdle is integrating Atlassian Data Center applications with Atlassian Cloud products (like Jira and Confluence). Atlassian’s Application Tunnels are purpose-built for this scenario. They provide a safe, encrypted link between your Atlassian Cloud organization and on-premises Data Center instances. With application tunnels, internal systems remain hidden from the public internet, significantly reducing security risks. For example, a Bamboo Data Center behind your firewall can securely communicate with Jira Cloud to share build results or deployment information, without exposing Bamboo’s server to external traffic. This tunnel-based integration leverages Atlassian’s Application Links technology under the hood, allowing Jira and Confluence Cloud to talk to Bamboo Data Center as if they were on the same network. In short, application tunnels let you migrate to Atlassian Cloud services while keeping certain critical systems on-premises, all without opening inbound ports on your network.
Setting up a Bamboo integration via application tunnels involves a few clear steps. Below is a breakdown of how to establish a tunneled connection between Bamboo Data Center and Atlassian Cloud:
Create a Tunnel in Atlassian Cloud: Log in to your Jira Cloud’s admin console. Navigate to the admin settings, go to Applications, then find Application Tunnels. Create a new tunnel entry by providing the hostname of your Bamboo Data Center instance. The cloud admin interface will generate a unique Tunnel ID and Public Key, and it will offer a Tunnel Agent JAR file for download.
Install the Tunnel Agent on Bamboo: Take the provided Tunnel Agent JAR and install it on the server (or VM) that has access to your Bamboo Data Center. This agent will run on that machine to establish the secure link. Ensure that the Bamboo server can reach out to Atlassian Cloud; specifically, verify that it can make outbound connections on HTTPS (TCP port 443). You might need to update firewall rules to allow this outbound traffic.
Establish Application Links: In your Bamboo Data Center application, set up Application Links to the Jira and/or Confluence Cloud instances that you want Bamboo to integrate with. Use OAuth 1.0 for authentication when creating these links. Make sure the OAuth credentials and permissions are configured properly so that Bamboo and the cloud services can authorize and communicate with each other through the tunnel.
Validate the Connectivity: After setup, perform thorough testing. Use diagnostic tools or logs in both Bamboo and Jira to confirm that the tunnel is active and data is flowing. For instance, test if Bamboo can successfully send information (like build statuses or deployment triggers) to Jira Cloud. A successfully established application tunnel should show as Connected in the Atlassian Cloud admin view, and you should be able to use cross-application features (such as linking Jira issues to Bamboo builds) seamlessly and securely.
Another critical aspect of cloud migration is centralizing and securing user authentication. SAML SSO (Single Sign-On) integration allows your users to log into Atlassian Cloud products using your organization’s own identity provider and credentials. This means employees can use the same login they use for other corporate systems (for example, Microsoft Azure AD or Okta) to access Jira, Confluence, Bitbucket, and other Atlassian Cloud services. Not only is this convenient (one password to remember), but it also enhances security through centralized control.
To implement SAML SSO with Atlassian Cloud, you’ll need an Atlassian Access subscription. Atlassian Access is an enterprise offering that, among other things, enables SSO and user management features across all your Atlassian Cloud products. First, verify your company’s domains in Atlassian Access; this proves to Atlassian that you own the user email domain and allows those accounts to be managed under your SSO rules. Next, configure the connection with your Identity Provider (IdP). In your IdP’s admin panel, set up a new SAML 2.0 application for Atlassian Cloud. The Atlassian Access admin console will provide you with an ACS URL (Assertion Consumer Service URL) and an Entity ID; these are parameters you input into the IdP configuration so it knows where to send authentication responses and how to identify Atlassian Cloud.
When configuring SAML, you will also map user identity attributes. Common attributes include the username or email (often as the SAML NameID), full name, and group memberships. Ensure that the IdP is sending the correct attributes that Atlassian expects (for example, the user’s email address, which must match their Atlassian account, and optionally group information if you plan on group-based access management). Once the IdP side is set up, enable SAML SSO in the Atlassian Access settings. It’s wise to test the SSO login flow with a small set of users before rolling it out to everyone; this way, you avoid accidentally locking out all users if something was misconfigured. After successful testing, you can enforce SSO for your verified domain, meaning users will be redirected to authenticate via your IdP when accessing Atlassian Cloud. Overall, SAML SSO provides a smoother login experience and tighter security control during and after your cloud migration.
Managing user accounts manually can become tedious and error-prone, especially in a growing organization. SCIM (System for Cross-domain Identity Management) is a standard that automates the provisioning and deprovisioning of user accounts between your identity provider and Atlassian Cloud. In the context of Atlassian Access, SCIM allows you to automatically create, update, or deactivate users and groups in your Atlassian Cloud products based on changes in your central directory (for example, when an employee joins, changes departments, or leaves the company).
Setting up SCIM user provisioning typically happens after SAML SSO is in place and requires coordination with your IdP as well:
Enable SCIM in Your IdP: In your identity provider’s application settings for Atlassian (for example, in Okta’s Atlassian Cloud app or Azure AD’s enterprise application for Atlassian), turn on the automatic user provisioning feature. This usually involves providing the IdP with Atlassian’s SCIM endpoint URL and an API token.
Connect Using the SCIM API Token: In Atlassian Access, generate a SCIM API token (sometimes called a provisioning token). This token, along with the SCIM endpoint URL, will be entered into your IdP configuration to establish a secure connection. The token acts like a password that authorizes your IdP to perform user management actions in Atlassian Cloud.
Monitor and Manage Provisioning: Once activated, the identity provider will start syncing users and groups to Atlassian Cloud according to the rules you set (for instance, syncing all users in a certain Active Directory group into Atlassian). It’s important to regularly monitor the provisioning logs or dashboard in Atlassian Access. This will show you if new users have been created successfully, if any updates failed (due to errors like missing required fields), or if users were deactivated. By keeping an eye on these logs, you ensure the sync works smoothly and address any issues (such as permission problems or naming conflicts) promptly.
With SCIM automation in place, your administrators won’t need to manually add or remove users in Jira/Confluence when someone joins or leaves. This not only saves time but also reinforces security: for example, when an employee leaves the company and their account is deactivated in the central directory, SCIM can automatically deactivate their Atlassian accounts to prevent lingering access.
Beyond user access, cloud connectivity often involves passing data or triggering actions between Atlassian Cloud services and other tools. Webhooks are a simple yet powerful mechanism to achieve this. In Atlassian Cloud products, a webhook is essentially a user-defined callback: when certain events happen (like an issue is created in Jira, or code is pushed to a Bitbucket repository), the application makes an HTTP POST request to an external URL of your choosing, sending details about that event. This allows you to notify other systems or kick off automated workflows in real time.
Jira Cloud Webhooks: To set up a webhook in Jira Cloud, go to the System settings and find the Webhooks section. There you can add a new webhook by providing a URL (the endpoint of the service you want to notify) and selecting which events will trigger the webhook. For example, you might configure a webhook to fire whenever an issue is created or transitioned in a certain project, so that an external helpdesk or reporting system gets immediately updated. You can also refine events with JQL filters: this means the webhook will only trigger for issues that meet certain criteria (like a specific issue type or status). For security, Jira allows you to specify a secret token when creating the webhook; this token will be included with each webhook payload so your receiving service can verify that the request truly comes from Jira and not an imposter. Always use HTTPS URLs for webhooks to ensure the event data is encrypted in transit.
Bitbucket Cloud Webhooks: In Bitbucket, webhooks are configured at the repository (or workspace) level. For a given repository, go to Repository Settings and find Webhooks, then add a new webhook. Provide the destination URL and select the repository events you care about. Common Bitbucket webhook triggers include push events (code pushes to any branch) and pull request events (creation, updates, merges, comments). For instance, you might send a webhook to Jenkins or another CI system to kick off a build whenever new code is pushed to the main branch. As with Jira, you should ensure the webhook target URL is secured via HTTPS. Bitbucket also supports adding a secret (shared secret) to each webhook, which will be included as an HMAC signature in the headers of the webhook requests. Your receiving service can use this to validate that the incoming request is legitimately from Bitbucket. Once webhooks are set up, test them (Bitbucket allows you to ping the webhook to test the connection) and then watch as your various tools start talking to each other automatically whenever developers make changes or progress is updated.
Atlassian’s application tunnels are fantastic for connecting Atlassian Cloud with Atlassian Data Center products. But what about your other self-hosted tools and services? Many organizations use a variety of third-party systems (CI/CD servers, databases, etc.) that also need to integrate with Atlassian Cloud products. Since Atlassian’s application tunnels officially support Atlassian products only, you’ll need alternate approaches to connect external tools securely. Here are some methods to integrate popular third-party systems with Atlassian Cloud:
AWS CodeSuite: If you use AWS developer tools (like CodePipeline or CodeBuild), Atlassian Cloud products can integrate through Amazon’s native connectors. For instance, Jira Cloud can connect to AWS CodePipeline using AWS CodeStar Connections, which is a secure connector provided by AWS. By setting up a CodeStar Connection, you create a trust relationship (using AWS IAM roles) that allows Atlassian to pull in build and deployment information from your AWS environment without exposing any public endpoints.
Jenkins (Self-Hosted): Jenkins is a widely used CI server, and to receive build triggers or send data to Atlassian Cloud (like to update a Jira issue when a build finishes), Jenkins needs to be accessible in some way. Since you can’t use an Atlassian tunnel for Jenkins, one approach is to set up Jenkins behind a reverse proxy or use a public URL that forwards to your Jenkins server. This endpoint should be secured with HTTPS and ideally locked down to only allow traffic from Atlassian’s IP ranges or from an API gateway. Essentially, Jenkins will expose a webhook endpoint (or you create an intermediary service to handle the webhook) that Jira/Bitbucket Cloud can call. By tightly controlling who can reach that endpoint (through IP allow-listing and authentication tokens), you ensure that only legitimate requests trigger your Jenkins jobs.
Snowflake / dbt: These data tools often integrate with Atlassian products via source code repositories or APIs. For example, you might store SQL scripts or dbt projects in Bitbucket Cloud and want to trigger Snowflake data loads. Without a direct tunnel, you would rely on secure API calls. One strategy is to use personal access tokens (PATs) or SSH keys for Bitbucket Cloud to allow an external tool (like a Snowflake pipeline or a dbt Cloud job) to pull the latest code. Conversely, if Atlassian Cloud needs to notify Snowflake or dbt of an event, you’d set up an endpoint or utilize the tool’s API. The key is to manage credentials carefully: generate dedicated credentials for these integrations and store them securely (for instance, in AWS Secrets Manager or HashiCorp Vault) rather than hard-coding them.
Atlantis (Terraform Automation): Atlantis is a tool that automates running Terraform plans/applies in response to pull requests. If you host an Atlantis server internally and use Bitbucket Cloud for code, Bitbucket’s webhooks need to reach Atlantis. Since Atlantis is not an Atlassian product, you can’t use an application tunnel. The solution is to give Atlantis a secure public endpoint. This could mean running Atlantis in a environment where it’s accessible via a URL, but protected by firewall rules. Limit the exposure by allowing only Bitbucket’s IP addresses or using a webhook secret. Whenever a developer opens or updates a Terraform pull request, Bitbucket will send a webhook to Atlantis’s endpoint, which then performs the Terraform tasks.
Other Internal Tools (Custom CI/CD, etc.): For any other on-premises system that Atlassian Cloud needs to interact with, consider using a middleware or proxy approach. One pattern is to use an API Gateway or cloud function as an intermediary. For instance, an AWS API Gateway can receive a webhook from Jira Cloud and then internally invoke a secure function or send a message to your internal service. This way, the Atlassian Cloud never calls your tool directly; it calls a gateway in the cloud that you control and secure. Always enforce that these endpoints require authentication (like expecting a specific token or key) and only accept traffic from Atlassian services. In sum, while direct tunnels aren’t available for third-party integrations, a combination of secure connectors, webhooks, and controlled exposure points can achieve the connectivity you need.
No matter which integration method or tool you implement, some core best practices will help maintain security and reliability:
Use HTTPS for Everything: Ensure all data in transit is encrypted. Whether it’s an application tunnel, a webhook, or an API call, always use secure HTTPS connections. This protects sensitive information (like authentication tokens or user data) from being intercepted.
Protect Keys and Tokens: Treat your integration credentials as secrets. Store API tokens, OAuth keys, and SSH keys in a secure vault or secret management system (for example, AWS Secrets Manager or HashiCorp Vault) instead of hardcoding them in scripts or configuration files. Regularly rotate these credentials according to your security policies.
Implement IP Allow-Listing: Where possible, restrict access to your internal endpoints by IP address. Atlassian publishes the IP ranges for their cloud services; configure your firewalls or API gateways to accept requests only from those addresses. This adds an extra layer of defense so that even if someone discovers your endpoint URL, they cannot interact with it unless they’re coming from an authorized source.
Regular Audits and Monitoring: Periodically review your integration settings and logs. Check that webhooks are functioning as expected and not throwing errors. Audit who has access to what in Atlassian Access (ensure ex-employees are indeed deactivated via SCIM, for example). Monitoring tools and audit logs will help you catch misconfigurations or suspicious activities early, ensuring your cloud connectivity remains both smooth and secure.
Can application tunnels be used to connect non-Atlassian products? No. Application tunnels are an Atlassian feature that supports only Atlassian products (Jira, Confluence, Bitbucket, Bamboo, etc.). They cannot directly tunnel traffic to third-party systems. For other tools, you must set up alternative integrations such as the secure webhook or API gateway approaches described above.
Do we need to open inbound ports on our network for these integrations? Generally, no inbound ports are required for Atlassian Cloud connectivity. Application tunnels and webhooks operate with outbound requests from your side. For example, the Bamboo tunnel agent initiates an outbound connection to Atlassian Cloud over port 443 (HTTPS). Likewise, webhooks are sent from Atlassian Cloud to your endpoints, so you just need to allow your tools to receive those specific HTTPS calls. In summary, ensure outbound TCP port 443 is open for Atlassian communications, but you shouldn’t expose new inbound ports to the internet.
Is a VPN required or supported for Atlassian Cloud integration? No, Atlassian Cloud does not support using a VPN for standard product integrations. Unlike some other enterprise services, you can’t hook up a VPN to Atlassian’s cloud to extend your network. Atlassian provides tools like application tunnels instead. Only a very limited set of enterprise offerings (for instance, Atlassian’s own internal infrastructure or certain marketplace apps) might involve VPN-like connectivity, but for nearly all cases, the integrations must be done via the official features and methods we’ve discussed (tunnels, SSO, SCIM, webhooks, etc.) rather than through a VPN.