Securing Access to Fleets of Postgres and MySQL with Open Source Teleport - Overview
Most of the world’s Personal Identifiable Information (PII) is in a database, but is access to databases secure enough? Companies are unable to maintain fine-grained control over access to their data and cannot map database activity specific identities. This complicates auditing and compliance and compromises database security. Join this webinar for a deep dive into the kinds of questions you need to answer to secure database access:
- How do I provide access to a specific database?
- Which user ran “select *” on production?
- Who connected to the database as “postgres”?
- How do I connect to the database in a different cluster?
Learn about the best way to approach secure database access at your company using open source Teleport.
Key Topics on Securing Access to Fleets of Postgres and MySQL with Open Source Teleport
- Teleport Access Platform is an identity-aware multi-protocol access proxy, which currently supports SSH, applications, Kubernetes, and several databases.
- Teleport currently provides secure access to PostgreSQL, MySQL, and MongoDB databases, while improving both access control and visibility.
- Users — once initially authenticated — are allowed to request roles both from the Web or from the command line.
- The audit log tracks activity, logged-in users, their requests, user sessions, and session content.
- Teleport documentation provides information on database clients and how to connect them.
Expanding Your Knowledge on Securing Access to Fleets of Postgres and MySQL with Open Source Teleport
- Teleport Database Access
- Get started in 10 minutes
- Database Access with Self-Hosted PostgreSQL
- Teleport Quick Start
- Teleport Unified Access Platform
- Teleport Kubernetes Access
Learn more about Securing Access to Fleets of Postgres and MySQL with Open Source Teleport
Introduction - Securing Access to Fleets of Postgres and MySQL with Open Source Teleport
(The transcript of the session)
Stephen: 00:00:01.120 Welcome to today's webinar brought to you by Teleport. I'm Stephen Faig, director of Database Trends and Applications and Unisphere Research. I will be your host for today's broadcast. Our presentation today is titled Securing Access to Fleets of Postgres and MySQL with Open Source Teleport. Before we begin, I want to explain how you can be a part of this broadcast. There will be a question and answer session. If you have a question during the presentation, just type it into the question box provided and click on the submit button. We'll try to get as many questions as possible but if your question has not been selected during the show, you will receive an email response. Plus, all viewers today will be entered to win a $100 Amazon gift card just for participating. Now to introduce our speaker for today, we have Steven Martin, Solutions Engineering Manager at Teleport. Now, I'm going to pass the event over to Steven.
Steven: 00:00:57.863 So we'll be first going over the Teleport Access Platform so you can understand how Teleport provides access to protocols for your organization. We'll then be focusing on how does it provide access and auditing for database resources for MySQL and Postgres. Then we'll go into a demonstration about DB Access and sort of a real-world scenario of someone who wants to get into, initially, their dev environment, and then requesting access into a production system so they can update a similar schema, the typical rolling out changes or fixing an issue. And then, as Stephen mentioned, we will have a Q&A time to cover any of your questions you might have about Teleport. All right. So first, let's talk about how Teleport works. And you often have a set of developers or site reliability engineers that need access to pick their resources. And those resources could be on a private network, a cloud provider like AWS, IBM, or Azure. And there's a number of different protocols that you want to connect through. But of course, you don't want to have a heavyweight solution or have different passwords or access keys, or you might have that now, and you're looking to change that to make that a simpler, more secure solution.
Overview of Teleport Access Platform
Steven: 00:02:33.924 So the Teleport Access Platform is an identity-aware multi-protocol access proxy, which supports currently, SSH, applications, Kubernetes, and database. And a key part of its architecture is to utilize short-lived certificates for authentication. And you'll see, as I go through the demonstration, I'll be authenticating the user using a Single-Sign-On, and that will issue the user a short-lived certificate. And versus things like access keys or passwords. We feel that's the safest method and one of the best methods in order to authenticate a user, and then allow them to have permanent access at a later date. Now, in terms of how they interact, the user can interact with Teleport via desktop as well as the console. Teleport is a Go-based solution. It can be deployed in your own environment in Kubernetes, really any Linux machine. We have customers running ECS. All kinds of combinations. It also can be a highly available configuration or even run off a Raspberry Pi. So it's a very versatile system there. We also offer a Teleport Pro that allows you to host Teleport, and then also gain access to your resources there.
Steven: 00:03:58.710 Now, in terms of when a user wants to authenticate, as I mentioned, often, you would use a Single-Sign-On; you can use a local set of users. We support that with multi-factor authentication. Now with things like a Single-Sign-On, like an identity provider like Azure Active Directory, Okta, essentially, you'll be authenticating with that particular IdP — I'll be using Auth0 in my example — and then Teleport will confirm that authentication. And using the traits that come back — what are preferred usernames, what Kubernetes, what databases, you should have access. It can populate that user's role, and then issue a certificate that maps to that user's access. And once that user has that access, then they're able to list resources, and then specifically access those resources which Teleport will audit. Now, in terms of how they access, as you see in the middle, there's the Proxy and Auth. The Teleport Auth is what has state. It maintains a certificate authority which allows it to issue certificates for users and hosts. It also is tracking the audit log; what activity is happening, what user logging in, what requests are they entering, what sessions have started or ended, what was the content of those sessions. So it's tracking that and has state. The Proxy is responsible for allowing users and resources to communicate as needed. So there's a number of ports it provides, such as the Web console, Kubernetes, and others that allows you to interact with it both from the desktop as well as the Web console. But it has no state, so the Proxy essentially, again, is just really a pass-through, it confirms connectivity with the Auth server, which allows you to maintain those set of roles. It is a role-based access control system that enforces whether or not someone can access. And you can make it a very open system. People have roots, people have access to all databases, or very restricted where — as you'll see in my example — I'm restricting user [inaudible] dev environments, and then later, they can request to get into prod, only if approved.
Accessing and auditing database resources in MySQL and PostgreSQL
Steven: 00:06:17.570 Now, moving forward to focus on the database side of it. Again, we see that Teleport Proxy and Teleport Auth. So users will interact, after they've already been issued their certificate, they will issue themselves a database certificate. And that will allow them, per database, to identify themselves as authorized to connect with that. The user, in the case of like a psql or MySQL, will access. They could be doing a select*, they could be doing updates, but the Proxy will be sitting in the middle and intercepting those requests and communicating through a Teleport database service running on an agent somewhere, and could be Kubernetes, can be a machine — really anywhere. As long as it can connect to the database, it can run. And that will be used in order to facilitate the connection. Now, for each request they do, that user's access is confirmed. So if in the meantime, even after they log in, their role changes, they no longer have access to a database name or things, if they attempt to create a session or interact, they can be denied. So that allows you to have that type of real-time control in Teleport, either easily onboarding or offboarding individuals to have access to databases.
Steven: 00:07:38.762 Now, the database service you see there, again, that's an agent that runs at the same Teleport binary that's running for the Teleport Auth and Proxy. For both, whether it's our Enterprise or OSS, the agents can all be the community version. Very simple to set up, simple configuration. A few lines of YAML determine what database you're pointing at. You can use IAM specifications as you're connecting to things like Aurora. Or we also support self-hosted, which simply uses certificate authentication, that's basically allowing the Teleport Auth Service to connect through, and then allows it to connect to the user as another user that's authorized. Now, what we've covered so far is the architecture of how you just do the basic connections, how you're logging, how you're connecting. There's also the concept — as part of this conversation as well — if I have a large number of databases and they're spread across a large number of networks, what are my options? And some of our clients can have hundreds of thousands of databases. And often, it's not feasible — just like the idea that we have, multi-cloud regions, you could have multiple Teleport deployments that allow you to connect. So, again, we have the Proxy and the Auth where the user connects into. But if you look in the upper right, we have the Teleport leaf cluster.
Steven: 00:09:20.014 So that's an example of, let's say I'm running the Teleport server in the Virginia area and that's connecting to various databases, whether using a Kubernetes agent or, say, EC2 agent. Well, I might have another set of databases that are in a very different region, up in New York or somewhere else in the world, and also could be network restricted. I don't want to have hundreds of databases, the agents connecting back to a specific Teleport instance in a different VPC. Basically, I want to contain them and only have one particular Teleport instance in an isolated network. So you can at least cluster using our reverse tunnel connection. I can deploy a Teleport instance, have multiple resources connect into that, and then easily connect back to another Teleport instance and give access. So that's one way that we can provide connectivity without having to expose a lot of ingress. Most of our connectivity is egress where the agents themselves will dial home — let's say — back to Teleport, register themselves, and provide that connectivity of the database being available. And then if they do need to shut down, they just simply shut down and the database will automatically expire. So it's really good about supporting ephemeral environments where you're bringing things up, bringing things down. All of the databases you see there can all be labeled individually. So our role-based access control primarily uses labels to determine what resources you have access to. You can, of course, use regular expressions that will allow you to map to, let's say, all of the dev or all the staging of a particular customer.
Steven: 00:11:23.443 So in the case of hundreds or thousands of databases, you can come up with a very simple pattern that allows you to easily allow or restrict access to particular databases. Now, in terms of how that role-based control works, it has a allow and deny concept; the deny takes precedence. So if I have a database like — or if I say, well, all of the dev customer X are denied, combinations, and then I also add another role where a person gets — it is saying you're allowed to do that, the deny will take precedence. So that's a key part of our role-based access control, is to have deny take precedence. You also can control the length of a session, so how long can a person be in a session about without reauthenticating. And you can control things like port forwarding or other settings where related to our other protocols. Now, in terms of the demonstration we're going over today, again, we want to introduce you to the Teleport capabilities, how you interact with the various databases, see auditing, and get to understand some of the concepts I've been talking about, like a root cluster, a leaf cluster, what those capabilities can do for you.
Steven: 00:12:51.369 Now, next, we'll go into, what's in that auditing, what do you see when a user interacts with a particular database, and how is that made available in the audit log? Now, in terms of the actual scenario I'm going to run, you'll see two different types of access. You'll see a user that has a broader access, and then you'll see another user that's more restricted where they have a specific development database and also they can request access to a production database. The administrative user, they can approve that particular access and also monitor what that user is doing. All of the various auditing things we can do can be streamed to things like ELK or Splunk very easily. We also have a lot of customers who are using services like Datadog. So if they wanted to monitor for, let's say, particular queries or unusual activity like lots of sessions all occurring from one user, you could certainly watch for that. Now, as part of this concept, this idea of being able to look at what's in our data, what's happening, and often you want to progress your fix rather than just push doing your fix directly on state, let's say state, production or your preproduction — so you can see an example of a user interacting from a development point of view, and then requesting and getting access into production. So they can actually see the change that's occurred. And that's using our Access Request functionality.
Steven: 00:14:37.116 So Access Requests allow particular users, from their initial set of roles, to say, "Well, I want to request, let's say, production access or staging access," and whatever role they're asking for may have a particular label that allows them in. They saw their restrictions from their initial role, things like I mentioned about the “deny”, but they can use these new “allows” to allow them access to labels they may not have had access to for, may allow them to have access to different users. You might have a maintainuser or user that has specific DBA rights that are not usually given to users, and then those are given for that specific set of time, allowed for the role. All right, so why don't we step into the demonstration part, and we can see Teleport in action.
Stephen: 00:15:34.797 Looking good, Steven.
Demo of Database Access and requesting additional access
Steven: 00:15:37.017 Thank you. So you can see here, I've gone ahead and logged in to one of our web consoles, and you can see I have a set of database. On my left, I have all the resources I have access to. You can see I have up to 200 different databases here. I have some MySQL. We can also see that we have some Postgres that are available. In addition to just listing the databases, I have my set of labels, and these labels allow you to distinguish the type of environment it’s in — is it production, dev, staging? And again, these labels are used in terms of the roles. Now, from my desktop, I wanted to connect to it, it gives me information about how to connect. I should be logged in. I should log into that specific database, and then I can use things like the direct MySQL. You'll also see how you can do that from a GUI client, which is pretty popular when it comes to databases. So why don't we take a quick look at that, and then we'll be coming back into the console. So here, I already have my [inaudible] to log in. I'm using my Auth0 as my Single-Sign-On. And that will automatically open up a browser window. This is connected to my Google account.
Steven: 00:17:12.981 And then there's a little "login successful." And as I mentioned before, it will issue that short-term certificate. I can see I have 12 hours on that certificate. That's the default time. It can be made higher to, say, 30 hours. Also, the user themselves can reduce that, let's say if they're in a system where they're not going to be using it for a large amount of time. There's some other settings you can see here. We can see what roles set to it. In this case, just a simple dev access they're using. And I'll go over what that entails. Now, from here, I can again list databases. You notice this user just has one database listed, and that's due to their role because their role has a more restricted access than the administrative user I was on. If I want to log in, simply do that. It'll give me information about how I can connect into the system. Now, like most people, I like the GUI approach. So I'm going to use my MySQL Workbench. Connect to the database. You can see here I have this "stevendev” user and I'll show you in a second some more information about how is that. I've set in my SSL settings. Oops. [inaudible] in here.
Steven: 00:19:00.562 So now I'm in the system, I can do this, like * from departments. To that, we'll come back, something's a little off here, we'll be coming back to this. And I think in this case, I just need to do a minor — okay, never mind. But I can see here that something looks off in terms of this data, but we'll come back to how we want to fix that. And we can see here in terms of what's been happening, I can see that a session has started, this particular user has connected the database “employees”; what user has done. This information is in a JSON format. This is the particular database that it’s connected to, so this is an Aurora RDS database running MySQL. Now, in terms of the query that are being run, this was the actual one I ran, so I can see the query, what it's connected to, what DB user is used at the time. Now, in order to get access to that, we had our role configured. We can see here, this devaccess user. So within this user, we've set particular settings. We're allowing them to connect, really to any database user they want. We are restricting what databases, though. So they can only match to environment of dev with the machine of mark 3. I'm just using that “mark” idea.
Steven: 00:20:35.183 And then in terms of what else they can ask for — they can ask for prodaccess or prod-mod access. So the user — when they're initially authenticated — they're not given these roles, but they are allowed to request them. They can request them both from the Web or from the command line. We'll be using the command line today. Now in terms of the user I'm using, admin, that user has a review setting. So that user is allowed to see any role coming in. In this case, I'm using *. I could have restricted that further, saying, "Well, I don't want you doing prod or a specific prod role." So you're able to really further restrict how they're able to get in, if you like.
Steven: 00:21:33.296 So, as I mentioned, this user currently has devaccess. They did see an issue with a particular set they want to confirm. Okay, am I seeing that issue in prod as well? Let's go check.
Steven: 00:22:03.424 So now we've asked for this particular role in mod access. And then because my user has those admin rights, I'm able to review that request. We can see it earlier had been approved, that had already expired, that usage, and now we're going to review this one. And from here, we can approve or deny. Approve. “Please go check.” Just so you can see it, there is an “Approved” option here. Submit that “Approved.” And now it's available. So now this user has both the devaccess and the `prod- mod-access”. If we take a look back at the audit log, I'll be able to see whether that request was created, and then that request was reviewed; who approved it. We can see all of those details. And again, all of this can be fed into an ELK or Stack of that nature. Now, in this case, the user can then list the database, they can connect through.
Steven: 00:23:23.137 In this case, we're going to connect into the prod and see if we see the same issue.
Steven: 00:23:39.785 Yep. So we're seeing that same item. Now, in this case, I'm navigating in databases, connecting to this particular cluster. You notice up here, there's another dropdown for clusters, so I can actually navigate to that other cluster as well. So this is a separate Teleport instance that's running. It has its own off-service. It has its own proxy and then resource [inaudible]. But my roles can map to that, and then I can see these various databases are available. I can look at the audit log that was occurring on that machine. You'll see that has remote, so earlier I connected through and done some interaction here. And again, part of the power of this is that this cluster can be in a completely different region, doesn't have to have any ingress made available to users, but you can connect easily through and provide access. Now, in terms of, if I want to update this — and let's try that MySQL Workbench again, let's see if I — a little better luck here— my “maintainuser”. And one thing I was doing, and I didn't get to explain that too well, we have our DB list, which tells us which databases we've connected through. You can see here, I'm currently connecting to prod, and I can always see, "Okay, what is my config?" So I can see that I'm connecting through onto this particular host. That's my proxy connection. This is the port it's sitting on. And then these are the certificates that are going to be used when it makes those connection. And in terms of a client like Workbench, those are used — I'm going to say, this user, I'm using the same hostname and the port. What schema? In this case, employees, I want to connect to. And then I give the various keys just like it mentions there.
Steven: 00:25:46.864 Okay. So better luck this time. I think I mistyped a particular file path there before. So sorry about that. But then the user can query, look at the particular departments. And this is just an employee sample database that's made available for a lot of MySQL. I can go in. The convenient thing about the GUI — I can directly apply it. I can make the change. We can see what query is going to occur, and apply that change and close. So now let's go back to in terms of our audit log and see what we saw there. And you can see, we did execute this query. It did modify the data. We'll also see any other activity that's happening from as we're in the interaction and also when the user closes a particular session. And that will also update here. And we see that session has ended. So that's being tracked as well, not just the queries that are occurring. And again, you can keep track of that and make sure if people are doing an unusual number of sessions or accessing tables that you expect to be sensitive in nature at all.
Steven: 00:27:38.248 And just to go back over, in terms of the roles — so the major difference in terms of when I got access to that particular role, this role has the label of environment prod and mark3. So they are only going to be able to access databases that have that particular labeling. I also could have put ‘mark’ — like a star, to say that, well, this person can access any of them that match that particular expression. You can also, from your external, SSO, you could have put in a particular mapping of, let's say, {{external.machines}}, so that way, it could automatically populate a set of machine names into here. And that's something that often is popular if you have a certain set of groups. We also support regular expression functions. So if you want to do even further substitution of looking for something like the group names I get back don't exactly map up, then you have a lot of flexibility there in terms of modifying what comes back and how you map into it.
Steven: 00:29:06.734 Now, currently, we support the Postgres, MySQL. We also support Redshift on Amazon. We're looking at a number of other databases that we want to support in a similar way in terms of access and auditing. And in terms of how you deploy that, you notice that you can't really tell, "Well, how is this connected? Is this on a kube agent? You're running it from a Helm chart? Is this on a EC2 machine?" And really, to the user, that's not visible, but it's very — so in that way, the experience is very seamless, they don't need to know that. They simply just need to see the database, see what they can list and connect to. In terms of adding more database, it's very simple, you would just add a new token. You can see here we have various help in terms of if I want to add in other types of databases, it gives me information, you'd add a new token. And we use the concept of tokens to allow you to initially authenticate the node that it has access as a database type of service. After that, it forms a certificate relationship, just like when the user logs in, they receive that short-term certificate. We also use certificates for our node agents, and that allows them to maintain a relationship going forward. The token then is not required unless you add a new protocol. In that case, it's a very simple architecture to add in new items, but also very secure.
Steven: 00:30:45.480 In terms of here, you would simply just have the Teleport service that can run; what database it's connecting to, what's the URI? And then in case if you're doing the RDS, what's it region? If I was doing a self-hosted, it's simply the URI because I would deploy out the sign certs from Teleport into that service, and then that would allow it to connect and act as other users.
Q&A time
Steven: 00:31:23.338 Well, Steven, that was most of what I wanted to show today. I'd be interested if we had any questions.
Stephen: 00:31:32.498 Fantastic. Thank you very much, Steven. So we can go into questions from our viewers now. First question, does Teleport work with PhpStorm?
Steven: 00:31:43.713 It does. There's a number of database clients that we support, and we keep trying to add more information about that. If you go to our goteleport.com/docs, in our Database Access, we have information on database clients, how to connect them. Often, as you saw, you can use that tsh db config to see the list of the SSL files. And provided that they do support certificate authentication, that those type of applications should work. And we do have clients that have tested and confirmed that PhpStorm works.
Stephen: 00:32:24.426 Understood. Next question. If a user's role should not allow access anymore to database names, are changes immediate?
Steven: 00:32:33.886 They are immediate for next sessions. As you saw, I had a star for which database names to connect. If I wanted to restrict that to employees or another schema and you change that, then yes, the next time the person tries to connect, they'll be denied if they tried to do something they're not allowed anymore. So that effect is immediate. There are other ways that you can disrupt, stop a person's access. So there's a lot of good safeguards in there to prevent people who should no longer have access and you need to quickly off board them from that access.
Stephen: 00:33:11.187 Got it. Our next question is: Is Teleport suitable for a Windows-only environment?
Steven: 00:33:19.048 We support from a client perspective. If you're going to be using database clients from Windows, we do offer a tsh client that can work in Windows and that allows you to access in there. The hosting of Teleport is on Linux machines or through our self-hosted cloud. We are looking at expanding some of our Windows support. But currently, in terms of hosting, it is Linux.
Stephen: 00:33:53.380 Got it. Okay, next question. How do I connect to MySQL, Postgres to Oracle?
Steven: 00:34:01.832 Okay. Currently, we support MySQL, we do not support the Oracle database. We are looking at it, that's likely to be one we could add in the future. And as we progressed, we initially released MySQL and Postgres support for RDS, and then self-hosted. And then within a couple of months, we added Redshift. We're adding MongoDB, going into our version 7.0, which is being released next month. So we are progressively adding new databases, and we expect to really expand that list going forward, to a large list of the most popular databases. So Oracle is definitely one we could do. I'd suggest, you can always watch our preview releases, which is part of our docs, to see if that's something that's coming up. And we do tend to put out a lot of our RFDs or other announcements that will allow you to see, well, what's coming up for Teleport and when will this be supported?
Stephen: 00:35:07.588 Thanks for clarifying. Next question. Are there any limitations on Target MySQL Versions?
Steven: 00:35:15.868 As long it can do the certificate-based authentication, then you'll be fine. There are some specifics on the MySQL version in the high 8.0 version. So you could run into some issues with that. If there are, you could always to reach out to us on our Slack channel at /teleport, and we can always see about ways for you to get that. But in general, there's not very many restrictions. It's simply that there was a change from, I think, it's 8.0.3. Or a very specific minor version of MySQL modified the way it recognizes the MySQL version and that's something that we have seen as an issue in some cases.
Stephen: 00:36:13.013 Understood. Another question. Can it integrate with AD and SSO for password-less authorization?
Steven: 00:36:23.037 What was the —? AD, SSO, what was the other part there? I'm sorry?
Stephen: 00:36:25.808 AD and SSO for a password-less auth.
Steven: 00:36:31.970 Oh, Active Directory. Yes. No, definitely, that is supported. We do have documentation on using Active Directory or ADFS for Single Sign-On. That's a very popular option in terms of doing that. And as said, we have detailed examples of how to use that.
Stephen: 00:36:54.402 Gotcha. The next question. Is the user interface available via mobile access as well as computer, i.e., is there a mobile app-based access option? Thanks, very interesting presentation.
Steven: 00:37:06.521 We have looked at mobile. I'd say, presently, we don't have a specific mobile version, we don't have a mobile app. The Web application is very friendly to mobile. Most of our interaction with the database itself is from the desktop client for now. So I'd say, for this discussion, you wouldn't tend to use that from mobile. But it is something we may look in the future of more types of Web and mobile interaction.
Stephen: 00:37:43.227 Understood. Another question. Is Teleport regularly security audited?
Steven: 00:37:50.707 It is. We run through security audit at least yearly. We do follow SOC 2, and that's part of something that is also regularly audited. And if you go to our site and look at our resources, those security audits are available so you can review what particular findings were there and how we addressed any findings were done. I think we not — so we are, as Stephen mentioned, at the outset, an open-source offering. And we think that's the best way to be for security. But we do also release those security findings that we have and how we address them, both for the product that people install on-prem or our cloud offering.
Stephen: 00:38:39.674 Understood. And I see someone asking where they can access a recording of this session. Just a reminder to everyone, this will be available on-demand. You can use the same exact URL. And we will send you a notification email. And it'll probably be up, I'd say, within 24 hours. So, Steven, we've gone through the questions. Before we conclude here today, is there anything else you'd like our viewers to know? What's the one thing you'd really like them to keep in mind moving forward from here?
Steven: 00:39:14.097 One of our big things is to keep doing often frequent releases. We are trying to release major functions at least every quarter. So as mentioned about particular database items, those are things that we're regularly releasing, and we think that's the best cadence to be on so that whether they're OSS or are license users, that people are frequently getting more value for the investment they've done with Teleport. And as I mentioned, that's why it's good to follow us on Twitter, our Teleport account there. Go to goteleport.com. And I mentioned the docs, there's a preview release that will give you what information is there. You can always go to our GitHub and see what is the latest information that's happening. And yeah. And also, we encourage you to join our Slack, which you can see that from our goteleport.com site, and interact with us, ask questions, just like the great questions we had today; how do I do this? What do we do there? And we have a great community of both people at Teleport as well as the community themselves that will answer your questions.
Conclusion
Stephen: 00:40:35.941 Fantastic. Once again, I'd like to thank our speaker today, Steven Martin, the Solutions Engineer Manager at Teleport. Again, if you would like to review this presentation or send it to a colleague, you can use the same exact URL that you used for today's live event. It will be archived and you'll receive an email notification within the next couple of days once that archive is posted. And just for participating in today's event, you could win this one $100 Amazon gift card. The winner will be announced on June 30th. We will reach out to you via email if you are the lucky viewer. Thank you, everyone, for joining us today. And we hope to see you again soon.
Join The Teleport Community
