No More Backdoors: Know Who Has Access to What, Right Now
No More Backdoors: Know Who Has Access to What, Right Now
With threat actors able to breach and pivot to sensitive resources in less than 62 minutes, the security of your infrastructure depends on the ability to quickly identify who has access to what. This webinar introduces infrastructure professionals to Teleport Policy, the most recent addition to the Teleport Access Platform. Teleport Policy provides a visually rich view of access relationships and the tools to quickly uncover and remediate long-standing privileges and shadow or risky access paths.
Key Takeaways:
- Learn how instant visibility can support defense in depth strategies and reduce the blast radius in the event of an incident.
- Learn how Policy, unified with Access and Identity, can give security professionals the ability to identify and remediate issues across all of your infrastructure, from one central location.
- See it live in action! The webinar will include a comprehensive deep-dive demonstration, showcasing real-world use cases for managing policy and safeguarding resources.
Who Should Watch:
Professionals chartered with hardening infrastructure security and access control across cloud and data center environments. This webinar is ideal for those in Infrastructure Security, Infrastructure Operations, Cloud Computing, Cloud Security, Engineering, DevOps, or DevSecOps roles.
Explore how you can implement defense in depth and protect your organization in today's identity-centered threat environment.
Key topics on No More Backdoors: Know Who Has Access to What, Right Now
- Teleport Policy unifies and controls access policies across all infrastructure.
- Knowing who has access to what infrastructure resources is a significant challenge, especially as the number of users, resources, and access configurations grows exponentially.
- Improper access configurations can lead to catastrophic data breaches, as evidenced by major incidents at companies like the U.S. Department of State, Verizon, Meta, Microsoft, and Uber.
- Teleport Policy's Access Graph feature provides a visual representation of access paths, making it easy to identify potential misconfigurations or excessive privileges.
- Access Graph allows users to view their own access, investigate specific user accounts, understand access roles, and trace access paths to critical resources.
- Integration with identity providers like Okta ensures that SAML users are accurately represented in the Access Graph.
- Access Graph can leverage Teleport's session recording and auditing capabilities to verify if users are actively using their granted access.
- Upcoming features like "Crown Jewels" will enable tagging and monitoring of particularly sensitive resources for any access changes.
- Access Graph includes a powerful SQL-based query language for filtering and analyzing access data based on various criteria.
- Teleport Policy will be offered as an additional subscription on top of the core Teleport platform, with pricing based on the number of resources being managed.
- Teleport Policy aims to provide a centralized, comprehensive view of access across multiple infrastructure platforms like AWS, GCP, Azure, and GitLab.
Expanding your knowledge on No More Backdoors: Know Who Has Access to What, Right Now
- SAML Identity Provider Access
Transcript
Introduction
Dave: Hey, everyone. Welcome to "No More Backdoors." Talking about Teleport Policy. We're just going to give a few minutes for folks to trickle in and then we'll get going.
[silence]
Xin: Hey, folks. Happy Friday. Thanks for joining us. We'll just give it another minute while folks get in here before we start.
[silence]
Xin: All right. Why don't we get started, guys? Happy Friday. Thanks for joining us today. Before we dive into today's topic, we'll take a couple of minutes to kind of introduce ourselves in the company. So today's webinar is “No More Backdoors: Know Who Has Access to What, Right Now”. And it's presented by Teleport. So we're from Teleport, where we built the Teleport Access Platform, which delivers on-demand, least privileged access to infrastructure on a foundation of cryptographic identity and zero trust. My name is Xin. I'm the VP of Product here at Teleport and my co-presenter — I'll let him introduce himself.
Dave: Yeah. Hi, I'm Dave Sudia. I'm a Senior Product Engineer here at Teleport.
Teleport Policy overview
Xin: All right. Thanks, Dave. So today, we'd like to actually introduce you to Teleport Policy, which is this block up here. It is the newest addition to our platform. At a very high level, Teleport Policy unifies and controls access policies across all of your infrastructure. So to put things into context, I'm going to stop sharing here and we'll do just a quick two-question poll. All right. So the first question here is — how many of you know exactly what infrastructure you personally have access to? And there's three choices. So please take a look at the poll. Should be on the left side of your tab. And yeah. Let's give it 30 seconds to see what everyone puts here.
[silence]
Xin: All right. Actually, a lot of people know, or at least given enough time, they can find out what they have access to. That's great. Let's actually go one layer deeper here and go to the second poll, which is — how many of you know — exact same question, but directed at your reports. So not necessarily yourself, but the folks that are reporting to you.
Dave: I'd say maybe also folks on your team if you're not someone with direct reports.
Xin: Yeah.
Dave: Also, when I think about the “given enough time,” I think about Cloudflare's postmortem that they posted a while ago where, yeah, they were able to figure it out, but it took them hundreds and hundreds of people hours. Given enough time has a lot of range.
Example: Complexity in managing access
Xin: All right. Cool. Well, it looks like just about half, maybe a little bit over half the folks, if given enough time, they can find out. And otherwise, there are very few people who are able to find out the next 10 minutes. And I think from our perspective, this is a really difficult but interesting kind of question to answer. And I'll kind of just go through a quick example to demonstrate why it's difficult or why it's complicated as a concept. So if we were to just take this example question. In a company, there are 10 employees and 50 resources, effectively. And each employee can either have access to resources or not. So this is a fairly simple, simplified version of a real-world scenario. You probably have more than 10 employees, you probably have more than 50 different infrastructure resources, and you probably have more states than just can gain access or not. There's probably states like, if you can request access, if you can get privileged access to things, etc. But we're going to go with this very simple sort of question to start. How many possible access configurations exist? So let's give it a minute. If you have any thoughts on this — if you have a thought on the answer for this, please drop it in chat. I'm curious what everyone thinks. And then we'll unveil kind of the math of it in about 30 seconds here.
[silence]
Xin: Yeah. All right, so let's unveil the answer here. So the answer is 2 to the 500. And I'll kind of explain why. So there are 10 employees and 50 different infrastructure resources. That means there are 10 x 50. So in this case, 500 different combinations of employees to resources. And for each of those combinations, there is essentially two states. You can either have access to resource or you cannot have access to resource. So from that perspective, you can see that this is a very quickly growing function. With just 10 employees and 50 resources, you kind of get this ridiculous number. It's essentially 3 with 150 zeros following it, which is just a wild number that is very difficult to imagine. Just to compare this to something that is a little less harder to imagine, but the atoms in the known universe, there is between 1078 and 1082. So this number, just from this very simplified version of the question, has many, many orders of magnitude — more combinations than the number of atoms in the universe. So you can understand why this becomes a very difficult question to answer, especially because in a lot of companies, these are not static, right? You have employees changing all the time. Their roles changing all the time. Therefore, the resources they have access to changing over time. So it's a very difficult question to track and track over time.
Data breaches from improperly configured access policies
Xin: All right, let's kind of take a look at why this matters in real life, right? So these are all the companies within the last 10 years that have had data breaches that have come from improperly configured access policies. And I'll walk through two examples, but there's tons more just in the last 10 years alone. So first example is in 2017, our Department of State, so the United States Department of State that handles our voter registration information, due to an improperly configured AWS S3 policy, essentially gave public access to the voter registration information for over 200 million Americans. So what they did is essentially they misconfigured AWS S3 policy and made the bucket publicly available. So anyone with that URL then can gain access to the information of 200 million Americans. The information included obviously names as well as address, Social Security number, etc.
Xin: So a lot of really privileged information was lost because it was simply misconfiguration in their policy. And they didn't know about this for a long time and they discovered in 2017. Kind of same situation, same year, happened to Verizon. They lost 14 million of their customers' records due to, once again, an improperly configured AWS policy. So you can imagine all of these companies, for example here, Meta, 540; Microsoft, 38 million, 2021; Uber, 57 million, this is including their customers as well as drivers in 2016. These are all very well-known hyperscale companies, and they couldn't even preemptively avoid this type of situation with improperly configured policies and improperly configured access. So it just goes to show it's a very difficult problem to solve. And if unsolved, it could lead to catastrophic outcomes with a lot of millions of people affected. So okay, so that's pretty much all I have. I will pass it off now to Dave to kind of talk about Teleport Policy, the product, and how it can help address this type of situation. Dave.
Live demo
Solving access management complexity with Teleport Policy and Access Graph
Dave: Thanks, Xin. If you stop sharing, I can pick it up. There we go. So yeah, so what is the solution to the problems that Xin brought up? Well, we think it's being able to quickly visualize and get a handle on your access. And that's what we're offering now with Teleport Policy and Access Graph. First, we're going to look at the default view of Access Graph. Quick note, if we count the resources I can see on my default view just coming into Teleport, it's 11. That number is going to come back up in a minute. We'll get there by going to Access Management and then Access Graph. Now, the default view of Access Graph is a great way to get a broad overview of your environment. Our default sorting method is by user, with users with the most standing privileges at the top. That way, we're naturally highlighting potential issues in your environment. There's a mix of AWS and Teleport resources in here. You can say an ARN at the top. That's a service count. We have this user `alice`. I can click on and — oh, `alice` is a Teleport user. The “arn” up here, well, is coming in from AWS. And I'm coming in from Teleport. Let's explore the access view for a single user. I'll right-click on my account and select View Access. Let me zoom in here because I know the view within the webinar casting thing is a little bit smaller. Now I can easily see what I have standing access to and what I can request access to. You can see that I have standing access through staging and dev access roles to all production resources. And I can request access to production resources through my requester role here. And we can see how that flows through, what I have standing access to, and again, that number “11” comes back up. This view also reflects changes from approved Access Requests.
Access Requests
Dave: For those of you who aren't familiar with Access Requests, let's see one in action and how it affects the view. I'm going to come in and make a new access request, and I'm going to request access to se-ag-prod, one of the production servers. And I want that immediately, and I just want it for an hour. And maybe I'll say that I need to do emergency diagnostics on a production server. And I'll submit that. Now, over in another window, I have a window open for someone who has an account that is available to approve my requests. We don't let you approve your own requests. I'm going to view that. I will approve my request, subject immediately. And we can see now it's approved. If I come back to Access Requests — I'm just going to revisit the overview for a second — you can see that my standing privileges has not actually gone up from 11. Again, if we look at the standard overview, what we want to give people access — or what we want to give you a sense of when you're looking at the big picture is, again, who's got standing privileges to lots of resources? And we don't want to highlight — if someone has temporary access, we don't want to highlight a problem where there isn't really a problem because someone has had temporary access to something. But we can see now that in the Access Graph view from my user, there's a new path that is coming from my approved access request straight out over to the production resource. So this updates pretty instantly, and it's really great for being able to instantly see what someone has access to at the moment, including temporary access.
Viewing access paths
Dave: So that's a view of one person's access. Useful for me as a developer to be able to visualize my access to the resources, or if I was on a responding security team, to be able to see the access of someone's account that I'm investigating. Maybe I suspect there's been a breach and I want to see what's going on. But from this view, I can flexibly jump to other views. By right-clicking on the `prod-access` role, I can go to that and jump immediately to seeing who has production access, who can review production Access Requests, and who can request it. One thing we've heard from users is that they've used Access Graph to quickly prove to auditors what the access paths are for a given resource. When the auditor asks you to show access for a specific bucket or server, you can show that it's locked off except after an approval process, and you can do it in seconds rather than having to go drag out things and make tables. And it's a really powerful tool for that purpose. Another thing we have coming very soon is a feature we're calling Crown Jewels, which will allow you to tag certain resources like this production server as ones that are extra important, maybe the most likely to be the target of a breach or the ones with the most sensitive data on them. We'll make it easier to jump right to these resources and provide notifications whenever access configurations to them change. So you have a live sense of, "Why did the permissions change on that server? That's not something that should have happened." Looking at the access path view for this production server, I'm a bit concerned because I can see, and I'll just zoom in to make it easier to see, down here that there are two users who have standing access to this production server and they get it through this role right here that's just called access. I'm going to look at that role some more and see that anyone who has standing access — if I click on that one, has access to all the servers.
Privileged access report
Dave: So I'm going to note for myself to bring up with my team that maybe we shouldn't have that role. We might want to revisit that one. But for these two users, let's revisit them: `admin-sam` and `danjohns`. Well, Sam is an admin, so it seems maybe reasonable that we have that access, but why does Dan have it? That sounds to me like a configure, or — and are they even using this access? Again, we don't want standing access to exist that people aren't actively using that isn't necessary. So I want to kind of investigate that. And here's where Access Graph gets really powerful. It's not just this feature in itself, but how it sits connected with the larger Teleport platform. I don't have to make a note to find answers to these questions. I can go answer them right now. First, I want to see if these users are accessing the server. I'm going to go to our Access Monitoring feature and look at the SSH sessions with weak security graph. I can see that there were five on June 7th. There were two within the last 24 hours. The way this graph shows is kind of if it's in the last 24 hours, what it shows is yesterday. There are a couple, which is concerning in the first place because these are SSH sessions with weak security. But I also know that this graph is going to get me pretty quick to an answer on if these folks are using this access. So I'm going to open up the query editor. We can see just looking at the information on this, what we consider to be weak security is using it with no MFA, not on a trusted device, concerning that that's happening with these. But I'm going to come into this query, and just to see who's using that production server, I'm going to just add server hostname to my query here and run it so I can see not just the sessions, but where the sessions are.
Query Editor and Session Recording
Dave: Okay. So `admin-sam` is using that access on se-ag-prod. He's, in fact, used it twice today. But Dan hasn't accessed it at all. Well, let's up the days. Let's go look at it for 30 days. So `admin-sam`, se-ag-prod, back in May. I'm just kind of coming down. Yeah, Dan is not using this at all. So that is clearly a misconfiguration. Dan should not have that access. Sam might, but I'm going to take it even a step further and I'm going to go see what Sam is doing with this access. So again, he accessed it twice today. I'm going to come in and play this session. And it's just standard package maintenance stuff using `apt` — `apt update`. And that runs, and okay, he's checking what's upgradable. This is stuff that probably we could automate somehow, right? These are not things that I want someone to have standing access to production servers without MFA and without a trusted device just to be able to go do. So that's another thing I'm going to bring up with my team on the security team. And maybe with that developers team or the sys admins team is to be like, "Is this necessary? Are there ways that we could — better ways that we could be doing this?" Now let's look at Access Graph and how it works beyond the Teleport platform via integrations. In this environment, we have our AWS integration activated. We also have an integration with Okta that's live, and we have ones with GCP, Azure, and GitLab coming soon.
Access management
Dave: Coming back to my overview, and just going to all access paths — sorry, I'm mis-clicking — `alice` stands out to me as a potentially concerning user account. They have access to 43 resources. And Bob is another AWS user. So 8, 16, 24, 32. Four or five times as many as another AWS user. Now, I've been a DevOps engineer responsible for many AWS accounts and their contents, and this is one of my favorite parts of Access Graph. We all know how hard it can get to really understand all the access patterns in an account with enough users and roles. As Xin was mentioning, it explodes. Being able to just quickly see someone with way too much access is so useful to just be like, "Why are these numbers so big?" So I'm going to look at this user `bob` and just kind of get a sense of what's different. So `bob` is coming in from AWS and `bob` is in a `group_bob`. It provides access to eight S3 buckets, but one of those buckets is overruled by this one, which is a denial policy. And so denial overrides access. So we can see that it actually has access to seven S3 buckets. Now, I don't know if we should have groups for every user, but at least this one seems pretty sane as far as access goes. Let's go back and look at `alice`. `alice` is in a group called s3-groups-all. This stands out to me as another group like that access group that we had on the Teleport side that we probably shouldn't have at all. But at the very least, `alice` probably shouldn't be in it. So yet another thing I'll bring up at our next — I might just raise it in Slack right now or at the very least at the next security team meeting.
Dave: Finally, let's look at some features for power users. You can imagine that once you have all your Teleport, AWS, GCP, Azure, and Okta resources in here and GitLab and whatever else we build, clicking through the graph is not always going to be that efficient except for those misconfigured accounts that stand out at the top. So first up is search. If I want to jump straight to a given resource, I can just put that name in here and jump directly to the access paths for that resource. And get a nice quick overview. I can see everything that goes there and how we get there, again, including temporary ones through Access Requests. But we also have the ability to query the graph using SQL. On the right, let me jump to — nope, not search, SQL. On the right up here, we have a little helpful box that brings up a bunch of suggested searches to get you going and kind of get you familiar with the data model. I might want to find the access paths for someone who has standing privileges above a certain account. So again, going to `alice`, show me `alice` and get everything — show me the access paths for everyone who has access to more than 20 things at a time. Or I might want to find all of my production servers in my AWS environment. So I'm just going to come in here and change the resource labels to `aws/env` is `prod` and run that query. And here I immediately jump. Here are all of my production resources in AWS and the access paths going to them. Now again, this is a demo environment, has a relatively small amount of things. In a real environment, this is where the SQL gets really powerful because you might not just want `aws/env: prod`, but ones in the EU region and that are for the cart service or something like that where you can really start to bring it down.
Dave: And I can just quickly shrink this down even more. Maybe I want to find the access paths for those where the identity is me. And I can do that and again see that I can request access to these things, but right now I have an access request path that allows me access to this specific server. So it's really powerful to be able to come in and query the graph and just jump straight to the information that you're looking for. That's a quick look at policy and Access Graph and how it fits into the Teleport platform and beyond. At this point, I'm going to just take it back and can come back in, and we're looking forward to seeing your questions in the Q&A. If you're interested in this, if this has gotten you excited, please reach out to us to schedule a conversation about Teleport Policy. To learn more about it, you can also go to goteleport.com/platform/policy.
Schedule a conversation about Teleport Policy
Xin: Yeah. As Dave said, we have actually a button at the top of your screen. This is Contact Sales. So if you go through that, you can reach out to schedule a conversation with us about Teleport Policy. We'll know that you're coming from this particular webinar. So we'll have a lot of context going to that conversation. If you want to revisit this at a later date, please go to the link here, goteleport.com/platform/policy. Exact same sort of situation. You can contact us and schedule a conversation, or you can even try out product for self-service trial format. So now let's see. It looks like we have a couple of questions here in chat. Dave, if you want to stop sharing —
Dave: And as we go into — yeah.
Xin: Go ahead.
Dave: I was just going to say, and as we go into Q&A, our wonderful backstage producer Lexi is going to push out just a quick survey about this webinar. We'd love your feedback so we can improve in the future.
Live Q&A
Xin: All right. So first question here. How will this work for SAML users? I've noticed that SAML users are cleared from the Teleport UI after some time. Assuming that remains the same, this will be missing a lot of information. That makes a lot of sense. A lot of our bigger customers and bigger organizations will have some sort of identity provider or SAML provider. And that is how a lot of these companies do authentication. From this perspective, so yes, first of all, to clarify the assumptions here, in the Teleport UI today, SAML users, once they log in, exist, I believe, for 30 minutes until they're cleared. And only what we call Teleport local users are the ones that show up in the user tab. Which is actually why many customers have asked about this, and we have documentation around this, why your monthly active user count may not actually match the user counts under the UI if you are using some sort of identity provider. For the purposes of Teleport Policy as a product, and Dave kind of talked a little bit about this from an integration standpoint, so we support right now AWS as well as Okta integration. And for identity providers like Okta that we support for Teleport Policy, we'll be able to actually import the users directly from Okta. So these are not the same as Okta users that are signing into Teleport. Which means in these cases for integrations, once again, integrations that we support — in this case, Okta — the SAML users will effectively permanently show up in the access policy UI. Dave, did you want to add on to that?
Dave: Yeah. I think just another clarification is that at the moment, Access Graph is a live view of your environment. It's on the roadmap to be able to take snapshots and go back and see historical access. So I think when we're talking about users disappearing, if a user is not in your environment and active, then it may not show up. But we're actively planning to bring you the ability to go back and say, "What about on June 5th? What was access like then?"
Xin: Yeah. All right. Next question. Is this a new feature of solution and a separate subscription? So Teleport Policy is a new product to the Teleport platform. And from a subscription perspective, so we've moved to a usage-based pricing model. And essentially, if you want to add Policy to your platform subscription, it will be an additional fee that's priced per resource. And again, you can contact our sales team to learn a little bit more about how we price particularly for Policy. But just know that it will be an additional charge on the number of resources that you're protecting. Dave, you want to handle this one?
Dave: Sure. Yeah. Is it possible to manage access to Azure Storage Accounts: (containers and fileshares)? But I said it quickly in the demo. So the integrations that are available today are AWS and Okta, but rapidly coming — this is what the team is working on right now — are Azure, GCP, and GitLab integrations. And I'm sure further integrations will come as people request them.
Xin: Cool. Thanks, Dave. And then next question here — does the free demo work with Teleport Cloud? Not clear on what this question is referring to. Zach, if you're in the chat, would you mind clarifying this question?
Dave: I mean, I think maybe it's if you start up a Teleport Cloud trial today or Teleport Enterprise trial today, is this baked into that trial period? I wonder.
Xin: Okay. Yeah. Assuming that's the question, yes. So you will gain access to Teleport. Any trial that you have with us, including the two-week self-service trial, you will get access to the entirety of the platform. So that would include Teleport Policy.
Dave: I can take this next one that's just come up, which is — what is the syntax of the query language that the policy product uses? So it's a SQL-based search language. The interesting thing about it — and as a senior product engineer, even people in tech ask me — what do you do? And I talk to users. I do research. But internally, I'm also often the first user of a lot of our new products. And I give a lot of feedback to the engineering teams. And one of the things I kind of surfaced to them is discoverability of the SQL syntax that we have for querying this. And one of the things the engineers brought back is, "Well, you're querying a graph, not tables." And so it's not exactly the same as you'd expect from being able to query across tables, and especially in terms of being able to bring up what fields are queryable within a given query. So having spent a couple weeks with it now, I think again, it's SQL-based and it gets really easy to use once you get familiar with it. But another thing we're actively working on is improving the discoverability of all the resources that you can query.
Xin: Cool. And then Zach, to clarify this question in chat here, we use Teleport Cloud. Can I demo this feature with it? Yes, you should be able to. For all of our new products, we take the approach of — we take a teaser approach, which effectively means that anything new that we ship, we will give everyone a way to use that feature up to a limited amount, right? Sometimes it's the number of queries. Sometimes it's the number of users. Sometimes, for example, for Access Requests, it's a number of Access Requests that you can make. So you should be able to access this. If you go to, as Dave showed in his demo, under the management tab, there should be a tab that's called Access Graph. And if you go there, you should be able to try out the product for yourself. Now, if you don't see it, it could be that you're on an older version of Teleport. And in that case, you can just reach out to our support or reach out to your account executive that you're working with and have a conversation about getting that updated so you can gain access to Teleport Policy. 14.3, I believe that's to — I believe this came out in 15. It's the initial release. So you're not going to be able to see it with a 14.3. So you'll have to reach out to your contact, or. Yeah.
Dave: But all the more reason to do so and get up to the latest version.
Xin: Yeah. Yeah. Which by the way, we are actually about to release v16, I believe tomorrow. So v14 in a couple months will actually be end of life. So even more reason to have that conversation now so you can get up to date and get all the new features and functionalities.
Dave: Including auto-update features that we've drastically improved. Last question that came in was, you mentioned something about Crown Jewels. Can you explain what that is again? Yeah. So we think it's really important for you to know when access changes. So again, kind of going beyond this instant view into chronological awareness of your access and access patterns. If you have that S3 bucket the Department of State had that has all the voter registration information in it, that to us would be something that we'd consider a crown jewel, right? And what we want you to be able to do is mark those to get instant updates when access changes so that if suddenly someone misconfigures the terraform and pushes it and that bucket goes public, you'd want to know about that. The other reason we're having you tag resources — as opposed to doing that for everything — is that you probably don't need to know if access changes on the temporary dev server overnight, right? And so we feel this could easily turn into just notification span. And obviously the worst thing in security is over notification and notification fatigue, right? And so we want you to be able to pick specifically these very important resources that you definitely want notifications on and be able to get that live information whenever something dangerous happens.
Xin: Right. Again, to put this into real-life scenario, right, let's take that Department of State situation. So one, you should be able to see that it's a public bucket that everyone has access to at the very top of your Access Graph, right? So just starting off, you should be able to see that and fix it and address the issue. And then with Crown Jewels that's coming, what you should be able to do then is if anything changes — again, it's a very sensitive database, right, with very sensitive information. If anything changes with regards to the ability to access the S3 bucket, that you will get a notification. So you can make sure that it's just constantly being configured correctly and there are no accidental changes that expose very important information. I think that's all the questions we had. Any other last minute questions from the audience? All right. Well, in that case, just to flash this up once again, if you have any interest in exploring this further, please reach out to us to schedule a conversation about Teleport Policy. Again, you can do that via the Contact Sales link at the top of this event. Or you can, at a later time, go to goteleport.com/platform/policy to do that. Thank you so much for joining us today for this webinar. And please, you can see kind of flashing on your screen right now. If you have any interest, you can register for our next webinar to get the latest information from the Teleport team. All right. Thank you so much, guys, and have a good rest of your Friday and weekend.
Dave: Thanks, everyone.
Join The Teleport Community
