@mariusz, although requested in 2010, I doubt there is any chance to get this to Standard Subscription. Most useful features in the last year went to Premium only.

Great news! Thanks Rak!

Thank you Rak Garg!

Great job!!!

Hello guys, this afftect my team, any update about this issue? its only be avaliable for premium?

Hi - to second Clayton Lopes - this is really nice to restrict IPs and require network access to get in, in addition to having your Atlassian login, but the key for me is that I will be able to open up anonymous access, but that be limited to the trusted IPs....  Can anyone answer that?  We want users to be able to view Confluence pages with out having to log in - like you can with Server/Data Center being open to specific domains/IP lists...

Great stuff - well done Atlassian!

Just to be clear on this feature, if we turn this on and change our confluence page to public facing does that mean users will not require a confluence license to view the confluence page as long as they are connected to the allowed IP? Does this also apply to Jira Service Desk?

This is really great news. Will be waiting for when this is available via Administrator interface

@Rak Gar,

Thanks for the update, that's huge news!

This feature is very important to everyone cares about security and data privacy. We need a timeline for when this will be implemented 

It's a very important feature ... especially in covid-19 home-office times ...  please reconsider adding that feature fast.

Surprised this is not a higher priority issue as of the CV19 issue. As most business are having to move their staff from local to remote they need to be sure from that accounts are secured.

Agree this is basic functionality for any cloud service for enterprises and should be included in product.

There is a workaround if you're willing to pay for Atlassian Access and able to be flexible on SSO. You can sign up for Atlassian Access, which comes with a free Okta account for all Atlassian products. Okta has this functionality (and more) and can be the IP restricted gateway.

Hi. I believe a simple IP restriction on the cloud platform will be a basic security feature. This should be 1 of the feature that is having priority on the next release patch.

Thanks.

You promote this as an "Coming soon" feature for both Jira and Confluence in the pricing tabs, and here you say it is a "future consideration"...?

Trustworthy.

Should promote as "might come one day"

I agree with the most of the commenters here. Very basic IP white-listing is simply a necessity, I can't introduce JIRA/Confluence to the rest of the company, because we lack this possibility.  That is very frustrating. And we have been waiting for at least a year now. 

Why we also need whitelisting feature is because we don't want our users to access Jira/Confluence via their personal computers and able to download everything for their own interest. Currently we have company's laptop for users to work remotely via VPN to our servers. Those company's laptop has been secured to prevent data leakage.

Without IP whitelisting, it is almost impossible for us to adopt Jira and Confluence Cloud.

SSO is great and working well however we want more . In our case we dont have use for public access so white-listing is necessary 

alexk1007397506,

Thanks for the suggestion. Is your organization using an Identity Provider (such as Okta) to handle authentication today? I believe many identity providers provide authentication-level IP whitelisting, which you could start using with your cloud products immediately. Here is a link to the relevant Okta documentation, for example.

Thanks,
Rak Garg
Product Manager

Finally, I have been watching this for a couple of years now. #

Just basic IP whitelisting at the top level. Either you can log into your account by being on the whitelist or you can't. That will do for now. You can add more white listing features later and take you time, this basic level of IP whitelisting is a MUST and should have been implemented years ago.

Hi Rak Garg

We use a tool like Bitglass (CASB) to do SSO and only allow trusted devices to access, but ideally we would prefer to restrict via Atlassian rather then having another layer between Atlassian and the end user 

Hi karthik2,

Rest assured that we believe in the value of this feature and are actively investigating how we can bring it to customers in the most efficient way. I'd love to understand: what other tools are you using with your Atlassian products to restrict access today?

Feel free to shoot me a note at rgarg@atlassian.com if you have any other questions.

Thanks,
Rak Garg
Product Manager

Hello @rgarg@atlassian.com

We haven't got much of an update from the last quarter of 2019 on this feature. Atlassian implementing this feature would remove the integration of other tools to restrict access to help in maintaining the simple architecture. Please let us know if the feature is even considered valuable to deploy into prod or still waiting for sufficient votes. 

It will be great to be able to restrict access to Atlassian Cloud using IP whitelisting to restrict access to our environment from public internet. What is the timeline for such implementation 

Good afternoon.

I'm the Head of Compliance of BET, Jira's user and the whitelist is really a good practice in terms of guarantee the security of access out of the office. Please check this possibility as this is acceeded outside of our office and we need to guarantee the security in a safe environment like only office IP.

Thank you

Microsoft planner is hot on the heals of replacing jira in organisations if this security control isn’t in place. Security wins over functionality. Planner doesn’t have workflow but has whitelisting.

This would make Jira a big player in cloud hosting space. Much needed feature from a security point of view. A thousand upvotes from me!

Nice feature to have

Seems like IP Whitelisting will be a "premium" feature.

This tells me they will charge the double amount of money to give us this basic feature and other less important stuff

Seemingly low-complexity feature making a lot of customers happy.

Value of this feature is that it will be one of the last arguments internal teams will have with their internal security department.

Suggestion to manage the security settings from within the billing / account section (different host) to prevent lockout.

As Atlassian Cloud is on AWS, while at it please integrate it with the corresponding AWS Security Group /WAF so we can have network level security (as to the less desirable application level security).

I totally agree with Simon , Whitelisting is the basic security feature which atlassian has to provide to customers.

Looks like atlassion is not concerned about security .anything which is hosted in the cloud should have the whitelisting feature .

We really must have this feature.

Bitbucket has many issues but restricting access to it via wihtelist is invaluable to us. Why this is not already a feature in Confluence is beyond me.

Atlassian - if you want customers to put their production & documentation pipeline in the cloud, you need to give us  the basic tools to secure it !

Hi Rak Garg,

with my team, we just moved to Atlassian Cloud.

Actually our Confluence contributors are around 100 and we are in the process of opening it to our product and operation specialists.

Thanks to this decision, we will be able to centralize all the informations inside one only tool (right now, the are dispersed among many google docs, evernote, google notes, etc....

However we would like that these users share their contributions to read-only users which will never be active users. We thought about the fact of opening a single account such user documentation@mail.com and spreading the ids to the read-only users. The security problem is pretty obvious and we discarded this choice since we don't want that a user connects to a Confluence instance (also if it would be seeing only one Confluence space).

That's why we would like to open the documentation to everyone but restraning the access to read-only users.

Like GCP, it would be perfect, if we could restrict the access to some IPs.

This is the main feature holding us back from moving to Confluence cloud. We use it for our internal intranet and do not want that information to be publicly accessible therefore we cannot move from server to cloud.

At Salesforce, by restricting with IP whitelist, we can register and store data in Salesforce with confidence.

ref: https://help.salesforce.com/articleView?id=users_profiles_epui_login_ip_ranges_edit.htm&type=5

ref:  https://help.salesforce.com/articleView?id=000321501&type=1&mode=1

At Atlasian Cloud, The fact that can't be restricted by IP whitelist means that you are putting users and the information they have to the risk.
Or it means that the data the user has is almost unimportant.

My team appreciates the Atlasian Cloud.
We want to migrate now, but we can not.

We need to be confident that they are communicating with Atlassian Cloud in a secure environment.

IP whitelisting is one of the most effective methods of ensuring this and prevents any internet traffic intended for Atlassian Cloud from being hijacked or rerouted to a rogue website.

If we can IP whitelisting, we can move to Atlasian Cloud.
If we can not IP whitelisting, we can not move to Atlasian Cloud.

We hope this feature will be realized.

Thanks.

Hi Rak Garg,

We currently use Jira Server and Confluence Server in our intranet.  We are uneasy about exposing our JIRA/Confluence content directly to the Internet to prevent user errors from leaking confidential or GDPR-related information.

Having an IP whitelisting in place would give us a lot more assurance to try the Extended Trial to evaluate a migration to Jira Cloud, as the atlassian.net instances seem to be in AWS Dublin, which is also where our intranet/Terminal Servers are.

Hi Rak Garg,

Following up on the previous post regarding license cost, which would be one reason for implementing white-listing for anonymous users. In my specific case, I'm representing a customer with more than 5000 users in the AD. I'm in the process of moving away from Confluence Server but I'm currently stuck since the majority of the users only need anonymous read access. Licensing 4000 inactive users is not an option. There are, however, two alternative solutions to white-listing that I can think of that would potentially solve the problem. 
1. Don't charge for named read only users
2. Allow anonymous users secure access from a CDN, for instance CloudFront. Whitelisting could then be provided by the CDN. This solution would require less work for you and would also minimize the load on your servers. 

Thanks

Robert

Hi Rak Garg,

From my perspective in a number of organisations I have worked in those that have used the 'Server' version of Confluence use white-listing to enable those spaces or pages that are accessible to anonymous users (i.e. public access) to be restricted to only trusted IP addresses, this is primarily due to information that is only relevant to the organisation and cannot be shared outside. Generally this has been the case as teams setup Confluence spaces/pages as 'Support wikis' where all support material for an in-house application is housed. Sometimes information within these can be sensitive and cannot be broadly shared with anyone outside the organisation. Additionally people do not want to cap out their licenses for Confluence for users that may or may not ever visit a Confluence space/page unless they require some support and bother to look at the support material (this however may go against the interest of Atlassian as additional licenses won't need to be purchased, but at the same time this functionality could intrigue people to use Confluence in this manner when they haven't done before and will generally have them embed all their support here in which it would be harder for them to move away from the application).

Thanks.

We are waiting for the feature as well.

Is there an update on this feature?

If you are seriously considering it, could this restriction apply by space if possible.

We want this feature as well!
Do you guys have an ETA for this feature?

We are awaiting for this security feature as well before moving our service to the cloud.

This is a must feature. Please update it asap

This is a critical security feature and a mandatory requirement for us to migrate the on premises installation to the cloud version.

What is the date plan to make this feature available?

Our tool selection policy prefers vendor cloud over self-hosting, but when using things like Service Desk especially (for internal service), we really want to be able to avoid 100% openness to the wider internet.  Requiring 2FA and using Azure SSO does remediate that a bit, but it would still be nice to have the whitelist option.