Multiple Confluence & Jira instances to keep customer data separate

[Barbara Westa;;]

Hi all,

due the nature of our business, we need to keep all customer data living in both Confluence and Jira, totally separate from other potential customer areas. I'm trying to figure out the best way to do this.

Some facts:

•  We have one major customer at the moment. All project work is in a single Confluence & JIRA installation running on 1 (virtualised) windows 2012 server.
• Both JIRA & Confluence are up to date.
• Using Tomcat as the db.

It looks like we are going to be getting a couple of new customers in the next few months (), and they will all need their data to be kept totally separate from each other.

It seems that I can:

• run multiple databases (containing a single JIRA instance per customer), on one dedicated 'Jira' server (as per https://confluence.atlassian.com/jira/running-multiple-instances-of-jira-on-one-machine-222200571.html). This is good as the data is kept separate and I can archive and remove the db when the customer relationship ends. However, I need to license each JIRA db separately.
• However, I cant run a similar setup with Confluence. I'd need separate dedicated confluence servers (again licensed separately)

Are my musings above, accurate ? (im new to the Atlassian suite, but hope to do the full training in the next few months )

There is no easy way to run a single confluence & JIRA system, but keep customers 'separate' in different databases ? (I also see that all the attachments for different customers, would be lumped together in Confluence).

Any advice ?

Is clustering going to cost me a small fortune ?

[Nic Brough -Adaptavist-]

You're mostly correct in your assumptions, but, I'd say

Tomcat is not a database, it's an application server.  For this stuff, you need a supported database service - PostGreSQL is top of the recommendation list, followed by MySQL, then Oracle or MS-SQL

Although you can run several JIRA instances on one machine, they can be quite resource intensive.  You'll need to think about resources on the server.

It's actually the same for Confluence - you can run several on one box if you have enough resources to do it.  You are right about the licences though - each instance requires its own licence

You can run one JIRA/Confluence and segregate customers by using the application's security systems.  The one weakness you will find is that users can see each other (So if Dave has project/Space called "Dave's place", then George, who works for another customer, will not be able to see "Dave's place".  But in some cases, he'll be able to work out that Dave is a user in the system).  The attachments live within this security scheme, so they're not an issue.

Clustering is not possible unless you go to DataCenter.  But that doesn't actually help you because that's one single system for everyone to use, not a set of small individual systems.

[Alex Yasurek]

Hi,

Is there a reason your situation can't be handled with permissions? Each customer is only given permission for certain JIRA stories and spaces in confluence? The content would be stored in the same DB but they wouldn't be able to access each others data since they would not have permission to do so.

[TomC]

To Alex's and Nic's points, we have successfully used space permissions and even page restrictions to segregate customers within one instance. We had one instance that might be considered extreme to some but wasn't to us - where different customers were in the same space.  With the diligent use of page restrictions they had access to different content - everyone could see the same landing page but through the use of available macros while they 'knew' other customers were in there, they couldn't access other customer's content.

That being said, having them in different spaces via space permissions would be cleaner and easier especially when the content you wish to provide is more than a page or two's worth.

We have also made the customer spaces more 'elegant' through the use of a theming plugin (there are a number of options in the Marketplace to choose from) that transforms Confluence spaces into more of a typical website look-and-feel.  It strips out the updated by line (if desired), adds menu tabs (if desired), and for some home pages especially, the comments area is suppressed (internal departments like this additional customization/clean up).  It has been a worthwhile investment for us to add this plugin as it has assisted greatly in acceptance/adoption by other groups in the business who like the 'website look' over raw Confluence in many cases. Since one can apply a theme per space, our internal customers can choose which option they want.

[Alex Yasurek]

We do similar things because we have employees and customers that access our confluence instance. Employees are allowed to see everything but customers can only see certain spaces. We also use themes on customer facing spaces to give them a different look and hide certain things we don't want customers to be able to use or see like the people directory, space admin section, and various options under the Tools menu. Customer facing spaces also have additional help links and a support button. As of yet we have not run into any issues where customers were able to see anything they were not given permission to. Our JIRA instance is a different story since it is completely internal only so we don't have to worry about customers seeing info there.

[Bill Bailey]

I would just echo that space permissions is the way to go, and segregate out your customers to different LDAP groups from your internal staff (note, everyone has to be a member of confluence-users). Then you have good control on rights within a space based on group membership, on a page, and at the space level.

Don't try to complicate your life with multiple Confluence instances.

[TomC]

<<Don't try to complicate your life with multiple Confluence instances.>>

Amen to that!

[Nic Brough -Adaptavist-]

Yup, the only weakness of one single system is that your clients can find out who each other are.

[Bill Bailey]

We ran into this issue awhile back. And turning off some of the modules, like quicksearch (type ahead) and some of the user modules (I forget which, but the mention would be a good one to disable) can do a pretty good job. Not 100%, but makes it harder.

[Adrian Reid]

Confirm. There are too many ways to find other users on Confluence who are potentially from a competing company. I used Javascript which was easy but disabling modules is a better option. But you need to disable the People button which is a major piece of Confluence functionality. This part of Confluence just hasn't been thought of at all.

[Barbara Westa;;]

Many thanks to all your replies and thoughts on this matter.

I'd love to have everything on one server and use permissions to separate customers (this is an internal tool only  - no customer access, plus we are a small company <50 users atm).

However, the customers hard-core audit requires robust data separation. Separate VMs and installs is the only sure way to do this I think.

[Nic Brough -Adaptavist-]

I think you're absolutely right there - there's just so many ways a Confluence  (or JIRA - that's worse in some ways) can leak information about other companies, the VM separation is the only way forwards in some cases.