Let's cut straight through the bullshit: if you're an engineer working in a company that deals with sensitive data or operates in a regulated industry, you've probably rolled your eyes at the mention of "compliance" more times than you can count. SOC2, ISO27001, HIPAA, GDPR – these acronyms often feel like speed bumps on the highway of rapid development and deployment.

But here's the kicker: DevOps and compliance aren't natural enemies. In fact, when done right, they're powerful allies that can supercharge your software development process and keep your ass out of regulatory hot water. So buckle up, because we're about to dive into how you can make DevOps and compliance work together without sacrificing your sanity or your velocity.

On June 30, 2024, Qualys, a US security firm, has discovered a critical vulnerability in OpenSSH Server - the de facto standard tool used to access and manage cloud servers.[1]

The vulnerability allows an attacker to bypass the authentication process and remotely execute code with root-level access on the system, potentially leading to data theft or system compromise. At risk are OpenSSH versions 8.5p1 (2020) to 9.7p1 (2024) or below 4.4p1 (2006).

The "Remote Code Execution" (RCE) vulnerability has been assigned CVE-2024-6387 and dubbed "regreSSHion" - This is pun to this being a regression bug because it has been reported and fixed in 2006 (CVE-2006-5051) and reintroduced in 2020.

Kviklet 0.4 is out! This release includes numerous refinements, which will continue into version 0.5, as Kviklet transitions from a basic MVP to a polished, robust tool that I hope everyone will love to use. For this release the main focus was to make Kviklet work for teams with a larger member count (think 10+). The highlights are:

• New Role and Connection Edit pages, check them out, should be a lot more intuitive than before.
• A download as CSV button for Select queries. So that you can use your favorite Spreadsheet tool to analyze and browse the data. Or process it further with your favorite programming language.
• Notifications with error messages if stuff goes wrong (hopefully you dont see them so often). But using Kviklet should have come a lot more intuitive due to this.

How to Setup Read-Only Access for Developers with Audit Logs​

In today's fast-paced DevOps environment, ensuring that developers have secure yet efficient access to production data is critical. We have written multiple posts on why exactly this is the case, see here and here. Read-only access to production databases is often a good sweetspot to start with for troubleshooting, analytics, and various operational tasks, that in our experience solves 50%+ of all dev access requests. However, this access must be carefully managed to prevent security risks and maintain compliance. In this guide, we'll walk through how to set up read-only access for developers with comprehensive audit logging using Kviklet, so that your SOC2 or ISO 27001 auditor will be happy.

Why Read-Only Access?​

Read-only access allows developers to:

Kviklet 0.3 is out! We've added a bunch of new features and improvements to make your production access even more secure and efficient. The new release contains a bunch of new features most notably:

• An integration with Kubernetes Exec, you can now run commands on other pods after they've been approved through kviklet. The idea behind this is that you can audit your script executions through Kviklet as well as database acces. If this works well we will expand on this further with e.g. a web based console some time?
• Support for MS SQL Server Databases. A wish by the community, if you have other databases that you'd like us to support don't hesitate to open an issue!

I asked myself this question at my first job at Scalable Capital, 4 years ago. I had started at a FinTech startup/scaleup with somewhere between 50 and 100 engineers, enthusiastic about DevOps and a You build it, you run it mindset, which I learned about in my software engineering education in university.
But reality hit hard. You can't simply give every engineer full production access, justifying lax credential management with We want to give people ownership and trust.

In the fast-paced world of DevOps, safely accessing production databases is a crucial competency that balances operational efficiency with stringent security measures. This comprehensive guide explores DevOps database access best practices, ensuring your engineering teams can swiftly address issues without compromising on security or system integrity. We'll cover the importance of giving engineers access, the place of migration tools, analytics, and best practices around maintenance and operational tasks. We'll also look at the role of the Four-Eyes Principle in this post.

Kviklet as an application already allows you to execute arbitrary SQL statements on your database. However a feedback we heard multiple times is that using a simple web tool for query execution is not the same as e.g. a designated DB access software like Datagrip.

We've decided to license all our code under MIT and make it fully open-source. With this decision also comes the realization that it is unlikely we will establish a company based on Kviklet. In this post we are sharing some learnings from our journey and what's next for Kviklet.

Open source is core to the modern engineering world. In one way or another, everything runs on Linux or Android, or at the very least, is developed with tools that are available as open source. This hasn't gone unnoticed in the startup world, companies are being founded with a core product that is open source, sometimes funded purely based on GitHub Stars with no active revenue streams.