In this blog, we'll look at how easy it is to make a private database available without the need for a VPN and using just Single Sign On credentials. That means no more shared credentials to access your database and flexible policies to define who has access. And, as a bonus, you'll also have session recording!
We all use databases to make our applications and services work. Sometimes they're self-managed on-premise, in a private data center somewhere, or more and more popular, a cloud service such as AWS RDS. Due to the nature of the data in these databases, they're often well protected by firewalls or run entirely in private networks such as a private VPC. This leaves us with the challenge of accessing the databases.
A second challenge is the database credentials. Teams still commonly use shared credentials for databases, making it challenging to rotate them periodically. As a result, it's hard to know who has access to the credentials.
Another challenge with shared database credentials is auditability and accountability. Since folks connect to the database all as the same shared user, it's difficult to attribute queries to individuals. And that's assuming the capabilities to record queries exist.
Database access with Border0
Using Border0, we can solve all of the above challenges. And we do this in an easy, low-friction way, in line with how developers like to work.
We'll take a look at an example use case, demonstrating how Border0 provides the following for MySQL and Postgres databases:
1) Allows users to access private database instances without the need for a VPN.
2) Access to the database can be controlled using flexible policies, allowing the administrator to define who has access to what databases, when, and from where.
3) Users can use their Single Sign-on (SSO) Credentials to log in to the database. So no need for shared database credentials.
4) Detailed session logs that record who accessed the database, when, and from where.
5) Query logs allow the administrator to see precisely who executed what query and when.
This is a powerful set of features that solve many of the long-standing challenges with database access. What better way to see how it works than a quick demo!
Example database Scenario
Let's assume a user has a MySQL database running in AWS, either self-managed or an RDS instance. Since the database contains sensitive data, it's deployed to a private VPC. This provides the network isolation we want and means that no one can access it directly from the Internet without some kind of VPN (or use Border0!).
Just a few people should have access, using just their SSO credentials. They don't have any database credentials besides their personal SSO credentials.
Provisioning a Border0 Database Socket
The first step is to make this database service available. To do this, we create a Border0 Database Socket (Sockets are what we call Services in Border0). This can be done through the portal, using the API (yay for automation!), our connector, or, like in this example, the Border0 CLI.
In this example, we're also providing an upstream username and password; these are the database credentials Border0 will use to connect to the database. Alternatively, we could use the Border0 connector and the AWS SSM plugin to provision this. Or fall back to a TLS socket, in which case we don't need database credentials.
Next up, we connect this socket to the Border0 anycast cloud like this:
This needs to be run either on the database server itself or a server in the same VPC that has access to the database server. Note: all that is required is egress network access, for example, using a NAT gateway commonly used for private VPCs.
You're now ready to access the database; that was pretty easy, right? Now the MySQL server has registered itself with the Border0 global infrastructure, and users can start to access it.
Accessing the Database through Border0
Accessing the database through Border0 is easy and can be done using the user's favorite database client. They only need a Border0 certificate, which can be fetched using our CLI or Desktop App. However, most users don't need to worry about that. To make things as easy and low friction as possible, we've made it easy to launch many of the popular database clients directly from our App or the Border0 CLI tool. Using any of these two options, users can quickly discover all databases they have access to and launch their favorite client.
Below is an example of using the Border0 desktop application. Notice how the user can quickly see all resources available to the user and connect to the database using various popular database clients for which we've built launch integrations.
For the CLI fans, the same is possible using the Border0 CLI client. Just type in border0 client db, and you'll see all databases you have access to and launch your preferred database client from this CLI wizard.
Notice that during this whole flow, the end-user was never asked for database credentials. These don't need to be shared with end-users; all they need is valid SSO credentials. Assuming the administrator gave the user access by defining this in a Border0 policy, the user can discover and access this database.
Session logs and Query replays
As the administrator, it's now easy to see who accessed what database service, when, and from where by looking at the Border0 session logs. By clicking on a session, you'll be able to see exactly what queries were executed by this particular user in this session. It's pretty powerful to watch this back as if you're watching a live video.
Having insights into Who accessed What database, from Where, and When, as well as details of all the executed queries, help administrators with their Audit challenges.
Wrapping up
In this blog, we looked at how Border0 can help organizations with database access, discovery, and auditability, no matter where your databases are located. We saw how Border0 can help make private databases accessible to users using only their SSO credentials. Our flexible policy language makes it easy to define who should have access under what conditions. One huge benefit is that users don't need to know the database credentials. Instead, they can just use their existing SSO credentials so that we can eliminate shared accounts!
Using either the Desktop app or the Border0 CLI, users can quickly discover what database servers they can access. With one click, launch their favorite database tool to connect and query the database without needing a VPN. This is a significant improvement in user experience for the engineers and, thus, their productivity.
Finally, we saw how administrators can see exactly who accessed what database, from where, and when. And were able to see what queries were executed. Again, a major step forward from the current status quo, where administrators often have challenges to easily see what queries were executed when. More importantly, due to the use of shared credentials, it's often difficult to determine who executed the query.
Hopefully, this demonstrates how easy it is to get started with Border0. We invite you to give it a spin yourself and sign up for our free, fully-functional community edition here!
Follow our documentation here, and you'll have your database accessible in 2 minutes: https://docs.border0.com/docs/making-a-database-resource-available
Ready to level up
your security?
