Eliminating Shadow Access: The Hidden Dangers of SSH and API Keys

Eliminating Shadow Access: The Hidden Dangers of SSH and API Keys

Static credentials like SSH keys and API keys play a prominent role in managing modern infrastructure, automating tasks, and enabling software integration, but they also pose significant risks. These keys are often difficult to track, escape traditional monitoring tools, and can be easily exploited if stolen, leading to breaches, shadow access, and compliance issues.

This webinar uncovers the hidden vulnerabilities of static keys, including shadow access—a scenario where unauthorized or outdated keys provide invisible backdoor access to critical systems—and offers actionable strategies to mitigate risks and strengthen your security posture.

We uncover how static keys often escape the purview of traditional monitoring tools, leading to vulnerabilities such as credential sprawl, excessive privileges, and compliance violations. You'll gain insights into real-world breach examples where compromised SSH and API keys caused severe organizational damage, demonstrating the urgent need for modernized access controls.

We also explore actionable strategies to mitigate these risks, such as implementing short-lived certificates, enforcing least-privilege access, and adopting centralized access strategies. You’ll walk away with practical knowledge to improve your organization’s security posture and eliminate shadow access risks.

Key topics on Eliminating Shadow Access: The Hidden Dangers of SSH and API Keys

• Shadow access refers to unauthorized and unmonitored infrastructure access that bypasses established security controls, including hard-coded credentials, orphaned accounts, shared credentials, and backdoor access paths.
• Shadow access has led to significant security breaches at major companies and poses regulatory compliance risks.
• Engineers often create shadow access when they need immediate system access to meet deadlines but face bureaucratic delays.
• Common examples of shadow access include storing credentials in code repositories, embedding them in CI/CD pipelines, creating over-privileged temporary accounts, and using unmonitored SSH jump servers.
• To eliminate shadow access, organizations should replace static credentials with dynamic, identity-based authentication; enforce least privilege by providing just-in-time access; implement centralized visibility across all infrastructure; and adopt Zero Trust principles.
• Teleport helps address these challenges by using certificate-based cryptographic identities with built-in expiration, enabling Just-in-time Access Requests, enforcing MFA for sensitive resources, providing comprehensive audit trails, and supporting native tools like SSH and database clients to maintain engineer productivity while enhancing security.
• The webinar also includes a live demo of Teleport as well as a summary of key Teleport benefits.

Transcript - Eliminating Shadow Access: The Hidden Dangers of SSH and API Keys

Introduction

Eddie: Hello, everyone. My name is Eddie Glenn. I'm the Director of Product Marketing at Teleport. We're just going to wait a few minutes before we get started because we still have a few people still joining today's webinar.

[silence]

Eddie: Okay. Let's go ahead and get started. First of all, thank you for joining. I'm really excited to be here today with everyone. And before I get started, I just have a few housekeeping things I wanted to go through. First thing is — please note the chat box on the right side of your screen. So feel free to ask questions, post comments, engage with us there. We have a couple of people working in that chat window, so they might be able to answer your questions online. If you do have questions for us, please enter those into the Q&A and we'll get to them at the end, time permitting. And then there is a docs tab to the right-hand side of your screen, and that contains some resources that you can download. And then within about 24 hours, we will send everyone the recording of this webinar. So don't worry about taking notes during today.

Eddie: So with that, let's get started. As I said, I'm Eddie Glenn, Director of Product Marketing here at Teleport. Just a little bit about my background. I started off as a software engineer developing real-time embedded operating systems and avionics systems. And then from that, I got into cybersecurity. That's where I've been for quite a while. I'm really excited to be joined by Steven Martin. Steven, I'm going to let you introduce yourself before we get started.

Steven: Sure, yeah. Hi, I'm Steven Martin. I've been with Teleport for a few years now. I'm a Solution Engineer specialist. Prior to that, I've also worked with a large number of Fortune 100 government implementations. So a lot of what we talk about today of shadow access — that was my life. This database, this automation, making sure people don't have too much access. So yeah, just been in and around a lot of the cloud and on-prem systems that most of us do day-to-day.

Webinar agenda

Eddie: Great. Okay. Thanks, Steven. So with that, let's just kind of quickly go through what I'm planning for us to cover today. So there might be a few of you that don't completely understand shadow access, and maybe you do understand it. I know as an engineer, I love shadow access because it's convenient. It allows me to do the job that I need to do. But from the security perspective, I know that it can be quite dangerous. So we'll talk a little bit about what shadow access is, give some examples of it. We'll explain why a key part of shadow access static credentials are a security risk. We'll talk about some best practices that everyone can follow without impacting an engineer's day-to-day activities too much. And then at that point, I'm going to turn things over to Steven, and he's going to show you how Teleport can help eliminate shadow access without impacting engineering productivity.

A real-life example of how shadow access occurs

Eddie: So with that, I thought I'd start off with a story. So last week, Teleport held its annual sales kickoff. And it was in the Westin Hotel in Dallas, Texas. And Steven was there, I was there along with the rest of our sales teams and solutions engineers. And as you probably know, a lot of these kinds of annual sales meetings — they try to do a team activity. So our team activity this past week was to divide up into teams and create a commercial that promotes Teleport and what Teleport does and the kinds of problems that Teleport helps our customers solve. So obviously it was very low budget. We basically were forced to use our own phones and our own laptops and do all the editing ourselves. Even worse than the editing was we had to do our own acting and scriptwriting and all of that.

Eddie: So I was the one who was doing most of the editing and I had all the files on my laptop. And during cocktail hour, it was kind of strange. I'm not quite sure, Steve, why you wanted to start editing during happy hour. But Steve needed access to my laptop and it was locked up in the safe in my hotel room. So I gave him the code, wrote it down on a sticky note, and he got into my hotel room, and opened up the safe deposit box, pulled out the laptop, and got what he needed. So that was great. I think according to Steve, on the way back, he threw it away, so it was safe. But the next day, we had more people that needed access to that laptop, and we had a Slack channel going, and they asked Steve for the code to the safe deposit box. And I was really kind of surprised by this, Steve, but you posted it in the Slack channel. So now we had the entire team that had access to my safe deposit box, along with not just my laptop, but all the other things that I was there protecting. I had $10,000 of cash that I usually carry with me.

Eddie: But anyway, so now we not only had Steve that had access to that safe deposit box, but five other people on our team had access to that safe deposit box. And then one of the things that I discovered the hard way afterwards is that Steve, instead of tearing up that sticky note, just tossed it in the trash can, and some random person came along and they found that sticky note, and now we had a stranger that had access to my safe deposit box. A lot of the story is tongue in cheek, but I just wanted to set the stage for when we're talking about shadow access — this is the kind of behavior that we're talking about. So maybe it's not necessarily a sticky note — or actually, many times it is a sticky note, but it's not access to a laptop in a hotel room safe. But anyway, I thought that would be kind of a fun way to get started on the topic.

What is shadow access?

Eddie: So, what is shadow access? Simply put, it's unauthorized and unmonitored access that bypasses established security controls. So an example would be, I have my password and I give it to someone else, and they can access my account. Or maybe it's an SSH key, and we'll talk a lot about SSH keys today. But basically, it's a security method where if someone else has access to that control, then they can bypass the security that an organization has put into place. What causes shadow access? Why do people like shadow access? And what are some of the techniques that you can use to bypass security controls? You can hard-code credentials, and we'll see some examples of that in just a few minutes. You can have orphaned accounts. So I created a cloud account to my AWS server that's only meant to be temporary. I forget that I have it. I leave it there and now there's an orphan account. There could be backdoor access paths where I SSH into a computer, a server, and then from there, I SSH into another server that might — that my story might sound familiar because it happened about a decade ago with a very famous CIA operative. And then we talked about shared credentials.

Eddie: And then why is it so prevalent, and why is this such a big problem for companies? And it's really how our infrastructure has changed. Organizations are seeing rapid infrastructure growth. We're going from single servers in a server room to cloud environments, multi-cloud deployments, just very complex, very spread out. And then the frequency of software updates has grown tremendously. So all this is putting pressure on engineers, and they need access to the resources to get their day-to-day jobs done. So this, I think, is a lot of why we're seeing a spread of shadow access.

Examples of shadow access used by engineering

Eddie: So let's talk about some examples, and we'll just go into a bit more detail of what are some things that engineers do that helps them get their job done, but from a security standpoint, it's not necessarily a best practice. So, storing static credentials in a code repository. Now, in a few minutes, I'll talk about some very public breaches that occurred because someone did this. And I hope by now that this doesn't happen, but it still happens. But we see passwords stored in code repositories, maybe it's a password to a database, and very frequently an admin password to a database. Maybe it's an SSH key or an ATI token, but they're hard-coded and then stored in a repository. And if that repository is public, then now you have a very serious breach on your head.

Eddie: This is the one that's probably most frequent, and that is hard-coded credentials stored in CI/CD pipeline automation scripts. Very often, it feels like it's a necessity because that's the only way to get your CI/CD automation working is to have that credential stored in that script. But again, very dangerous because now it's hard-coded in, and anyone that has access to the script has access. And there was a pretty big breach a few years ago. I think it was around 2020 that involved a very well-known company where they had credentials stored in their CI/CD automation scripts.

Eddie: And then this is also very common. If I am under a deadline to finish my work and then it takes me two days to get access to a critical server that I need only for maybe 10 minutes to get a package uploaded. I'm going to work around that because I just can't afford to wait two hours, two days, or whatever the time is to get access. So that will make me want to do things that, intellectually, I know it's not the best thing to do, but because I have a job to do, I will sometimes break that rule. And then this was an example I just mentioned, over-privileged orphan accounts. I'm debugging something. I need to be able to log in as admin. I create an account for that. I forget that I've created it. I leave the company, and then that account's still there. So that's danger.

Eddie: So that's a lot of ways shadow access is [inaudible], but it's not all of them. And I'm going to just give a few more examples. And then there are even more that we just don't have time to cover today. Unmonitored SSH jump servers. So I mentioned this as an example of an SSH into one server. That server has an SSH key pair that connects to another and another and another. And then I've been able to jump from server to server without any security controls. And then the whole multi-cloud infrastructure perspective, modern architectures has led to a lot of shadow access because it's so complex. And there are so many visibility gaps that security groups or security engineers may have access and visibility into one cloud environment but not another cloud environment. And this helps enable shadow access that tends to be very common. And then shared credentials. It's that whole sticky note thing that I just talked about with Steve and the code to my safe deposit box, but shared credentials and shared accounts across an engineering organization. Again, no one's necessarily being malicious with shadow access. It's just the way that engineers have found to fix the immediate problem that they have, and that is that they need access to a particular critical infrastructure resource.

Audience poll: challenges of limiting shadow access

Eddie: So, let's do a poll because I want this to be interactive. And I'm going to pause sharing for just a second, and Lexi is going to throw up a poll for everyone. So the question is — what is the most challenging aspect with limiting shadow access for your organization? You can select any of these or as many as you'd like.

Steven: I've definitely had a couple here.

[silence]

Eddie: So, Steven, do you have any commentary on what you're seeing here? Does it surprise you?

Steven: No, I think often nowadays, we are not just working either in one environment anymore. So it's harder to say it's a single approach to credentials. So often at that complex infrastructure question and others where, OK, I'm accessing one system this way, but I'm accessing another database this way. So it really can get complex being able to track that and then saying, well, I want to make sure to only issue these credentials. Then later, I got to go back and update them as they expire or change. So that can make it a real challenge not to over-generate credentials for your infrastructure.

Eddie: Right. Right. So I noticed that we have a few more options, but on the screen that I'm looking at, I can't see what the results are. I'm really interested in if anyone's selected, "We haven't developed a consistent process to limit shadow access." It's scrolled off of my screen.

Steven: That's tied with, "Our engineers require it." So those are our two leaders right now.

Eddie: Right. Right. So, I mean, I think this is — I'm assuming that we have lots of engineers on this webinar today, and from your past experience, my past experience, that when we have deadlines, we do what we have to do to get the deadline met. And that's one of the things that excites me about what we're going to talk about later — is that Teleport can help provide that security that's needed by the organization without impacting the productivity of engineers. So with that, I'm going to get back to finishing up my talk so we can get into your demo here.

Four dangers of shadow access

Eddie: I wanted to bring up three common or three very well-publicized breaches that involved shadow access. There have been others. In fact, it was hard for me to select just three, but they have very serious consequences. I kind of alluded to the one before Ed Snowden with — I think I said the CIA, but it was NSA. 10 years ago now, but very serious that involved shadow access. But more recently, very well-known, very respectable brands have had issues where they've had SSH credentials especially stored in repos that were breached. The repo was made public and it became an issue because the SSH credentials were in that. But all these led to very serious consequences for their companies. And that's why even though we all love shadow access, we have to keep in mind that this can bring serious consequences to our companies that we work for. And therefore, there needs to be motivation by all of us that are doing engineering to try to avoid using shadow access.

Eddie: So very well-known companies, and there are many more than just these three. So what are some of the dangers? So what? We have shadow access. Obviously, they lead to breaches. But if you're in a regulated industry that has significant data protection protocols in place, healthcare, financial services, shadow access can lead to, worst case, unauthorized data access and changing of data. I mean, can you imagine going and being able to change someone's health record to change a test result from positive to negative or vice versa? So, unauthorized data access and changing that data is a danger of shadow access.

Eddie: We've talked about breaches, reputational liability risk. Liability is becoming a bigger issue to consider because companies are being sued. Executives are being held accountable for not doing more to protect their data. And shadow access as a leading culprit of some of these breaches will have an impact on the organization. Introduction of malignant code — we saw this with SolarWinds. The hackers were able to insert malicious code, and that was pushed out to all of their customers. And then there are compliance issues. More and more regulatory standards are trying to address some of these bad practices by requiring certain criteria around data access, and shadow access behaviors will bypass that and leave you out of compliance.

Audience poll: approaches to limiting shadow access

Eddie: Okay. So let's move over to the next poll number here. The next poll question. So how does your organization limit shadow access? So I'm assuming there are maybe some limitations, maybe not, but I'm really curious to see what the results are here.

[silence]

Eddie: We'll go to a few more minutes. Maybe not minutes, but maybe another minute.

Steven: Yeah. I appreciate the audit answer. I've unfortunately known of some cases where, yes, we do audits, but the audits are done by the engineers themselves. So it's a case of like, okay, we're policing ourselves well. So it's just human nature that it's difficult to track it. But yeah, it's a complicated thing to make sure you don't have access. And then also a case of going through an audit is never fun, whoever's doing it.

Four steps to eliminate shadow access

Eddie: Great. Okay. Let's move on. Thank you for that. Interesting responses. So there are four steps that we can take that help eliminate shadow access, not just limit it, but we can actually eliminate shadow access. First one, it's obvious, but probably easier to say than actually do unless you're using Teleport — is to eliminate the use of static credentials. So what if you didn't have to manage SSH keys and store them in code? Passwords, API tokens, etc., just eliminate that. That will go a long way to stopping some of those methods of shadow access. Enforce least privilege. Again, I know engineers are really concerned about being able to access what they need when they need it. But if there's a way for them to get that access without having to wait a couple of days to get it, then that will go a long way as well to eliminate shadow access.

Eddie: Centralized visibility. We talked about the example with multi-cloud, but it's just not multi-cloud. It's server to server, database to database, one software application to another software application. If an organization had visibility into all of those infrastructure resources, and they can see who has access to what, what paths of access they have, that can go a long way in eliminating shadow access. And then obviously implement Zero Trust. So these are all great things to do. They help towards eliminating shadow access. But this is going to lead us into how Teleport can help you do these things. And especially, again, this is around how can we do that without impacting your productivity.

How Teleport helps eliminate shadow access

Eddie: So I know, intentionally, I did not talk about us as a company at the start, because I wanted to talk about the problem at hand first. But Teleport, we make computing trustworthy. And we do this by modernizing identity, access, and policy for infrastructure. And it's designed for engineers specifically. And it's designed for improving engineering productivity, as well as improving the resiliency of the infrastructure that you guys use. And our approach for eliminating shadow risk is built on layers. So we have the first layer that is based on identity. We aren't using static credentials for this. We're using identity that's based off of cryptographic identity. This applies to not only people, but also to machines and software workloads, endpoints, and AI agents.

Eddie: We connect these through session-level encryption, through Zero Trust networking. We provide short-lived privileges that's based off of least privileged on-demand access only. And then we have the ability to provide a single source of truth for everyone around the govern and audit capabilities. So that's at a very high level, and Steven's going to go into more details of how this actually works in real practice. And with that, I'm going to turn things over to you, Steven, to talk about what you're going to demo today.

Steven: Yeah. Thanks, Eddie. Yeah. Let's jump into it. I am just looking for the share button. Sorry about that.

Teleport Demo

Steven: So here we've landed on the web UI of Teleport, and this gives me access to a number of infrastructure items. Now I've already authenticated and been issued a cryptographic identity. You can see that gives me access to a certain number of resources. That includes things like cloud access to an AWS cloud environment, also SSH servers, databases, as well as Kubernetes. And it's very simple in Teleport to simply jump right into a resource. This is an AWS EC2 instance. You can see it's just like any other type of normal interaction. Now, as I'm accessing that, Teleport has used my issued cryptographic identity. The SSH service running on that machine will verify it, so that way we have an end-to-end confirmation of my identity. Also, because it's certificate, it's time-based.

Steven: So part of what Eddie talked about earlier in terms of stashed SSH credentials and things of that nature, those are even more dangerous because they're not limited. Often what we call static keys — they're issued, but there's no expiration. And a key part of Teleport is that all of my credentials expire in some amount of time. That can be in 20 minutes, or that could be in eight hours. But there is an expiration. So that way, even if someone's able to get those credentials in some way, they're going to expire and not be useful later on.

Steven: Now, while I'm in this environment, I'm able to access it. Teleport is monitoring that access. So besides just the fact that I can get access, the system can see where people are accessing. You can see I'm across three different servers right now. That also gives the opportunity if there was a concern about what access I am to remove it. Now, once I end the session, then that session can be reviewed to make sure that was there any particular concern about what occurred there, what the user did. So that's always available to you and other auditors.

Steven: And you can see it plays like a video. It is the actual text and other cases, so you can select it, and review it, and copy and paste out. You, of course, have the option to hide or show what is or isn't available. Now, part of this is also that, well, it's good to have the identity, I've authenticated. But what if someone takes my laptop? What if someone goes off with whatever I've already logged in with? Well, there's also additional confirmations you can do. Those are often called MFA or second factor. So in this case, I've tagged this particular machine. You can see I've tagged as a customer account. So I want to make sure that when someone's going in, there's additional cryptographic confirmation. So in this case, I have to use my Touch ID. I could also use a YubiKey or other ways. So that's one method of making sure that, well, you may have the credentials, but you still couldn't get in unless you had someone's second factor. And that allows Teleport, again, to cryptographically verify what's getting in. And that's something you typically — the default SSH access on most servers do not have that. So this gives you additional protections in order to do that.

Steven: Now, in terms of what other access I can have, so you saw my initial access. Now there are also other systems I can access. So there's other prod machines. You notice they don't have the connect because I can request them. So these are requestable items. And often, one of the problems people can run into why they go for shadow access is, "Well, I don't know what I have. I just need to have everything and always have it available and be able to do everything I can from the root access." Versus, "Well, if we display it to people, then that helps them to know, well, what could you access? How could you actually request it and get into and make it more of a seamless process as opposed to something where they have to constantly inquire what can I access? What's the IP of that?" So all of these resources are available to the user, both in this form as well as in their desktop, so they can either get immediate access to it if that's their day-to-day machines or request it and then go in.

Steven: So in this case, I'm going to ask for an app, as well as a server. Now I can ask for this immediately or also ask for a later date and time. Sometimes you're not working on that immediate day, right? So you may want to ask that for another day. And I'll say this is an authorized job. And then this request can automatically process and allow me in once it's processed. It goes into the pending state. Now, once that's processed, let's just go look back at some of the other things we can access. There's things like databases. You can do this from your workstation, go directly into the browser. I'm going to access the DVD rental database, which some of you may remember, or you're more familiar with Blu-rays. But that's a case where you can go directly into a database, get the query. Now, again, Teleport is validating your cryptographic as you connect. So there's no saved passwords. I don't have to click on something, copy and paste a password from Vault. It's all done in a passwordless method.

Steven: Now, in terms of the request, we can see here it's automatically processed. Again, I requested a particular app and an SSH server. I can assume the role and those resources are available to me. So you can see how quickly I did it. It's not something where I have to go off and manually ask someone. It's not something where I have a particular different SSH key I use for now. It's all done seamlessly through this interaction. And I'm in a prod environment. It will enforce that I'm allowed to access it for this time. Everything I'm doing here is being recorded. But my day-to-day — it wasn't really that different for me, but it's simply I don't by default have that.

Steven: And one of the dangers of shadow access is there's breaches. There's also the issue of what if I do something I didn't intend to? What if I connected to production directly? There's a lot of — Eddie, I think you've seen the horror stories on Reddit or something of how did you take down production? And a lot of times it was inappropriate access at the time. Oh, I didn't realize it was connected to a production database. I didn't realize I was on a production server and I ran some update and that took down production. So often, most of us don't need day-to-day, very high access. And so this is a case of being able to appropriately have it when you need it, but not have it all the time.

Steven: And just to give a little — we've been going over some of the forms of how I access, how I can do Just-in-time. To give you an idea of the architecture, here's a quick diagram in terms of a user connecting. As we mentioned, a user is issued a cryptographic identity that forms their certificate. They communicate through Teleport. There's a single binary that's used to provide the access. And then we split those up into services. So we have the Teleport Control Plane that has the Proxy. You saw me going through that in terms of the web UI. We then have our services that are allowing things like the Teleport SSH Service, the Teleport Database Service. Those are both things you saw me access in terms of the SSH. Now these dial back into the proxy. So in this case, I didn't need a port open in terms of that. That also enables that I don't have to go into a VPN. I don't have to open that, provide some network access.

Steven: Again, shadow access isn't always just the credentials. It can also be, well, I have network access to everything. And in those cases, well, what if a malware got in and they could try to attack various systems? It's not always just about getting into systems. It's about disrupting systems. So you can do other things to [inaudible] that time. But as I mentioned before, each of these services are verifying your credentials as you go along. So while I'm in here, once it connects to the SSH, it verifies my certificate using its public key. The same for the database. It verifies me before I connect to the database. And the database, like an RDS form, we're using IAM credentials. If it's connecting to a self-hosted Postgres, the Postgres can trust Teleport certificate, or we can use its certificate. So again, all very seamless, passwordless, verified using standard certificate credentials.

Steven: Now, as it's going on, everything's being connected to the Auth Service, recorded what's happening in the audit, as well as we also have chances of locking out if we have any concerns. So in this case, we've talked about the resources, how they connect, how you can do Just-in-time Access to your more sensitive resources, how you do additional safety checks before a person connects to a resource. Now let's also take a look at more of the shadow access part in terms of what are some concerning access resources that we might see.

Steven: So this is a production server. I can take a look at that server. This is under our Teleport Identity security. It lets me know what servers are available, what are the flows that a person can get through to get here. In this case, one of the things I'm concerned about is, well, this is an EC2 server. Now, in terms of that shadow access we talked about, what are some private keys that can get here? So I know Teleport can get here. That's why it's here. But also I'm concerned about — do we have any leftover private keys that might be there. Yep. We definitely have some. So we have this case of two. Now I was expecting my own. I didn't realize Bob was here. So we actually have two that can come in, and that's concerning. So that means we don't just have a single key that we might be expecting, but often when you come into these kind of servers — and this is where we're talking about shadow access — where Bob, who I told Bob not to do this, and we'll lock out Bob in a bit over this kind of thing, but he's taken on himself to add in keys. He's done shadow access, but we've now discovered it. We'll try not to yell at Bob too much, but it's a case of you don't always know what's in these systems.

Steven: And something Teleport can do as part of its integrations is to scan for these keys. And there's two things it can do. One is it scans for the key. Like in my case, this will link back to my own machine. So my machine is registered in Teleport as a trusted device. So I do expect that and it's going to validate back to who it is. Now this key is not connected. So this key, I assume it's Bob, but it also could be something nefarious. So this is a case of me being able to detect that and then being able to investigate further, remove it from this server to make sure it's not available.

Steven: Now, in terms of when we have something that might be nefarious like that, as I mentioned, we can have users like Bob. And just before the call, I logged in here with the user. And of course, your authentication goes just before. So in this case, you can see in Bob's browser, he's logged in. Now what if we have a conversation with Bob and says, "Oh, I'm not logged in. I'm not in there." And we found out maybe Bob, again, doing some things, being a little too loose on his security, allowed someone in. And that's where, based on our detection, we can go to our identity and add a lock for that user. So in this case, I can identify Bob, proceed to lock. Now I can lock Bob's user forever. Or in this case, we'll just do an hour to make sure [inaudible] review. And we can see that locked in real-time. So in this case, Bob received this message. It's locked. He'll not be able to get in for that hour. And we, of course, could make it permanent if we have concerns about that.

Steven: Now, you also have the capability of not just locking Bob, you also could have locked those servers involved to make sure that you're not — if you're concerned about a particular access, Eddie mentioned about accessing or changing particular data. So that's something where you can lock that particular resource and then individuals would no longer be able to — anyone wouldn't be able to access it through Teleport. So that gives you that additional protection to make sure that you're not allowed to do anything more with those particular resources.

Steven: Now, in terms of everything I've been doing here, and one thing is you've seen me in the web UI so far, you can, of course, also do this from command line. And these are the same servers I had in the web UI. I can even use tools like SSH or pgAdmin or psql to directly interact with any of these servers. So that makes it more capable. One of the concerns you run into when you have something that doesn't work with native tools is that, again, people are more likely to use shadow access. So that's part of why Teleport — we support being able to integrate native tools like SSH, like psql, all the tools you're used to accessing regularly as part of a typical infrastructure. And that way, people, again, don't try to get around it to use something else because, oh, it takes four steps to get it there. I can't use my favorite database GUI. I can't use PuTTY or things like that. No, that does work with Teleport. It makes it more seamless for people to take advantage of that. And it's very typical understood steps.

Steven: Now, this is what the user can do. We also have our Machine ID and automation. So everything I'm doing here in terms of SSH, Database Access, we also have an automation item you can do. So the same type of identity can be issued and used. Again, for best practice, you'd want to focus in that identity to do — "Oh, it's working with a particular set of databases. It's working with a particular set of servers." But all those can be done both directly on, say, a Linux machine, or if you're doing GitHub actions, that allows you to specify that. The same thing you saw me do with Bob, if I had a concern, "Oh, there's something dangerous here." We can lock down our identity. We can lock down those roles to make sure no one can use them. And then in real-time, whatever's happening will stop immediately, as opposed to, "Oh, I think I stopped that identity. Did we copy that one? Did we do something else?" No, you can track this down and prevent further access that you don't feel is appropriate. All right, Eddie. Well, I think we hit most of the items there.

Eddie: Thanks, Steve. Before you stop sharing, we had a number of questions that came in about the demo, and I'm thinking maybe it would make sense for us to address a few of those. It was about things that you were showing.

Steven: Yeah. So how does Teleport slow down the SSH throughput? Teleport is designed to be as good or better in terms of SSH access. We're using native SSH protocol. So you typically wouldn't see a major difference there. It also can integrate directly with OpenSSH in addition to the Teleport service. So again, you really shouldn't see much of a difference.

Steven: I see another here. Does the client machine need to have a Teleport agent we can definitely use? I say in certain cases, you would install a service, things like database or others. As I mentioned with SSH, it can also directly interact there. In cases like AWS and others, we use OIDC integration directly with it. So it depends on the resource there. In a lot of cases, if you don't want to have a service, you don't need to.

Steven: Integrate Teleport with Okta? Yes. So one of the things we support — OIDC and SAML — in terms of auth as well as GitHub. Now, in addition with Okta, we also have an extra integration that's available where we can sync up the set of users, allow you to manage apps and groups, as well as when you saw me navigating, that's available.

Steven: And we saw, is [inaudible] available? That is in V16. That is part of our Teleport Identity security feature. So yes, that's been available from V16 and on. I see a question for [inaudible] nodes. Okay. I think it was about expiration. So the Teleport certificate is trusted on the server on here or in the OpenSSH. So this certificate will expire. So this certificate has an end time. The certificate here does have expiration. It's a longer expiration. It's not necessarily that day, but that will verify the certificate the user is. So these are aware of the user certificate and they verify it when that comes through. Now, this certificate will expire. And past that, it's useless. You'd have to get another certificate to go through. And then this will go on and confirm it. The Teleport Certificate Authority can also rotate and handle changes like that. So if you ever need to rotate that certificate, that's part of the infrastructure.

Steven: Can you access Windows endpoints? Yes. We do have Windows Desktop support that currently is through the web UI and through the browser. You can do RDP interaction. I see a question here. Do access get granted [inaudible] identity? So there is a — when you form the cryptographic identity in Teleport, then we're using the metadata from the SSO to form that identity. So that does things like what roles you have. Are there any additional traits you might have, like logins, customer environments, groups — all of that can be used to form your cryptographic identity and what you're allowed to do. We also have the concept of Access Lists. So if you want to maintain a separate set of lists based on that input, that's available. So again, that forms a total cryptographic identity. Often, the IDPs themselves are fairly coarse-grained in terms of the groups you're in, and then Teleport will form the total cryptographic identity of your user in order with what they have access to.

Steven: Question about crowdsource feature in shadow access. Not quite sure if that applies or not. Yeah. I'm not sure if that was meant for another — or CrowdStrike or another option, but I don't know that that would apply in this case. I do see another question from the same individual, a shadow access in the same light as backdoor entries and web [inaudible]. Yeah. I mean, you could consider it backdoor or cases where you might have particular hard-coded username or passwords that allow people to come in. Often you might have a root user you're not aware of and someone put in there and no one's tracking it. So yeah, definitely those cases, those cause concern. Now, a lot of times, like in databases, you can configure, well, which credentials can you use from where? You could say, well, from all of these, you have to use certificate-based. So we would definitely say using Teleport, you turn that on, where coming from the outside, you enable just being able to use certificate-based to come in.

The Teleport differentiators

Eddie: Thanks, Steven. That was a great demo. And thanks, everyone. Those were awesome questions. I'm glad we addressed them at the demo. Sorry, I have an Alexa here that is very sensitive. Sorry about that, everyone. Okay. So we're kind of in the last few minutes of the webinar. Appreciate everyone staying and again being engaged and asking great questions. I just wanted to conclude on some things that make our platform unique in the industry. First one, it's purpose-built for modern infrastructure. So it has the cloud-native support, Kubernetes support. It's built for engineers by engineers. It's not clunky like some other solutions might be. It eliminates the need for static credentials. It's built on a foundation of cryptographic identities, trusted identities. And then the other thing that's really unique is that it provides a central view, a unified view for identities across people, machines, and software workloads with built-in Zero Trust support, identity governance, and identity security.

Teleport platform benefits

Eddie: And today we've talked primarily about shadow access, but Teleport helps with so many other things. We've talked about how it's really focused on improving engineering productivity. And Steven showed us a lot of examples of how it's going to make life easier for engineers, but we also support that resiliency aspect of modern infrastructure in helping to support aspects around security. So we have customers that use us for eliminating access silos, which can be a real problem from a productivity standpoint. We help streamlining access requests. We saw how easy it was with Steven asking for access to a production server and getting that almost immediately. We saw an example where someone was doing something wrong and we were able to lock them out. So that helps really — is very useful with offboarding. But it can be just as useful with onboarding someone — that you can give a new employee access to all the infrastructure resources they need.

Eddie: We have a lot of customers that use us to help eliminate the need for VPNs and bastions and that's a very common reason why there is shadow access. We modernize PAM, we accelerate compliance, and we know that in today's climate there are a lot of regulations that can really decrease engineering productivity because you have to do things for compliance, like producing security audit reports and things like that. And I think we're almost out of time, so I want to get here to the final points.

Key takeaways

Eddie: Key takeaways. So these are three things I want you to remember after you leave the webinar today. Shadow access is very common. It's very commonly used, but it's also an extremely common reason for why there are breaches and compromises. So it's an important problem that we all need to address. And ways to address it is to eliminate the use of static credentials, stop stuffing them into code repos, stop putting them into script automation, enforce least privilege. There's no reason that someone needs access to your production server 24/7. Give it to them only when they need it for the task they're doing. Implement Zero Trust across all of your infrastructure, and then provide that centralized visibility. For those that are responsible for the security and the resiliency aspects of your infrastructure, make sure they have visibility across all the different resources. And finally, Teleport can help you achieve these things. Again, with no impact on engineering productivity. And in fact, what we've seen with our customers is that it improves our productivity.

Eddie: So with that, we've answered a lot of questions and I see that we're actually over time. So I'm going to thank everyone for attending today. We have a survey at the end. We really appreciate you taking just a minute of your time to answer the survey questions because it allows us to provide better content for you in the future. Again, thank you, Steven, for doing the demo, and thank you everyone for attending today's webinar.

Steven: Thanks, everybody.