As you know, our Jira instance is currently the weakest link in our security posture. It is outdated, plagued with multiple vulnerabilities, and essentially a ticking time bomb.
To mitigate these risks until it can be replaced, we have decided to place Jira behind a VPN. This means that only OpenCraft members (and those who genuinely need access) will be able to use it. Consequently, Jira will no longer be accessible to anyone who is not connected to the VPN.
As far as I recall, no clients actively use our Jira, and we do not have any shared boards with them. However, if I’m mistaken, please let me know—any clients who require access will need to set up the VPN as well.
The VPN client configuration will only affect Jira (and Wazuh), so your regular internet traffic will not be routed through the VPN server. Additionally, the added latency is minimal, around 20-40ms, so you likely won’t notice any impact.
Based on the comments below, first let’s discuss if that’s something suitable for us or not. Should we put Jira behind a VPN?
Yes
No
Not sure (please comment what info would help you)
@gabor Before imposing decisions like this on the team, can you please ask the team first, and leave ample time for people to schedule a ticket in their sprint? Please postpone the deadline, and move this thread to become public.
FTR: this post is now public. The topic is updated too.
@antoviaque based on the previous discussions with @braden I had the impression that this is not something optional, but kind of must-have as Jira is posing a security risk with sensitive data in it. However, that may have been a misunderstanding on my end. I’m going to drop a poll on this above. To reduce potential round trips, do you have any good deadline in mind in case it gets voted?
I agree that we should probably put JIRA behind a VPN, but the rather tight deadline is a bit confusing to me. I assumed this would involve a post like this one for discussion in sprint 1, sprint 2 to take in feedback and do the backend work, sprint 3 to give people time to configure the VPN and see if everything works, and sprint 4 for restricting access without a VPN.
I think a lot of people (myself included) are integrating with Jira APIs in many ways and it might need more time to think how we’d adapt to a VPN.
We also have automation in sprints and openfunctions that call on Jira APIs, how will they work behind a VPN?
We should remember that not all enterprise devices allow the use of custom VPNs. I can discuss this tomorrow during the client meeting.
@gabor, did we consider any alternatives, like putting the instance behind Cloudflare Tunnel? Accessing the instance could be as simple as authenticating through the Google SSO (or a one-time PIN received via email) configured for Cloudflare Zero Trust.
Connecting to a VPN can be problematic for people who already use other VPNs in the kernel networking mode.
Edit: we also have one more client board. However, it’s not used anymore, so I can discuss deprecating this one.
What is the ticket for this? Found it, edited post to add. I don’t see it in the original post. Also, how do you want us to submit the keys, and is the IP we need per user or is it one we’ll have posted somewhere? Is it possible to have the VPN connection endpoint behind DNS, and just not advertise the record in public spaces? I don’t think you can query a DNS server for ‘all records’ in a way that would make it public if we don’t publish it, so a DNS record that can be updated seems like it would be no more dangerous than directly telling people the IP.
Even if you MUST specify the IP in the config, having a DNS record that’s updatable makes it easier for the team to find it.
It’s an IP range, not an IP, so apparently no, it can’t be a DNS record, unless it were a TXT record, I guess, but that doesn’t seem the right way to do it. Only other issue I can see is that since this is a reserved address range, the team should be made aware of the range we’re using ahead of time, in case any of our networks may be using conflicting addresses. I’m not, but I do have other VPNs, so there could have been a conflict.
@gabor Thanks for making the post public, and for pushing back the deadline!
For setting a deadline, the best would be to agree to it as a group, and preferably by consensus, rather than me or you setting it. If there is a disagreement or a decision by consensus can’t be reached, then that can be escalated to @braden and/or me - but it’s better to start from the group whenever possible, especially when it impacts everyone like this one. It takes longer for sure, but it tends to be better decisions.
I have my desktop, my laptop and another server I use. I can probably reduce the places I use it, but I also have another VPN that I use to access my own self-hosted services, and these two might need to be used together without conflict. So mainly my point is, I’d need a bit more time ideally.
What are the next steps here? Should we try a grace period where use of the VPN is optional, and let everyone with complex setups / API integrations etc. tests whether or not it will work for them?
