MongoDB Access Webinar

Secure Access to MongoDB with Teleport Database Access - Overview

MongoDB is one of the most popular open-source databases. This makes it both an easy choice for teams of any size and a prime target for hackers. In the past couple of years alone, there's been a number of hacks involving thousands of open and unprotected MongoDB deployments — many of which could have been easily prevented by following a standard set of security best practices and using products like Teleport to control access.

In this webinar, Roman Tkachenko shows how Teleport Database Access can help you provide secure access to your MongoDB clusters, including:

• Using your SSO provider to give your users short-lived database credentials
• Using role-based access to control who can access your databases - Using access requests for temporary privilege elevation Capturing MongoDB access and query activity in the audit log

Key topics on Secure Access to MongoDB with Teleport Database Access

• Teleport can provide secure access to MongoDB databases, while improving both access control and visibility. - MongoDB is the most popular analytical database with a low barrier for entry to using it, which makes it a very compelling target for bad actors.
• Secure access to MongoDB with Teleport Database Access solves the challenges encountered with managing an inventory of multiple MongoDB clusters in multiple environments in a coherent manner and having a straightforward way to control access.
• With Teleport Database Access, MongoDB clusters are never actually exposed on the public network and instead connect back to the Teleport's proxy or the reverse tunnels established by the database agents.
• Teleport keeps a central inventory of all registered MongoDB clusters allowing users to see all clusters they have access to at a single glance.

Expanding your knowledge on Secure Access to MongoDB with Teleport Database Access

• Teleport Application Access
• Get started in 10 minutes
• Documentation
• Teleport Quick Start
• Teleport Access Platform
• Teleport Kubernetes Access

Learn more about Secure Access to MongoDB with Teleport Database Access

• Read the Teleport Admin Guide
• Download Teleport

Introduction - Secure Access to MongoDB with Teleport Database Access

(The transcript of the session)

Roman: 00:00:01.477 All right. Thank you, Ben. Good morning, everyone. Welcome to Securing Access to MongoDB with Teleport Database Access webinar. And let's get started. Right. So let's go over the agenda items first. So first, we'll talk a little bit about what we mean by MongoDB security in general, right? What kind of challenges you might run into if you're thinking about securing access to your MongoDB cluster, what kind of solutions you have at your disposal, and how Teleport Database Access can help you kind of improve the security of your cluster. Then we'll talk about how Teleport Database Access works, take a look at some of these features, jump into a quick demo to take a look at all those features in action, and at the end, we'll kind of conclude by leaving some time for questions and answers, hopefully. So without further ado, let's get started, right?

MongoDB security

Roman: 00:01:01.289 So let's talk about MongoDB security in general, right, and what we mean when we think about, "How do you secure your MongoDB deployment?" So MongoDB is probably one of the most popular open-source databases out there, right? It's certainly the most popular analytical database. And in fact, since its inception, it's pretty quickly climbed up to the top five spot of popular database engines and it's kind of sitting there right now along with Mammoths, MySQL, and Postgres pretty confidently. So this popularity comes from the extremes of use, right, which makes MongoDB a very popular choice among teams of all sizes looking for some NoSQL action and from small, small start-ups to large enterprises with different areas of expertise. Unfortunately, it also makes it a very compelling target for bad actors. There is a low barrier for entry to using MongoDB. Unfortunately, this means that it's also very easy to use in an insecure way. And so this is not just hypothetical either.

Roman: 00:02:07.322 Just in recent years, we've kind of seen multiple reports and incidents where hackers discovered thousands of completely unsecured MongoDB clusters which were exposed online without any protection whatsoever. And so this is especially unfortunate because Mongo, as any modern database system, has plenty of ways for securing the deployment. And combining it with third-party solutions like, for example, Teleport Database Access, which encourage and enforce good security practices can supercharge the security of your cluster. Now, let's explore a few ways and a few security properties we'd like our Mongo clusters to have, right? So starting from kind of the basics from the network layer, taking our server off of the public internet, public network would probably be a good first step. Partially, this could be achieved by using things like virtual private networks and firewalls. However, in the ideal scenario, the machine where your database service is running would probably be completely cut off from all the common traffic. This is not like a deployment model that MongoDB or any other major databases support out of the box, unfortunately. And using things like open SSH reverse tunnels can help a bit but be a bit cumbersome to set up and maintain reliably in a production environment.

Roman: 00:03:34.310 So next step is transport security. Most of the web has fortunately moved to TLS these days. But unfortunately, when it comes to databases, right, that actually keeps data, which is oftentimes very sensitive. They're oftentimes left without strong transport security. Authentication and credential management is another aspect where database administrators oftentimes take shortcuts. Not requiring any authentication for a database is kind of bad enough, but password management is hard and thus using a single user with a shared password, which is similar to a cessation into a server as a singular, for example. This approach is oftentimes the next best thing and it's not much better than a complete lack of authentication because not only it makes relocation and rotation painful — it also erases the identity information of the person actually connecting to the database, basically making the audit trail obfuscated.

Roman: 00:04:37.122 Now, building on top of strong transport security and authentication, access segmentation is another important property, right, of any secure MongoDB deployment. And control and access within a database is just one aspect of it, right? MongoDB has a very powerful role-based access control system allowing you to fine-tune permissions of users connecting to it. On the other hand, like in any organization, you most likely have multiple different database clusters for different purposes: staging versus production, or sensitive or non-sensitive data, and so on. And this is where controlling the access becomes a little bit more tricky. So, for example, how do I make sure that this particular user or this particular team only has full access to, let's say, a staging and non-sensitive databases, but also at the same time, being able to give them temporary privileges to a production database in case of emergency?

Roman: 00:05:39.881 So questions like this come up a lot, and most organizations end up building just homegrown tools to answer them. Now, moving on to this identity and all that kind of point here, I briefly touched upon this earlier, but when a user connects to a database for various security and compliance reasons, yeah, it is pretty important to know who they are exactly, right? So using shared accounts entirely obfuscates identity and removes the benefits or reduces the benefits of role-based access control. But even using something like a set of predefined accounts with different levels of permissions is not a whole lot better, and provisioning a database account for each user in your work is challenging from an operational perspective. So in the ideal scenario, you would know exactly who from your team who likely has a stable as a sole identity provider identity in your organization. So who are those users just connected to the database and what they were doing while they were connected to a database. So which brings us to the question of audit logging. In most scenarios, the best you can get out of the database, and it's not specific to Mongo, but the best you can do, probably, is get some kind of basic logging out of the box, right, that is not very easily exportable or analyzable, and moreover, not tied to the identity of the actual person connecting to the database.

How Database Access works

Roman: 00:07:11.523 Finally, it takes some work, as we've just seen, to ensure security when you have just a handful of databases. But managing an inventory of multiple MongoDB clusters in multiple different environments in a coherent manner and having a straightforward way to control access and all other things we talked about to them is an entirely next level of a challenge. And so as we went through all these challenges that you might encounter, so the reason we're building Database Access is to help solve some of these challenges, right? Help you configure your MongoDB clusters in a secure way. And on the next slide, we'll talk about how Database Access works and how can it help you achieve all of those security properties we just talked about. So on this slide, there's a diagram of a kind of typical example database access deployment, right? So for folks who are already familiar with Teleport, this should look very familiar because it's very similar how SSH or Kubernetes or application AXIS works, or even database access with different kind of database engines. But for newcomers, this, hopefully, should give a good enough high-level understanding of the architecture. So in this typical deployment, we have multiple Teleport components, right? So we'll take a look at each of those.

Roman: 00:08:37.102 So first off, we have a Teleport proxy here in the middle. A Teleport proxy is a stateless service that performs a function of an authentication gateway. It also serves a web UI and accepts database client connections, right? So within the Database Access kind of context, this is the component where all your clients connect to, right? This is the only public-facing component of Teleport. Next, we have a Teleport auth service or auth server which serves as a cluster certificate authority, right? Handles users' authentication, authorization, and issues short-lived client certificates, right? So Teleport uses client certificates as a primary means of authentication for everything including any type of internal authentication between kind of services it does. And so finally, this piece right here is a Teleport Database service. This is the database access's brain that connects to MongoDB databases, performs authentication, authorization, and the protocol parsing. To connect back to the cluster, database service establishes an SSH reverse style to the proxy, as you can see here. And as such, users do not need any direct connectivity to the database service or the database this is actually connected to, right? So in this example, we have a couple. Well, I have a self-hosted MongoDB cluster and a Nettles cluster, which is being proxied for Teleport. So as long as the database service can dial back to the cluster's proxy server, it can be located behind a firewall without any bad connectivity whatsoever. Also, you can obviously have multiple database services connected to your Teleport cluster, and each database service can proxy be connected to multiple databases, so you can mix and match those in pretty flexible ways.

Roman: 00:10:32.719 Now let's take a look at a typical kind of flow database access users go through when they want to connect to the database. And now this will also be — we'll take a look at this as well during the demo. So first, whenever you, say, want to connect to a particular database, you log into a Teleport cluster by executing a tsh login command that retrieves your client certificate, right? So like I mentioned before, Teleport relies on client certificates authentication, and as such, it uses MongoDB x.509 authentication mechanism, right, which it supports out of the box. So once logged in to the Teleport cluster, the user can see the inventory of all MongoDB clusters registered with this Teleport cluster, right, which is obviously subject to RBAC checks, right? So the user would only see the databases they have access to as their Teleport role allows them, right? So once they pick the database they'd like to connect to, they retrieve another short-lived certificate specifically for connecting to this particular database instance, right, and this certificate just kind of depicted here on the left beside each kind of client on this diagram, this certificate contains a user's identity information and some kind of route information, which is used for RBAC and audit logging.

Roman: 00:12:00.988 So once they have retrieved the certificate for the database, the user can use a standard MongoDB client, which could be, for example, a Mongo Shell or one of the graphical UI clients like the additional one like MongoDB Compass, for example. So they use one of these standard clients to connect to the proxy authenticating with this client certificate they have just retrieved. So then the proxy looks at the cert and dispatches it to an appropriate database service over [inaudible], right, based on the routing information encoded in the client certificate. The database service authenticates the connection, that forms an authorization check with the auth server to make sure that the user who is connecting has the access to the database indeed, and then it establishes a connection to a target DB, let's say like this south coast MongoDB instance here, and starts proxying all the traffic back and forth between the database and the client interpreting all the protocol messages in between then performing audit logging.

Features overview

Roman: 00:13:09.068 So now, this is basically the way it works. And we'll see like I mentioned before, a lot of these during the demo, so it hopefully becomes even more clear. Now before jumping into the demo, let's quickly go over some of the Database Access features and see how this architecture enables soluble security properties we talked about in the beginning. So first, your MongoDB clusters are never actually exposed on the public network, right, and instead, connect back to the Teleport's proxy or the reverse tunnels established by the database agents. So Teleport keeps a central inventory of all registered Mongo clusters allowing users to see all clusters they have access to at a single glance. So then administrators can also set up flexible, role-based access control policies to allow or deny access to specific Mongo clusters based on the user's identity information, which can also be tied to your identity provider, right? So basically, what you get with this is as a SSO into your MongoDB cluster or multifactor auth into your MongoDB cluster.

Roman: 00:14:23.685 Teleport can also restrict access to your specific Mongo databases on the RBAC level as well now, which is not technically kind of a feature but rather a security property of the system, right? But like I mentioned, Teleport uses mutual TLS pretty kind of heavily within the system and relies on short-lived certificates for authentication, which means that connection to Mongo basically gives you end to end mutual TLS, right? So as based on the architecture diagram — let's go back a second. At each hop of the connection, right, MongoDB client to a Teleport proxy, proxy to database service, and database service to the actual database. Teleport relies on mutual TLS, right? Now, all MongoDB commands are executed while you are connecting to the database are recorded, obviously, in the audit log, right, which can also be shipped to an external SIEM system. And in addition, each audit log entry also includes information not just about the database user, but your SSL user as well, right? So this way you can map activity within the database to a particular user in your organization and not just some shared account they're using to connect to the database.

Roman: 00:15:47.243 Another useful feature is integration with access requests, right, or access workflows, which allows users to temporarily request elevated privileges to databases that they don't normally have access to, right? This is just like their temporary production access that we discussed in the beginning. And so finally, Teleport trusted clusters feature allows to provide unified access to many MongoDB clusters deployed in different environments, right?

Demo time

Roman: So let's now jump into the demo and take a look at some of these features in action. Well, out of this presentation and let's go over my setup a little bit first. So for this part, we're going to look at my terminal and some IDE. So my setup, right? So I have two MongoDB clusters, which is a local MongoDB cluster that I have deployed in a Docker container, right? So you see can I have a couple of other containers right in here, but the one we're interested in right now is this MongoDB cluster, which is a replica set, right? So I have a Mongo one and Mongo two, which comprise a single kind of MongoDB replica side cluster.

Roman: 00:17:11.829 And then I'll go back to my browser. I have a test Atlas deployment, right? So we'll also take a look at connecting your Atlas cluster to Teleport Database Access, right? So now let's take a look at the configuration of my Teleport cluster, right? So it's specifically a database service configuration of my Teleport cluster. And so this is the relevant part. Again, for folks familiar with Teleport, this is just a part of your standard Teleport YAML configuration file, right? For folks who are new to Teleport, so Teleport uses YAML format for configuration and this is how you configure the particular database service, right? You can see that in this case, I have three entries. So these two establish connection to my local MongoDB cluster. And the reason I have two entries is because I have two nodes in my MongoDB cluster and I just want to demonstrate that Teleport can also connect you not just to primary member, you can also instruct Teleport to kind of land you into a secondary MongoDB instance by default if you'd like, right?

Roman: 00:18:27.766 So otherwise, you will see that you are supplying your connection stream to Teleport, which is how Teleport knows where to connect, right, to this particular cluster. And the only difference between those is that in a second case, I will have [inaudible] preference secondary, which indicates to Teleport that it should prefer connecting to a secondary MongoDB cluster instance. And so finally, the third entry I have here is for my Atlas cluster. And again, as a URI here, I'm just using the connection stream that Atlas gives you on the Connect page. Another kind of important thing to note here is these static labels, right? So take note of how we're marking each particular database entry with the static labels which are then I'm going to be used in the role-based access control, right? So labels is how Teleport allows organized access to various pieces of your infrastructure, right? And we can see here that I have Environment Local label for both databases, which represent my local MongoDB cluster and environment cloud for the Atlas database just to showcase.

Roman: 00:19:42.983 So finally, let's log into my Teleport dashboard as well and go over my role configuration or all configuration, right? Or role configuration for my user. So for this demo, we're interested in this particular two roles, right, which I have, which are called DB Limited and db-full. And if we expand the description for each of those, we can see that this particular DB Limited role only allows the user of this role access to databases that are marked with Environment Local, right? So in our case, if we go back to VS Code- where is it? - configuration, the user that possesses DB Limited role should only be allowed to connect and see these two databases, right, because they have the same Environment Local label. And so finally, there is a DB Full role as well, which has a Wild Card DB labels, which means that users who have this role, they should be allowed to see and connect to all the databases.

Roman: 00:20:46.572 Now, with the setup out of the way, let's take a look at how we actually try to connect to a database, right? So I'm going to start by logging into my Teleport cluster. So like I mentioned before, again, familiar for folks familiar with Teleport. For new folks, tsh login command is how you log into your Teleport cluster. So proxy is the Teleport proxy endpoint, right? In this case, we're just telling it to use a local user, right, because I could also tie it into my identity provider. But for this demo, I'm just going to use my local Teleport user and their password. And what TSH login command did, it basically retrieved me credentials. A short-lived certificate which allows me to interact with my Teleport cluster now. So now, if I want to see the inventory for my MongoDB clusters connected to this Teleport, right, I can execute the tsh to the login command. Sorry, tsh to tls command. And in this case, you can see I only have access to two entries, right? As we discussed before, my current role, which is shown right here, DB Limited, only allows me to see databases with environment local label, which is why this command only shows me these two entries.

Roman: 00:22:15.096 Now, let's say I want to connect to Mongo primary here, right? So to do that, I need to execute the tsh db login command, right, which is very similar to tsh login which ran in the beginning, which actually is going to retrieve me a client certificate for connecting to this particular Mongo primary instance, right? You will notice that I'm also supplying it with a DB User flag. So the Roman T is a user that uses x.509 authentication that already exists in my Mongo database, right, that I have preconfigured before. So let's do that and retrieve the client cert for connecting to the database. And now, once we have retrieved the credentials, what I can do is I can obviously use the standard Mongo client to connect it, or I could use the pretty convenient shorthand that tsh gives you, which is just tsh db Connect, right? So you don't have to remember all these flags and other things you need to include in the standard Mongo command. So you could just execute tsh db connect and then basically it takes you into that local Mongo DB instance. So one of these containers is where we're currently connected to.

Roman: 00:23:35.681 So if we go back a second to my — so now we're connected, right, but let's go back a second to my Teleport Control Panel and take a look at the Activity tab, right? You will notice that Teleport has detected that I have connected to the database, right, and logged the Database Session Started event. And it already started logging some database queries, which the Mongo Shell client executes, so. But we could also try and execute a few queries of our own and see how Mongo and Teleport behave. So first, we could run the connection status command just to make sure that we're connected as a proper kind of authenticated user and check our permissions, then we could do something like db.test.find(), db.test.insert({“hello”” “world”}). Just run a few kind of standard MongoDB queries. And if we go back to the Audit Log and refresh the page real quick, we can see that, for example, this is the find command that I ran before, where it was recorded in the Audit Log. We could expand the details of this particular audit log entry and view the full command text as well as the names of our database user, which we were using to connect to the database, and the Teleport user, right, which, as I said before, it can also be tied to your SSO identity, right? So this way, you kind of get the marking of a particular user — of the actual user in your organization who was performing, let's say, this command or this query within the Mongo database. Then we can also take a look at this event, right, which is our insert command that we ran, and also take a look at all the same information, basically.

Roman: 00:25:34.282 So now let's kind of exit out of here and just tsh db ls command again. You can see that it depicts the database you are currently connected to. Now, let's say I want to connect to a secondary instance, right, just to see that [inaudible] takes me into the secondary replica set member now, and I can use another db login command, right, to retrieve credentials for this particular instance. Secondary. So this is the same cluster so I'm going to be using the same user, and we can all, basically, kind of clear from this command right here, or you can be logged into multiple databases at the same time if you'd like to. And you can execute tsh db, connect mongo-secondary, which is taking me to the same cluster which we were connected to before, but, obviously, to a secondary member, right? So from here, we can do pretty much all of the same stuff like explore status for a replica set. [inaudible] holders to this probably won't work because this is not a primary member. But if you do like this, it probably should work. Yes. And obviously, if we go back to the Audit Log, we can see that the database session and event has also been recorded, right, when I disconnected from my primary instance, and when I connected to the secondary instance, the behavior is pretty much exactly the same, right? So everything is obviously recorded with the only exception that it has connected me to the other member.

Roman: 00:27:21.810 Now, let's also try something else and try to connect to the database with, let's say, a user that my Teleport role doesn't allow me to connect this, right? If we go back a little bit to my Teleport role configuration and take a look at db-limited role, you will see that another property you can enforce, right, in Teleport RBAC level is db_users, right? So db_users, basically, is a list of allowed database accounts that you can connect to the database sets. So in my case, my db-limited role allows me to use ls or r0mant accounts. So let's see what happens if I try to connect it as some other user. So let's see — tsh db ls. Run tsh db logout to clear all the credentials and do the login again. Let's say now user admin, right, or some superuser. So now let's try to connect. So obviously, this is not working, right? I get the “access denied” there because I'm not authorized to connect to this Mongo instance as that particular user. And if we take a look at the Audit Log event, the incident was recorded, right? “Database Session Denied”, and it records the name of the database user that I attempted to connect to, which is kind of very helpful for various kind of compliance and security reasons, right, to be able to have this information.

Roman: 00:29:00.714 Now for the next kind of step of the demo, right, first, let me log out again. Let's pretend that I'd like to now connect to my Atlas instance, right? If you remember from the setup, we actually have an Atlas database connected to this cluster as well, which I'm not currently seeing just because my limited role doesn't allow me to. So what I can do to do it though is — I can request a different role. I can request that db-full role too. Access to this db-full role so I am able to see that Atlas database, right? So the way I'm doing this is I'm sending an access request, right, which is tsh login command with a Request Roles flag and pasting the name of the role I'd like to assume temporarily, right? And the admin Teleport cluster administrator can approve, or other users who have access to approve or deny request can take a look at this access request and approve it or deny it. And in general case, we have integrations with various third-party systems. Like these approval requests can go to PagerDuty, to Slack, to Jira, to some other kind of systems. But in my case, I'm going to just go ahead and approve it from the command line. So we see this is the request that's pending. Right. So let me just try and request approve real quick. All right. So approval received. Right. If we run tsh status again, we can see that my role list now includes db-full, which should allow me to see the third database, right? The one with the environment equals cloud label. So now I can see it and now I can connect to it, basically, exactly the same way as I did to the other two, right?

Roman: 00:30:58.144 So if I execute tsh db login command I have prepared, in my Atlas cluster, I am using the Atlas username, right, which is at this point actually my [inaudible]. Go back to my Atlas cluster deployment a little bit and take a look at how it's configured. Right. So obviously, like I mentioned on the architecture slide, we're using x.509 authentication with Mongo, and this is something that Atlas supports out of the box, which we call self-managed x.509 authentication. So if you go to your Security Advance tab, go to Enable Self-managed x.509 Auth, set it to On, and upload Teleport CA, right, to it so your Atlas cluster knows to trust client certificates generated by Teleport database service. And so finally, when it comes to user configuration, here on the Database Access tab, pair this Atlas user preconfigured here, which uses x.509 authentication method. And if you go to your database user, this is the type of authentication method we select, right, certificate. And an important kind of point to note here is that MongoDB treats the whole client certificate subject stream as a username, right, which is why it says here CN=atlas, right? So common name equals Atlas is the correct format for a database user.

Roman: 00:32:31.620 But now let me connect to, actually, Atlas using this Atlas user — tsh db connect. Right. So now, I'm inside my Atlas cluster, right, and I can pretty much do everything else I've been doing with the other clusters as well with my local cluster as well. And back to Open Audit Log. Everything is obviously still kind of recorded. All right. So now for the final part of the demo is a kind of final bit I would just like to show that can also use graphical UI clients to connect to your MongoDB clusters, right, if that's your jam. So if you prefer to use a — there is a GUI clients. You can do that as well. So it preconfigured here, so if we expand the details of this particular connection. This is MongoDB Compass, by the way, so this is the kind of official MongoDB graphical client, right, which I'm using here. And you can see that in this Connection Configuration, I have a hostname imported points to my local Teleport cluster, right? And in the More Options, obviously, I am selecting Server Client Validation and providing with all the secrets for this connection, right? Same as you do with your Mongo Shell client. Now let's go ahead and try to connect. It should work. So you see that takes me to basically my Atlas cluster, right, through Teleport, and I have preloaded that Atlas cluster with some sample data so we can go around and explore different collections in exactly the same way as you would if you were connected directly to your MongoDB instance, right?

Roman: 00:34:28.963 But obviously, in this case, we're connected for Teleport, and if we just want to make sure, just take a look at the audit log again and see that all the Atlas has opened, actually. A few connections, a few sessions. Actually, more than a few, and started executing different queries. So, for example, this is a query corresponding to retrieving data from this sample_airbnb database, and so on and so forth. And you go ahead and disconnect from here now. It should hopefully close all the connections. All right. So that concludes our demo. Let me log out from here as well and log out from Teleport. And let's swing over back to the presentation and keep going. Right. So hopefully the demo was interesting and informative, right? Before we wrap up, I just wanted to mention that today we were obviously focusing on the secure access to MongoDB with Teleport Database Access, but there's just kind of one piece of the whole Teleport Access plain story. In addition to Mongo, Database Access currently also supports Postgres and MySQL protocols with more to come, and as well as it also provides access to other pieces of your infrastructure such as SSH servers, Kubernetes clusters, web applications, and cloud consoles. And so feel free to kind of check it out if you're interested in any of those as well.

Roman: 00:36:13.362 And so finally, for the next steps, I'm just going to leave a few helpful links on this slide. So if you're new to Database Access or Teleport in general, I would start with the introduction and then move on to exploring the MongoDB guides which are relevant to your use case, which we have a few, right? So we have a specific guide for configuring Database Access with your self-hosted MongoDB cluster with MongoDB Atlas using self-managed x.509 authentication and using different GUI clients such as MongoDB Compass, right? So finally, everything we've talked about today is available in open-source Teleport version, right? And MongoDB support is included starting from Teleport 7, which we released just a few days ago. So go over to our Downloads page, feel free to download it, and start exploring. So thanks, everyone, for your attention. Now is the time for questions and answers if we have any. I think you are muted, Ben. We can't hear you.

Q&A

Ben: 00:37:25.324 Oh, there I am. Hi, everyone. Yeah, thank you, Roman. That was an awesome presentation. I got to see the GUI demo too, which is pretty cool. Yeah. I know there's a couple of people on the call. Feel free to open any questions if you have them. I have a few which I didn't send you, Roman, but these are easy ones to get started. So my first question is: is there any performance overhead with using Teleport Database Access?

Roman: 00:37:54.534 Yeah. Yeah. Of course, there's going to be some performance hit, right, because the database service performs all the protocol kind of parsing and proxying back and forth, right? So there is going to be some performance hit for this. The primary use case, I would say, for Database Access though, at least at this stage, right, of the project, is connecting to a database for different maintenance activities, right? Like executing queries and stuff. So we probably would not advise you to connect your applications that are critical from a performance perspective for Database Access. Although you obviously could do that, right? Just be mindful that there might be some performance hit, a little bit of performance overhead. Otherwise, yeah, you can connect your robots, for example, your CI or CD systems that need to perform some data migrations or some other activities within database like let your users connect to the database. Yeah. In this case, it should be pretty transparent for our users.

Ben: 00:39:04.226 And so if I had a CI or CD and I want to know what this migration was running, how do I create the user for the robot?

Roman: 00:39:14.714 Yeah. So you create a same user for the robot in the database, right, with appropriate permissions that you'd like the user to have. So for example, if this robot user only needs access to a particular database or a collection, so you provision an appropriate user in your database with x.509 off, and then you create the corresponding user for your robot in Teleport, right, and generate identity. We have guides on generating identities and using all these tsh and database tools. We pre-generate the user identities as well, right? So and then you give your, say, Jenkins user or TeamCity user or whatever CI system you might be using these credentials and point to Teleport proxy, right, and the identity file. And that's how it's connected to the database, basically.

Ben: 00:40:13.030 And then you can also set the length of that certificate long or short or use the same short-lived certificates too.

Roman: 00:40:19.465 Yeah. Yeah. You can generate certificate with TTL that is fitting for your use case. Right. So you can tweak TTL. You can do it super short, which is what we recommend, usually, right? The shorter your certificate is or the sooner it expires, then the easier it is to revoke access in case of some security incident or something. But yeah, you basically can tweak the TTL of your credentials. Yeah.

Ben: 00:40:49.314 And if you're running the Database service sort of next to the MongoDB — I know when I set this up, my Mongo database was in a VPC, so it's going over localhost, so I guess that helps with network security. But for that service, is there an instance size that we recommend for the Teleport DB service?

Roman: 00:41:10.851 So DB service itself does not add a lot of kind of overhead to you. So whatever instance size you're using for your MongoDB instance would probably be fine to just deploy database service on top of it, right, as [crosstalk].

Ben: 00:41:25.889 As it is. Run it is a sidecar on that instance.

Roman: 00:41:28.188 Right. Right. Right. Exactly. Yeah. There are different ways of deploying this. You can collocate your database service with database, right? Like you said, deploy it as a sidecar, which is a good pattern. You can also just deploy database service on a different node and connect it to multiple database instances, right, and kind of mix and match in this regard.

Ben: 00:41:54.368 And then I know we have Atlas and self-hosted MongoDB. Are there any other providers that we currently support?

Roman: 00:42:02.155 So for Mongo, no. From authentication standpoint, anything that supports self-managed x.509 authentication method with Mongo will work, right? So anything that lets you upload your own certificate authority, so like, for example, Atlas does, right? So like I was showing before, it lets you upload Teleport certificate authority, which is how it can validate client certificates generated by Teleport. Right. As long as the cloud provider or your MongoDB deployment allows you to do that, it can be used with Teleport Database Access. We don't support any other authentication methods currently. Like we don't support username and password, right, which is our intention, basically, right? We like to rely on client certs or auth. We may look into supporting AWS IAM auth at some later date, right, because I know the latest MongoDB version, I think, has support for AWS IAM auth, and we're also using AWS IAM with things like RDS or Redshift, right, and Cloud SQL.

Ben: 00:43:17.030 Yeah. I know there's also the note to people who set it up. Once you have enabled TLS setup in your Mongo, the passwords no longer work, right?

Roman: 00:43:29.016 Yes. Yes. Yeah. I think there is a setting that allows you to connect without a certificate or something like this. But in general, yeah. And I think it's a good kind of practice in any case.

Ben: 00:43:43.606 Yeah. Instead of the passwords. Yeah.

Roman: 00:43:45.270 Right, so.

Ben: 00:43:48.590 Yeah.

Roman: 00:43:49.022 But yeah.

Ben: 00:43:50.846 Well, I don't have any questions and no one else has come in, I guess my last question would be, what are you working on next?

Roman: 00:43:59.212 So with regards to Database Access, the next protocol we're looking to support is very likely to be Microsoft SQL Server. And we're kind of going top to down on the list of most popular database engines, I guess, right, which is with MongoDB, Postgres, and MySQL, we've got three of the top five kind of spots covered. Next stop is SQL Server, which is pretty popular. And we also do have kind of a whole list of different requested engines on GitHub. Redis has got quite a bit of upvotes. We had some mentions of Cassandra, Elasticsearch, I think, and a bunch of others. So I'm not sure, to be honest, when we'll be able to get to those. We obviously want to cover all protocols out there. The sooner the better, so. But yeah, priority-wise speaking, probably SQL Server.

Ben: 00:44:59.320 Well, I look forward to doing one next month with SQL Server. [laughter]

Roman: 00:45:03.601 All right. [laughter][inaudible]. [crosstalk].

Ben: 00:45:05.483 Anyway, thanks, Roman.

Roman: 00:45:07.089 All right. Thank you, Ben.

Ben: 00:45:07.093 And thanks everyone lot for joining today. And if you have any other questions, feel free to either leave a comment on our GitHub discussion board under Teleport, or you can join our Slack community. Thanks for joining.