Scaling Privileged Access for Modern Infrastructure: Real-World Insights
Scaling Privileged Access for Modern Infrastructure: Real-World Insights
Implementing and scaling privileged access in modern computing environments generates new challenges for security and engineering productivity. Modern computing architectures are ephemeral, elastic, on-demand, and complex. This webinar delves into the challenges faced by platform engineering and infrastructure teams when enabling secure access in these environments.
In this session, John Capps, Vice President of Infrastructure at VIDA, a leading digital identity company operating in Indonesia, shares his team's transformative journey in securing privileged access. John outlines the initial use cases that focused on fortifying and streamlining his engineering team's access, along with subsequent expansions to cater to broader business functions and customer requirements.
Joining John is Ev Kontsevoy, the co-founder and CEO of Teleport, who provides valuable insights into key strategies for enhancing security. Ev illuminates the process of eliminating secrets, consolidating identities, implementing zero trust principles, and unifying policy frameworks. These measures serve to bolster security measures and effectively mitigate the attack surfaces that are frequently targeted by threat actors today.
Key topics on Scaling Privileged Access for Modern Infrastructure Real World Insights
- Modern infrastructure is highly complex, diverse, and ephemeral, making traditional access control methods inadequate.
- Teleport consolidates identities and policies across all resources into a unified access control layer.
- Teleport provides productivity and time-to-market benefits by simplifying access for engineers, adopting a secretless approach, and enabling scalable security with non- linear team growth.
- Teleport eliminates the need for credentials that can be stolen, improving security posture by using cryptographic identities tied to hardware and biometrics.
- Automated reporting and compliance features in Teleport significantly reduce audit overhead.
- Implementing Teleport can be rapid, even for small teams, by leveraging infrastructure-as-code tools like Terraform.
- Business value extends beyond technical benefits — Teleport enables self-service access across organizations, improving productivity and reducing VPN reliance.
- Teleport Policy allows visualizing and reporting on the current access state, a first step towards centralized policy management across fragmented infrastructure.
- The Teleport release cycle and the company’s Support team are some of the additional reasons VIIDA adopted Teleport.
Expanding your knowledge on Scaling Privileged Access for Modern Infrastructure Real World Insights
- [Teleport Access]
- [Teleport Policy]
- [Teleport Application Access]
- [Teleport Kubernetes Access Guide]
- [SAML Identity Provider Access]
Get Started with Teleport
- [Teleport Trial]
- [Teleport Labs]
- [Participate in our discussions]
Transcript - Scaling Privileged Access for Modern Infrastructure Real World Insights
Diana: All right. Thank you for being here today for our webinar on Scaling Privileged Access to Infrastructure. I am Diana Jovin, the VP of Marketing at Teleport, and your host for today. Today, joining us, we have John Capps, who is the VP of Infrastructure at VIDA, and Ev Kontsevoy who's the co-founder and CEO of Teleport. So before we start, I want to point out on the right hand of the screen, we have a chat and Q&A tab. I invite you all to let us know where you're joining from, and also, if there are any top-of-mind questions that you're hoping that we will address during the session. At the end, we'll have a short two-question survey, and we would also very much appreciate it if you could let us know what you thought of the content today. We'll be covering five topics, about six minutes each. So the fireside chat part of the webinar will take about half an hour, and we'll close with 10 minutes of Q&A at the end. And so without further ado, let's turn to introductions. So, John, tell us about VIDA and your role at VIDA, and what's going on there.
Guest speaker's background
John: Sure, thanks, Diana. Yeah, my name is John Capps. I'm the VP of Infrastructure at VIDA. And we're an identity assurance provider based in Indonesia, primarily in Indonesia. And what we do for the Indonesian market is we do identity verification for primarily financial services institutes, but also we have customers like Grab, where we're doing driver verification. And essentially, we offer an assurance service where we can verify to our customers, which are our B2B customers, that their end users are who they say they are. So that's predicated on our relationship with the Indonesian government, specifically the model where they provide us a database of identities, and we do liveness verification and modeling around that, and then we come back from the government database and give them a yes or no.
How Teleport was founded
Diana: Okay. Great. Thank you, John. And, Ev, tell us about Teleport and why you founded the company.
Ev: Sure. So Teleport is a secure infrastructure access platform. So we all know that internet lives in data centers and internet needs to be told what to do. So there are engineers all over the world who develop applications that are basically instructions for internet to do wonderful things. But engineers are not physically in data centers. So they need remote access to all of those computing resources and that infrastructure, and that is what Teleport provides. And the way we started the company was interesting because at the time, Teleport founders, we were working at companies like Rackspace or Google and others, basically hyperscalers, and companies that operate servers by hundreds of thousands or even millions. And we noticed that hyperscalers — these more sophisticated companies. The way that they protect their infrastructure is much different from the mainstream technology, and we decided that we need to take this difference and simplify it quite a bit and make it available to everybody. And maybe it also makes sense for me to expand on what it actually means to access — what is infrastructure? Because it's such a generic word now. So by computing infrastructure that needs remote access, I mean data centers, cloud accounts — like your AWS account, your GCP account, your Azure account, whatever — but also everything that lives inside, that includes things like databases, Kubernetes clusters, Linux and Windows servers, internal web applications, observability tools, CI/CD, essentially everything. Our view is that your entire infrastructure and everything inside — it needs to feel like one giant computer. And you need very, very simple remote access for it.
Diana: Okay. Great. And, John, I think, in an earlier conversation, you said that you started with a concern about how you securely access the Indonesian national database and then expand it to other resources. What do you mean by infrastructure in terms of the things that you're trying to secure?
What infrastructure security meant for VIDA
John: Yeah. So my background is in a lot of various types of infrastructure, and I'll define infrastructure in my experience as any collection of hardware and software that can be used to platform a product. So this is anything that evolves into a platform where I can launch my applications for my customers or applications internally for the network, data centers, hardware servers, but like you said, AWS accounts or GCP accounts where you can have that platform as a service. So any collection of those types of resources that evolve into a platform where you can build your product — that's my definition of infrastructure. At my current business, it is hybrid. So we run AWS pretty extensively, and then we run on-prem as well due to the nature of operating in Indonesia. So part of our product is a PSrE certificate authority, public certificate authority, where we issue digital certificates against every identity that we verify. That way those verifications and that verification can be legally enforceable when they're signing onto a bank account or they're signing a document or things like that. So for me, infrastructure is all of the above. I have leased hardware, and I have owned hardware, and I have licensed software, and I have open-source software, and I have AWS, and we try to use a common set of tooling for these things, but it can be quite challenging in such a diverse infrastructure. And my company is not massive, and I have a very small team, so how do I — scaling my team's functionality and capability without having to onboard a linear number of employees as the company grows. So when we're looking at tools like Teleport, that's where I'm — we're trying to solve a security problem, but we're also trying to solve a scaling problem. And we can go into more depth about that later, but when I'm looking at these tools, there has to be both — it has to be both a business value-add as well as a functional requirement checkbox for us.
Why modernize infrastructure access
Diana: Okay. Terrific. So let's move on to our first topic, which is Modernizing Infrastructure Access — why it's needed. So let's start with you, Ev. So can you talk about how securing privileged access to modern infrastructure is different from approaches that people have taken in traditional IT and how Teleport solves this problem? And then afterwards, we'll talk to John about how this then affected VIDA, right, in your implementation there.
Ev: Yeah, absolutely. And it's kind of interesting that John already answered, I would say, probably 30% of your question in his earlier response. It's like, what is different about infrastructure today versus 10 years ago, 20 years ago? Why is that modernization of access such a big deal right now in 2024? What changed? And there are basically two things that changed. Thing no.1, what John was alluding to, is explosion of complexity. Back, for example, when Facebook got started, right, they built their first iteration of that product on LAMP stack. We all remember that. All you needed to build the web applications back then was Linux, Apache, PHP, and MySQL. So if you had a bunch of servers, all you need to do is just kind of secure your Windows with SSH — sorry, secure your Linux with SSH, secure your MySQL, and you would be more or less fine. So the problem of remote access was well contained with just those four components. But now, even if you look at small companies or mid-sized companies, you will see that — and you will examine their tech stack that they run their applications on — it's incredibly complex.
The diverse nature of modern infrastructure
Ev: AWS alone has hundreds of different products inside, and they all have remote access. But then you have Linux and Windows servers and you have containers and you have Kubernetes, and you have Docker Registry, and CI/CD, MongoDB, MySQL, and several types of databases. Then you have a bunch of observability tools, internal web, every single layer. I can go on and on and on. Quite literally companies have hundreds of technology layers, different flavors of computing resources. And every single one of them listens in a network socket, has its own kind of authentication, has its own authorization, has its own role-based access control, has its own audit. Not everything speaks HTTPS. So you cannot just put SSO in front of every single protocol. SSO is not going to help you get into like a Linux box via SSH, for example. So that is one problem — that modern infrastructure is incredibly diverse, just like John said.
The ephemeral nature of modern infrastructure
Ev: And the second problem is that — well, it's not a problem, it's actually a wonderful thing — that it's ephemeral. We are now used to create and destroy computing resources by hundreds and thousands, just using code. So this old approach of configuring access manually by clicking on buttons and dragging people into different groups — it just doesn't really scale anymore. You need your access to be defined as code as well. And that is essentially Teleport's approach to how we solve this problem. First, we consolidate identity across all of these different identity silos into one place. So from Teleport's perspective, you shouldn't have a separate identity for humans, separate identity for workloads, separate identity for laptops, separate identity for all different types of resources.
Ev: Teleport combines identities of everyone in one place. Then on top of this, it allows us to define policy in one place and allows us to enforce deep zero trust connectivity across all these different components, effectively creating a unified access control for your entire infrastructure. And this access control becomes part of your tech stack. So it's also controlled with code. It also grows and shrinks as your infrastructure grows and shrinks. So it simplifies dramatically managing access, and it implements a paradigm that I called scalable security. This is something also that John was alluding to. You don't want to linearly grow the size of your security or security engineering team as your company grows. You want your security to be more kind of scalable. So you want this to look more like logarithmic. Your infrastructure continues to grow, but it's growing faster than the overhead that you are investing or spending on managing access to it. So that's our approach to consolidate everything in a single kind of access control layer.
What led to the search for scaling privileged access
Diana: Okay. Thank you, Ev. So, John, given the issues that you're trying to solve, why did you start looking for something to help you with scaling privileged access? And what were some of the key things that you were trying to address?
John: Yeah. So I joined VIDA about a year and a half ago, and the company, right as I was joining, had just experienced a large time of our large period of inorganic growth. So company was fairly young, three and a half, four years old, operating in Indonesia, looking for product market fit, building up a customer base, and all of a sudden industry or the — excuse me, the policy regulation changes in Indonesia and all the competitors are closed. So all the competitors no longer meet the compliance. They can't pass the audits. The administrative information is closing down certificate authorities for noncompliance. And we go from one or two customers to 100, 150 customers in six months. How do you build processes quickly to meet the business needs? And you don't. You keep things alive as well as you can. And so when I come on, we're still kind of a bit a little wild west. We've got SSH keys and I've got different types of servers. And then Red Hat kills the upstream for CentOS, or how do we pivot operating systems? And there's a lot going on all at once. And I have a team of seven people, so it's not a large team of people, and how do I bring on tools? And how do I bring on processes where I can abstract away that complexity?
John: And we have VPNs and two data centers and site-to-site VPN with AWS because [inaudible] over the internet according to Kominfo regulation. Kominfo is our regulator for certificate authorities in Indonesia. And we come into our annual audit, and they're looking at privileged access escalation. All of a sudden, we're one of the — we're one of the larger players in the field for certificate authorities in Indonesia, and they're very strict on us, which is the way they should be, and we don't have privileged access escalation. I have a team of people that have access to the VPN, and they can access the infrastructure from there. And we have some network segmentation, but it's not that well controlled. And so the auditors are like, do we have privileged access escalation or privileged access management, and I'm like, "Great, privileged access management." We can buy something like that, but then there's no functional component. There's not an easily adoptable functional component to a lot of privileged access management systems.
John: So we're looking at Teleport, one, because we don't want to have to adjust our complex networking. So we have AWS and multiple regions in AWS and multiple accounts and multiple segments on our on-premise. And Teleport for us is abstracting away all of that. So I'm looking at a product where I have two-person control of root credentials, I have auditability, a great ecosystem of tooling that allows me to build everything as code. So we deploy all of Teleport with Terraform and all the configuration with Terraform. That gives me the ability to close down SSH. I don't have to write SSH vulnerabilities now. My systems don't even have to listen on SSH right now, except for maybe on local networks if we have some break glass policy where Teleport goes down or the VPN goes down or something goes down, right? So I have systems that aren't listening on anything except for maybe the application ports, and maybe they're only listening — this is all reverse-tunnel based, so I don't need to worry about ingress to my Teleport cluster. Teleport doesn't have to talk to anybody.
John: So it simplified a lot of network management for us, as well as checking off those security checkboxes for Kominfo. And privilege escalation is really easy. There's a lot of [inaudible] options. I have a small team, so we can have either two-people moderated sessions, or we can have access requests with auditing. So my team's small. So I'm not using two people to do a single task. So now I have to raise an access request for privileged access, and I can both see who's granting it, who's reviewing it, and what they're doing during that time. And that makes my team move faster because now they don't have to worry about the complexity of building a new system and integrating the keys and doing baselining and things like that for golden images. I can just Terraform out a new node with Teleport, and it's available, and it's tied into my policy-driven access management plan. So now I can set everything up as policy. I have mappings from my single sign-on. I can build new groups and map those to different policies and create policies dynamically. It makes things a lot more scalable for me, and that's where it opened up into — now I have business value, right?
John: So Teleport isn't just about accessing servers. That's great. I can SSH to a server. I can access a server via an SSH style pattern. But I also have database access now — native database access. I have MySQL client on my laptop. I use Teleport. It gives me a certificate. We trust that certificate. I get a native database connection. Kubernetes is the same way, right, Kube-control. I can use Lens now if I want, which is a product that lets me give a lot of observability into Kubernetes. But the thing for me is applications. I set up web proxies now, and I can basically run my intranet over Teleport. So no VPN access. So I don't have to worry about network security. I can see who's logging in. I can see who's accessing what web UIs. We have single sign-on versus those web UIs. So we have a lot of options here now for realizing business value, where I can bring in my engineering and engineering developer enablement for non-production environments. I can bring in my operations team. I can bring in my marketing team if they want. Our back office doesn't need access to the VPN anymore.
John: So for me, it was, Teleport solves a problem — that I might have an immediate problem — but I can also justify this to my business with proper business value. We can realize now the benefits of enablement across multiple parts of the organization. So that's kind of the idea behind Teleport for me — is a lot of the reducing complexity and implementation, but also actual business value. Because I have a very business-oriented organization versus a technology-oriented organization, which there's no right or wrong way to do it. Every business has its own different culture. But mine is business. If it's not adding value to the business, it's not likely to get a lot of budget or attention or priority, and that can be quite challenging for me. So the more that I can have business value with tools that I adopt, the more I'm going to get buy-in across the organization.
The self-service security pattern
Diana: So this idea that you started with your engineering team and then expanded out to other business groups within the organization is really interesting. And I think you called it a self-service security pattern. Can you give an example of how you did that for one of your groups and how those groups realize business value?
John: Sure. I have an excellent example because it was a really early adoption use case for us. I have a team of people that are not part of my business line that need to be able to access and do manual validations of identities, right, against the government database. Tons of restrictions against how we access the government database, right? So we have a very specific MPLS line network connection to the government. We have very specific patterns and networks that we can access to that system, and that cannot be publicly accessible. And even behind the VPN, it'd be quite challenging. So originally, we had a Windows host that was approved, and people would log into the VPN, and they get on the remote desktop, and they would open the — it was a mess, right? Couldn't track it. We couldn't see what they were doing. Couldn't see who was logging in very easily. There wasn't a lot of traceability. So we've set up basically a web proxy, got it approved by the government, and all the hardening done. And now I can get my users access to Teleport, and I can see who's logging in and when. I can control their access. And they can access this web portal now via the web proxy directly through Teleport. And because it's a reverse tunnel, there's no network connection.
John: If you're accessing Teleport, you're not accessing the network, which is the key differentiator for us. Being on the VPN, of course, I can do a zero trust network, but it is so much more complex than a zero trust policy. Because a policy is — I can use language to define who I'm trusting and then implicitly deny everybody else. Whereas a network — zero trust networking — can be a lot more challenging to implement, especially across a hyperconverged network with AWS. So that was the initial use case for us in different parts of the business. Our operations team now has 60 people where it was — they were on the VPN and it's a one-hour timeout and 2FA, and now we have this single sign-on with Teleport and they can access. And I can see everything that they're doing, and we can audit that as necessary. So whenever we have the Kominfo, whenever we have our auditors come in, we can basically just click through and be like, "Here's the audit trail." And we can basically attribute everything we need to back to the policy.
Benefits of implementing secure privileged access
Diana: Fantastic. And, Ev, you work with a lot of customers directly. What kind of other benefits are people looking for when they implement secure privileged access?
Ev: That's an interesting question because I was just recently asking. I decided to ask exact same question every time I meet a customer and see how their answers would be different. And I would ask them like — what are the top three benefits you're getting out of the solution? And what's interesting was that security was rarely mentioned as number one. And it's not because they don't care about security. Probably it's just not very exciting topic for most people. Instead they would tell me that it's a productivity benefit and faster time-to-market benefit, because a lot of — what John was saying, is like, "Hey, I need to do a lot with a team of seven and my company continues to grow." And I'm not going to have the opportunity for the size of my team to linearly kind of follow the size of the company. Everyone expects technology to scale nonlinearly to deliver exponential benefits. So that is what most Teleport users would tell me — is that Teleport allows us to be on a kind of fast path.
Ev: So if you're an engineer and you need to access, I don't know, Kubernetes cluster on your AWS environment, and then you need to access maybe some Linux boxes in your own data center, and then there are some internal applications that you're using for whatever purposes, oftentimes, all of these resources are on different networks. So you need to kind of juggle your different VPN credentials, you need to — sometimes switching from staging to production is also convoluted. So all of that leads to human errors where people accidentally — and probably most engineers have a story in their career — how they accidentally deleted the table in the production database because of that mess, because of human errors. So that is most likely — not most likely, that's the most common benefit, is — and that's probably why we called Teleport “Teleport”, because it feels like all of these computing resources are just getting teleported into your laptop. So the things you're supposed to get access to, you get access to instantly. So that is a beautiful thing.
Ev: And another benefit too is obviously from a security perspective, because we probably all know that cybersecurity industry is on — we're on a losing streak. So the frequency of breaches and data exfiltration accidents and the damage caused by cyberattacks and ransomware attacks is actually on the rise. So there is something broken in our industry. So what is that? And the answer is that attackers, over time — they realize that attacking vulnerable software, attacking vulnerabilities in software, is actually quite expensive. But instead attacking humans and attacking human behavior is actually much easier. So humans make mistakes all the time. [laughter] We're extremely unreliable. So we click on links we're not supposed to click. We open attachments we're not supposed to open. We could lose our laptop somewhere like in the restaurants. There are all kinds of mistakes that humans make, and that's what attackers do. They try to trick humans into making these mistakes.
Ev: This is where all the phishing attacks and deepfake attacks, all forms of identity attacks — they all try to trick you into making a mistake. And once you do make a mistake, what happens next is that attackers steal your credentials. They're looking for private keys in your laptop. They're looking for those config files for different cloud providers. They are going after your browser cookies, API keys, all kinds of credentials that they could find. That is the goal of an identity attack. And those attacks, they represent 75% of all attacks. So that is the reason why the industry is — that we have been losing to the dark forces. So how do you prevent humans from making mistakes? You can't. You could invest all you can into training. So that will probably lower probability of humans making mistakes. Let's just say you can lower probability of someone making a mistake by a factor of two. But what happens — going back to this kind of function of scale that John was referring to — you grow to X, you hire twice as many people, and the probability of someone making mistake goes up to where it was before you invested all this time in training.
Ev: So therefore we cannot prevent humans from doing stupid things, but we could design your infrastructure access to be immune to human behavior, and the way you do that, and that's what Teleport provides, is that Teleport doesn't use any forms of credentials. We don't rely on passwords. We don't rely on browser cookies. Teleport uses what we call a cryptographic identity under the hood, and that's true for humans, it's true for machines, for hardware. And the way it works is that — so you configure Teleport to use combination of a trusted platform module. So essentially, it's a secure chip on the motherboard of your laptop. And you combine that with the biometric information of a human and with a password, and those three things collectively — that uniquely defines that particular human being. And then Teleport issues a certificate that is tied to those characteristics. And additionally, the certificate is pinned to the IP address of a client.
Ev: So now you have an identity that is not represented by some kind of piece of information that could be stolen, uploaded, downloaded, cloned, shared with another person. So using this approach that we sometimes called secretless approach, because the actual secret is stored in a physical world — it's a microchip on your laptop and your finger. So that allows your infrastructure access to be kind of immune to how you behave because these secrets cannot be stolen. And a third benefit that everyone would always mention is the ease of achieving compliance. So Teleport has a component then called — it's a new product we launched last year called Teleport Identity. So that is a component that allows you to automatically generate reports that you could show to your auditors that say, "Hey, these people never have access to infrastructure unless this accident happens." And then we have this access review process, and then access is automatically revoked. And Teleport allows you to document that all of this is in place and all of this is enforced. So therefore, just the overhead of passing compliance audit is very, very low. So that's the third benefit that everyone would mention.
What implementing secure privileged access requires
Diana: Okay. Thank you, Ev. So let's now turn to what it takes to implement this. So I think in the traditional privileged access management market, sometimes these projects are known for being long and complicated because you're trying to identify all the privileged users in your organization. In this case, you already know all of your users are privileged. It's more about how you're securing their access into infrastructure. So, John, what was involved in deploying Teleport for these purposes? What was the timeframe? What resources did you need? How long did it take to stand up?
John: Yeah. So we were quite rapid adopters, and I would recommend [laughter] ultimately taking a more intentful approach. So we were in the middle of an audit and basically PAM had come up as a point that we needed to make sure we were finishing. And so we had been looking at privileged access management and been looking at Teleport already, and basically, it was, "This meets our requirements. We've done some pilots," and then we ran with it. We have quite a robust Kubernetes skill set on my team. And so we basically took out-of-the-box Helm charts with some good opinionation and overrode a couple of our own options. So we can only access our Teleport over the VPN at the moment. We're still evaluating public access. So there's some complexity around putting things directly on the internet. So we're running over the Teleport and making sure that our converged infrastructure in AWS and our on-prem is robust enough to support this.
John: But basically it was infrastructure team first. So how do we define access? And what does privileged access management look like? So how do we have a pattern where people can request access? Who's going to be allowed to review those? We quickly put together infrastructure and engineering, basically, our two major components here. So infrastructure team can access privileged access. We are processing tickets basically based on privileged access management. That way engineering can approve those requests. So we now have basically partnered up with the engineering team to be able to provide that function in the event that we do need to move quickly, right? As it evolves, we bring on other types of non-privileged access. So we're talking about the web UIs or the applications in Teleport. And those don't have a differentiation between privileged and non-privileged. That's just a matter of access control. So who can access what applications? Who can access what databases? How do we map users on systems to users in Teleport? And how can we grant access?
John: So if you want to access root, obviously, that's privileged access management. But what do our non-root users have access to on each of our servers? So making sure that we have all of that defined as we're going into the implementation was pretty important. But we took it, basically — initially, it was just SSH. How do we SSH into systems? And there's some questions here. We can address those very shortly around that. But my team is largely doing a lot of work around logging into a system and making changes. Now, as that changes, recently, we've integrated our Teleport implementation into another product produced by PagerDuty called Rundeck, where now we have self-service. I have a machine ID using this TPM registration from a server that we have. That machine ID is automatically renewed. We're able to access or control access around that machine ID, but abstract that away from our self-service tool. So now I can write automated tasks that have access to my infrastructure at a policy-driven level, and we can write automated tasks against those, so self-service against — so if I want someone to be able to do a very specific action against two or three databases, for example, delete a user, reset a password for our product, right, now I write that up, automate it. I run that on my machine, my machine ID. That whole thing is abstracted from the self-service tool, and now I'm even more not needing to log in the systems. So we're moving away from that SSH access into more of a self-service access, but it's the same patterns that Teleport offers us with SSH, and with applications, and with other things. Now it's just more machines and less people. So same patterns. And that's one thing that really appealed to us, is the ability for us to adjust our access patterns and still be able to use Teleport to provide value.
Introducing Teleport Policy
Diana: Terrific. So policy has come up a few times. So let's touch on our last topic before we go to Q&A. Ev, Teleport Policy is a product that Teleport recently introduced. Do you want to briefly describe what that does?
Ev: Sure. So before I dive into Teleport Policy offering, let me just make an observation that I would make. I would argue that policy management for modern infrastructure is currently not a solved problem. What I mean by this is the following — so the normal state today of affairs in any infrastructure is like heavy fragmentation of identities. So organizations normally use one system to manage identities of their employees. It could be like Okta or Active Directory. So that thing holds the kind of — so it's your source of truth, like, who works in your organization? What do they do? And who they report to and which groups they belong to. But then your servers, your infrastructure, identity of those machines are stored in a completely different system. Then you have your client devices like laptops and smartphones. So identities of those devices stored in a different system. And if you have identity in this fragmented state, you cannot enforce policy in one place. That's really a big, big problem in the industry.
Ev: So your policy ends up being fragmented. So you have your IAM roles and AWS over there, then you have some other policy for your hardware in another place, and that drives this extremely high operational overhead of kind of securing infrastructure. So several attempts have been made by different companies to solve this problem, to try to consolidate access in one place — I'm sorry, consolidate policy definition. Because ultimately, don't we all want to have just a hypothetical edit box in which you can type, "Hey, developers must never touch production data"? And then click button says, "Enforce," and it just magically happens. But it's just not possible because if you have some sensitive data in a database, there are so many different paths that the potential bad apple developer can take to steal this data. They could connect to that database directly running SQL commands. They could SSH into that box bypassing database policy, or they could use AWS API to do EBS volume dump bypassing SSH security, bypassing database security.
Ev: They could use Kubernetes API to get there. They could go through a CI/CD pipeline because CI/CD usually has credentials for databases. There are many different ways how a creative engineer can get access to this data. And you have multiple sources of policy that control all of those different pockets. And again, all of this is because of fragmentation of identity. So we spent previous few years of company life trying to consolidate identity in one place, and now since we succeeded, so now we're starting to roll out a centralized implementation of policies. So the end state that we're optimizing for is that you would define in Teleport Policy that you want to enforce and Teleport will take the definition and it will enforce it across all these different protocols that we support — SSA, HRDP, AWS APIs, everything. So then whatever policy you set will be true regardless of which access path you take. So that's the end state. That's where we're going to. But because everyone wants this and everyone wants this badly, we realized that we could be releasing these capabilities gradually.
Ev: So what Teleport policy currently allows you to do — well, we're still working on policy definition, but at least we could look at your infrastructure and tell you what policies you actually currently have, and what is working. So you can ask Teleport questions like, "Hey, show me every single person who can SSH into this box right now," or "Show me list of all the people who can access this resource on AWS." So at least it could generate your reports and show you visually the access graph, who can access to what, because you can also ask the reverse questions. You can pick a person. For example, I could pick John and say, "Hey, Teleport, tell me what John has access to," or "Show me things that John theoretically could have access to if he requests access." So currently Teleport Policy is this product that you could have this conversation with. You can ask it questions about what can happen, what's possible, and it will give you answers. And those answers are kind of guaranteed to be true because Teleport is deeply, deeply integrated with all of these different workloads.
How Teleport Policy could solve problems
Diana: And so, John, you've had a preview of policy. How could you see that potentially applying to some of the problems that you're trying to solve in your organization?
John: For me, it's purely administrative. So obviously, being able to go and see it is amazing, but the real functional, the real business value for me is when we're going through an audit, or we're going through forensic analysis of an incident or something like that, I can go and just see it. I can generate an impact report. Basically, an impact report — I can see what was exposed and see what the blast radius is, things like that. When I'm going through an audit, I can basically generate a snapshot of our user access matrix. These users have this access or this potential access, and this is our escalation policy. So for me, it's administrative, beyond a personal fun interest of being able to see it graphically painted out in a way that's easily digestible. It's an attractive auditing and security tool for us. That's all.
Q&A time
Diana: Okay. We have a number of questions here. So let's move to Q&A. Let's see. So there are a bunch of questions here about SSH. So, John, do you want to talk about SSH access to things like servers and front ends?
John: I'll be really quick because it is SSH native — basically access pattern is the same. So the mental model is the same, but it's not really SSH. So what it is — is Teleport is not initiating connections. You essentially have reverse tunnels coming from our server. So I have server. I have Teleport. I have a stateful connection from the server to Teleport, and whenever I request access to that system, that's Teleport asking that server, "Hey, can I have access?" And then we have a stateful tunnel there, right? So basically the Teleport SSH client behaves like native. You can actually set the Teleport SSH client up to behave natively with aliases in Linux. So if I'm running a Mac and I have a terminal going, I can set up aliases where I can do X forwarding, port forwarding. I can set up everything else. I can set up everything in Teleport on SSH the way that you would normally use Teleport, or the way you would normally use SSH on a regular system. So all your native tooling is there.
John: Actually, if you're willing to go that next step, you can onboard systems because Teleport's agent-based, so every server is running the agent. You could actually have non-agent-based configuration for each of your nodes. It's an open SSH configuration. And the basis of the technology — and, Ev, if you want to go to more depth, you can, is trust change. So it's a TLS. We issue a certificate to individual users. We issue a certificate to individual machines. Each of them are identified by the certificate, and the metadata for that certificate identifies the access and who they are, and the tagging, and the metadata for each of those objects. And that's that trust chain. So all the trust chains are originated by Teleport and certificate authority, either built in or bring your own, and then you have access to users based on — again, we're going back to policies. So I have now a centralized non-root user or non-privileged user, and then I have a root, obviously, that I'm using for privileged access management. And so when I want to log in as my non-root user, my users have access to that based on whatever roles they have in my IDP, so. But it's all reverse tunnels. So SSH is native. So the mental model is SSH, but the actual connection technology is not SSH.
Ev: So I'd like to add to this a couple of things. So first of all, everything John described is absolutely correct, but Teleport gives you a lot of optionality, because there are no two absolutely identical infrastructures out there. So there are organizations who want kind of deep integration of Teleport capabilities. For example, reverse tunnels that John keeps referring to, that allows you to implement extremely secure system where all of your servers, they don't listen on the network anymore at all. So in that mode, it's the best implementation of Zero Trust possible. You could open up firewalls. So you could basically have your entire infrastructure running on public IPs and it will be secure. So for that, you need agents, you need Teleport agents on these boxes. But some organizations say, "Hey, we don't want that. We don't want to deploy agent in every box." So in that case, you could deploy Teleport in a proxy mode, and this way, it's working much, much closer to how OpenSSH works.
Ev: But the big underlying difference is that Teleport supports not just SSH — it supports pretty much every protocol you can think of. And the second one is that, again, it's a secretless system that works. It's a chain of trust that ends with certificate authority and Teleport protects CA using hardware. So chips like TPM, HSM, or virtual HSM. So those are used to hide, just completely remove private keys from being accessible by humans or applications. So this way, the entire access is always ephemeral. You issue the certificate to go in a complete specific task. Once the task is complete, your certificate is kind of no longer needed. So you could retire it or it could expire automatically. So that is one big difference. There are two different ways to kind of deploy Teleport in kind of agent mode or agentless mode, depending on how much of this kind of network security you want.
Diana: [crosstalk] —
John: And I'll take just 10 seconds to cover it off [inaudible] because it's basically an extension. If you use the Teleport CLI on your local machine, you get whatever native X stuff you want, copy, paste. If I'm on a Mac and I'm in a terminal, I have middle-click, paste enabled. If you're using that local CLI and you have it configured to use the `tsh ssh` which is basically the native implementation, you'll have all of that normal copy paste.
Diana: There's another similar question. Does Teleport replace Microsoft Active Directory (Microsoft Entra)? Shall we —?
Ev: The answer is yes and no. So first of all, Teleport can integrate with any identity source you already have, so Okta, AD. So Teleport simply becomes like a front end. We will authenticate users based on what is in that system. So you could take advantage of your existing investments in identity. But sometimes engineering teams actually say, "Hey, we don't want to use a company central identity." Again, it's just kind of — look, it's internal kind of politics of how they want to manage access. In that case, Teleport can act as an SSO provider itself. So once again, you have this optionality, either we can integrate with your source of identity or Teleport can become your source of identity.
Diana: So here's a question from Ken Ricketts, "Based on the business value, who do you typically see allocating budget for Teleport?"
Ev: So we usually run into — well, there are obviously kind of long tale of scenarios, but primarily we come out of either identity budget or privileged access management budget. So those are two kinds of common sources of where the budget comes from. But sometimes it also comes from just like a general platform engineering budget. So if you have a platform engineering team, sometimes it's called foundation engineering team or cloud engineering team — so they have a budget. Sometimes it comes from there. It depends how a company internally is structured.
Diana: And, John, how did that work in your organization?
John: For us, it comes from our infrastructure operations team. So my team is Budget. As I go to expand this to business enablement, I do plan on sharing that budget because there is a question over here, and I'm not going to depth, and you guys can, if you want. But the pricing model is per user, the way that we have going. So as I bring on more and more users across the business, I plan on sharing my budget with those consumers as well. But in our first year, it's all in infrastructure operations budget.
Diana: And there's another question for you here. "What Teleport features made you decide to use the product over others?"
John: Yeah. Without going into too much depth, for us, the product is great, and there are other great products. For me, it was ease of implementation — how quickly can I get it going? How quickly can I deploy it? So the tool itself is very good. The ecosystem of support tooling is also really strong, and Teleport is invested in improving, and they've set the standard. So you have to go into this with this knowledge, and for better or worse, there is a very rapid release cycle with Teleport. And we are attracted to that because we get to see fixes constantly, always improvements. It's every quarter, major release — every six months, major release, and minor releases every four weeks, three weeks. It's quite rapid. But I mean, every minor update sees improvements for us. So the tooling is great, but also, we had a great engagement really early on with Teleport. We have the ecosystem of tools. Support is really amazing. The pricing for us made sense compared to other PAMs. So it was both technical, but it was also a good relationship. I mean, we have a great relationship with Teleport. So that was probably one of the big drivers for us. Support's been amazing. The release cycle for us is really attractive.
Parting thoughts
Diana: Okay. So we're closing up on the end of our time here. So I'm going to ask each of you to leave us with one parting thought. Ev, why don't you go first?
Ev: Actually, I just saw there are several questions from Darren about whether Teleport supports AWS CLI and Azure CLI and RDP and X11. So a very simple answer is yes to all of those, and here's why. So to answer Diana's question, our vision of the future — that's why I want to share with everyone before we leave. Our vision of the future is this — is that the complexity will continue to increase. We're going to be adding more and more and more technologies into our data centers, into our cloud accounts. So managing remote access for every little thing individually is just not going to scale. It will work, but it will not scale. It's not a good scale story. This is why I'm so happy that John brought up the question of scaling early. And we will continue to get more and more different types of identities. For example, now everyone is training intelligent agents. Everyone is extending or building LLMs and putting those things into their infrastructure. They will need an identity too. They will not behave like humans. They will not behave like your typical microservices. That's a completely different type of animal that will also need to have a role — that will also need to have permissions. And those permissions will need to be elevated and reduced. So the point I'm making is that the complexity of computing is that it continues to increase. We have to consolidate access controls across all these different protocols and identity types. So that is simply inevitable. Whether it's Teleport or something else, or it's something else that you would build internally, I do encourage everyone to start thinking about this now, because the surface area of an attack will only continue to grow, and the cost of maintaining access control will be getting out of control. So this is why modernizing access matters so much in 2024.
Diana: Okay. And how about you, John, any final thoughts for the audience here?
John: Yeah. It depends on your organization, but I find if I can look at a tool that has a technical solution for a problem I'm having, that has real business value, that is very attractive for me. So if I can take a list of functionality and — great, from a technical standpoint, these are amazing. How can I realize value across the organization? Right? It's not only about solving my immediate problem, solving my scaling issue, solving my whatever. Every product that I want to look at, I always try to — if I'm taking it, especially to my CEO, if it's a large purchase, how does this benefit the business? Obviously, we'll pass audit, but that's a function. That's my role and responsibility, right? I can do that in a million ways. I want a product that if I'm spending the money, I can realize additional business value on. And for me, Teleport has been great for that. I mean, I'm using Teleport essentially to build out an intranet here where I don't need a VPN, and that's been really attractive because Indonesia national firewall, technical reasons or whatever is going on in Indonesia, right? So for me, it's business value, and that's where I'm getting the most buy-in from my leaders as well. So that would be my tidbits here — is if you can have something that you're buying or have something that you want to do that brings actual value across the organization, you're going to get a lot more adoption, better adoption, happier customers, whether your customers are engineers or your customers are paying customers. It doesn't matter. That's where I'm seeing the most value from a product like this.
Diana: Okay. Thank you, John. So for our audience, if you asked a question, we did not get to it, we will reply with an answer after the call. I'd like to remind you about the survey. If you'd like to comment on your experience today, we'd certainly appreciate it. And thank you, Ev, and thank you, John, for joining us today.
John: Great. Thanks so much, Diana.
Ev: Thank you.
John: Thanks, Ev. I really appreciate it.
Diana: Bye, everybody.
John: Bye-bye.
Join The Community
