Introduction to Teleport

Introduction to Teleport - overview

Want to know how Teleport's Access Platform technology replaces VPNs, shared credentials, and legacy privileged access management technologies, improving security and engineering productivity? Watch this session from Phil and Alex to learn more about Teleport's Certificate Authority and Access Platform for your infrastructure so you can:

• Set up single sign-on and have one place to access your SSH servers, Kubernetes, databases, Windows desktops, and web apps.
• Use your favorite programming language to define access policies to your infrastructure.
• Share and record interactive sessions across all environments.

Key topics on Introduction to Teleport

- Teleport is the easiest most secure way to access infrastructure.
- Without Teleport, engineers must access infrastructure using an insecure and cumbersome siloed mix of VPNs, bastion host, jump host, legacy PAM solutions, all of which renders visibility minimal and causes high error risk.
- The solution is identity-native access (which Teleport provides) for infrastructure, and this is comprised of secretless and zero trust.
- In addition to identity, Teleport stores your cryptographically validated identity in secure enclaves that already exist in your devices today.
- There are many reasons why developers, security engineers, and customers love Teleport.

Expanding your knowledge on Introduction to Teleport

- Teleport Desktop Access
- Teleport Device Trust
- Teleport Machine ID
- Teleport Passwordless
- Teleport Server Access
- Teleport Application Access
- Teleport Kubernetes Access Guide
- Teleport Database Access

Learn more about Introduction to Teleport

- Teleport Labs
- Contribute on GitHub
- Join our Slack community
- Participate in our discussions
- Why Teleport
- Get started with Teleport
- Teleport Resource Center

Transcript - Introduction to Teleport
(The transcript of the session)

Alex: 00:00:00.119 So should we just wait for a couple of minutes? Give everyone a chance to join. Yeah.

[silence]

Alex: 00:00:18.274 So what have we got so far?

Philip: 00:00:19.912 10 people watching.

Alex: 00:00:20.392 10 people watching. Great stuff. I think we had 20 registrants. So we'll just give it a minute or two to let the rest join. But welcome to everyone that's on so far. Thanks for taking the time to join us today. We'll just give it another minute, see if we can get this up to 20. So for those that have joined, we have Kateryna from our marketing team on the call. So if you want to ask questions, just put them in the chat section where they get moderated, and then she can share them with us throughout the call and we'll have a bit of time at the end for questions. So feel free to ask away and myself, probably more likely Phil, will try and answer as many as possible in the time that we have. We seem to be at 10.

[silence]

Alex: 00:01:39.043 Okay. Give it another minute. I'll just share my screen. Okay, guys we'll just give it another 30 seconds or so. See if we get a few more people joining.

[silence]

Alex: 00:02:33.547 And then I can crack on. Oh, 14! Okay. Okay. I think it's three minutes past. So shall we just get moving? Okay. Good stuff. Right. [laughter] Hi everyone. Thanks for taking the time to join this Introduction to Teleport webinar. For Kateryna from our marketing team who's kindly joined the call to moderate everything and help us through this session. It's me and Phil's first time using this platform. So hopefully it goes smoothly. But just bear with us and hopefully, it will all be — it will be fantastic. So if you guys want to ask questions, stick them in the chat on the right-hand side, I believe, and she's going to look through them. Yeah. Obviously, moderate them. And then she can post them to myself and Phil sort of later on. We'll try and sort of keep about 10 or 15 minutes towards the end of the call for live questions. So we can do some nice interactive questioning. But also feel free to ask throughout the call. And yeah, perhaps we can stop and answer some questions as well. So yeah, I'm just going to briefly introduce you to Teleport. Discuss why it was created and the challenges it solves. And then Phil, our fantastic EMEA Solutions Engineer, will deliver a demo into the different elements that make up the Teleport platform. And then at the end, we can answer some questions.

The easiest most secure way to access infrastructure

Alex: 00:04:13.695 So first of all, really, yeah, so to describe Teleport — Teleport really is a rare security solution in that it actually makes it far faster for engineers to do their jobs while increasing security levels at the same time in parallel. Likely, helping to make your organization far more secure than it currently is now. So nearly all organizations that we speak to, and we speak to a lot, have implemented security solutions that developers didn't really adopt and don't particularly like and don't particularly find easy to use. This is one of the main sort of pain points that we see. And the reason for that being that they're a pain to use. Developers are generally super smart and they're generally smart enough to kind of get around them. So if you really want someone, especially your DevOps teams to adopt a security solution, it really has to be a super simple tool. And that's what Teleport has done with identity-native infrastructure access. So let's take a look at it.

Alex: 00:05:09.907 So without Teleport, engineers must access infrastructure using an insecure and cumbersome siloed mix of VPNs, bastion host, jump host, legacy PAM solutions, all the tools that most companies currently use — each with its own access control and audit layer. So visibility can be pretty minimal, and the risk of an error is high. Controlling permissions for services connected to your infrastructure just becomes very, very complex and very siloed. So with Teleport, every connection across your global infrastructure passes through Teleport's identity-aware access proxy, where it's authenticated and authorized based on human or machine identity. And because engineers and services are treated the same, you get complete visibility and control over every connection without managing different access control systems, making life super easy for you. And because Teleport bases authentication on identity, instead of static credentials like SSH keys, passwords, it's far more secure, it's more cost-effective to scale, and it's far more easy to use.

The solution: identity-native access

Alex: 00:06:16.261 So let's have a look at the solution itself. So the solution is identity-native access for infrastructure. And identity-native is comprised of two things: secretless and zero trust. Secretless basically means taking the number of attack vectors off the board. So there are no passwords to be stolen or phished. No legacy PAM systems or vault keys to manage, making your life easier. Less systems for DevOps to, basically, fight and have to get through each time they want to access a piece of your company's infrastructure. And the second component of identity-native is zero trust. And zero trust completely throws out the idea of a corporate network, with all access between humans and machines being used based on identity. So the primary component of zero trust is Internet-facing access proxy that controls access between resources from any locations that you have throughout the world.

Alex: 00:07:07.478 So how does Teleport do identity-native infrastructure access? Let's have a look. So we start with identity, and it says cryptographically validated — a bit of tongue twister there — identity for everything. So that's DevOps developers, machines, applications, databases, whatever. There are no passwords or secrets inside. Teleport was born identity-native from day one. So we have never used passwords and we've never used any credentials of any kind. A lot of organizations were trying to make this kind of legacy access management solutions. Many of our competitors. Won't name any names, but they're trying to make them in a modern cloud infrastructure world, and it's just not working. So these vendors are identity-washing their solutions to fit with these modern infrastructures. But under the hood, it's the same old thing. Passwords, keys, shared secrets, shared credentials, zombie credentials flying around, and this is causing the risk of a breach. So these solutions don't do anything to improve security and what they do is slow down your developers and engineering productivity.

Alex: 00:08:15.440 So in addition to identity, Teleport stores your cryptographically validated identity in secure enclaves that already exist in your devices today. So things like TPMs, HSMs, Touch ID for Mac. Teleport uses these built-in security devices to protect your identity on the device itself so they can't be stolen or tampered with. So, for example, if a device is stolen, it doesn't mean that your infrastructure is actually at risk. Teleport requires proof of presence in the form of per-session MFA so that the authorized user is the one that actually is accessing the infrastructure. Then all connections between resources are mutually authenticated, not only from identity perspective between the device themselves but at the network level. So Teleport uses mutual TLS for all network connects so that connects cannot be spoofed — to prevent attacks.

Why developers and engineers love Teleport

Alex: 00:09:09.770 So why do developers and engineers love Teleport so much? And they tell us this every single day when we speak to them, and they want more Teleport. Basically, because it's the easiest way to administer access from one place. Teleport consolidates a variety of different manual processes and interfaces to provision access by resource, giving a single source of truth for all your access across all your infrastructure. It's infrastructure agnostic. So it doesn't matter if you have a hybrid infrastructure or you're migrating resources between clouds. With a Teleport access platform, developers and engineers have a real-time inventory of their entire infrastructure in a single console, making life super simple. Just-in-time access requests. So no need for long turnarounds to submit tickets to ops or tickets while remembering to close those tickets. So any requests get dealt with really quickly. And then you can, yeah, notify the team member of their relevant or elevated access really simply and really quickly. And we've partnered alongside tons of other tech tools for loads of first-class integrations, which allows us to be an easy part of your tech ecosystem. So that's things like SSO. IDPs, Slack, Jira, Microsoft Teams, Terraform, just to name a few.

Why security teams love Teleport

Alex: 00:10:28.407 So why do security teams love Teleport? So, single source of the truth. Teleport consolidates multiple layers of access across all the modern tech stacks. Zero trust infrastructure access to Teleport is the easiest way to implement BeyondCorp and zero trust architectures for modern engineering teams. All connections from any engineer or machine are user authenticated, authorized, and audited by Teleport’s identity-native access proxy, which gives you full zero trust. We can render phishing and pivot attacks useless. So Teleport removes the number of sources of breaches and greatly improves not only your organization's security posture but the infrastructure access experience by replacing all your passwords and secrets and giving you that easy kind of biometric and hardware-based machine identity. So we also, yeah, reduce auditing and compliance burdens, which are a nightmare for most of our customers. So many Teleport customers operate really highly regulated and secure infrastructures that have to have that kind of constant and ongoing audit and compliance scrutiny, and customers use Teleport’s identity-native infrastructure solution to meet those key controls and audit burdens in a variety of really, really complex and difficult frameworks such as FedRAMP and PCI, SOC 2, ISO, NEMEA, HIPAA, SOCs, and all the rest. So yeah, so Teleport really is the leader and first identity-native infrastructure access platform for engineers and machines. And by replacing insecure secrets with true identity, the Teleport access platform delivers that frictionless developer experience and tears down those siloed access tools with phishing-proof zero trust for all your engineers, all your DevOps guys, and attaches to all your global infrastructure.

Teleport customers

Alex: 00:12:25.965 And here you go. You can see some of the people that we're trusted by in production. Tons of customers throughout the world. And these guys really care about DevOps moving at pace. That's one of the key things. It's DevOps moving at pace while maintaining that best-in-class security posture. So Teleport is an open-source access platform that improves developer experience while increasing security by replacing all those VPNs and shared credentials, secrets, and vaults, and legacy access management technologies. So that's just a quick sort of introduction of Teleport and the problems that we're trying to solve and that we are solving. And so now what I'll do is I'll hand over to Phil and he can explain a bit more about how it works under the hood, show you a demo, and get into the technicals. So I will stop sharing by clicking the stop sharing button. There we go, Phil. Over to you.

How Teleport Access Platform works

Zero trust

Philip: 00:13:23.393 That's great. Great. Alex, thank you. Great. So we'll get into a demo in a little bit, but I think we'll just take some time to get into a kind of deeper dive of what's happening under the hood in Teleport and get into the technology behind it and the Teleport access platform. And as Alex had called out, your Teleport is adhering to zero trust principles. And in that sense, what does that mean from a Teleport perspective? We have our identity-native proxy. And that's typically an internet-facing proxy where all of your resources are connecting to. So that's what's ruling out the need for VPNs and supporting any resources in any location and removing the need for any perimeter-based security. And all of your resources, be it Linux, SSH servers, Kubernetes clusters, databases, Windows desktops or applications, are all connecting to that proxy over a reverse tunnel. And the important point there, again, meeting that kind of zero trust requirement, is that reverse tool is on a single outbound port from those resources to the proxy.

Philip: 00:14:41.153 And so that's ensuring that there's no ingress required on those resources and we're essentially creating the reverse tunnel on that outbound connection — or multiplexing on that outbound connection is the term we use to create that reverse tunnel. And that's far more secure. That you don't have any ingress on those resources. And so they're private within your own infrastructure but connecting out to the proxy. And that proxy itself can be self-hosted in your own infrastructure and in your own cloud environment or in on-premises or your own data centers. Or Teleport also offers their own cloud offering, where we're hosting the proxy essentially for you and your resources are just connecting out to our cloud solution. Teleport is also infrastructure agnostic. Again, meaning that any resources in any location, it's all the same, essentially, to Teleport. Those resources are connecting to a proxy and access is centralized within that single solution, regardless of where it's based, but also providing a consolidated role-based access definition across all of your infrastructure.

Secretless

Philip: 00:16:00.894 Now, in terms of that secretless term that you heard from Alex earlier, we achieve that using short-lived and scoped certificates. And that's true. Our certificate authority, that's a core component of the solution. So when users and machines too, it's a service account, log in to Teleport, they're going to get a short-lived and scoped certificate. So it's short-lived in the sense that it will live for a number of hours that you define. That could be eight hours to reflect a working day or reduced to a shorter time period or a couple of hours if the user is accessing a more privileged environment that you want tighter controls on. It's also scoped, as I said, to a job role so that users only get access to the resources that they need to work through their working day. So it's that principle of least privilege that's within that certificate, so they're only seeing and working on resources that they need to on a day-to-day basis. So they log in. They get that short-lived certificate. And that certificate and that approach can be used by both human users and machine or service accounts using a feature in Teleport called Machine ID.

User access

Philip: 00:17:23.274 Okay. And then in terms of users accessing the platform, and that's what we'll see more of in the demo to come for your engineers, it's a very similar experience to what they're doing today. Frictionless and not shifting them away radically from any tools that they're using currently. So they're going to use our web user interface or work on the command line using our tsh tool, but they can continue to use kubectl for Kubernetes, for example, and their existing database GUI clients for accessing database. It's just that in the background, it's certificate-based authentication that's used, as opposed to username and password or any static credentials or keys in the background.

Philip: 00:18:14.862 And to facilitate a single source of truth, we would integrate with identity providers within our organizations so that identity provider stays as that single source of truth. That's where users are onboarded and off-boarded. And we sync with that identity provider and take group management policies from that identity provider and map them to roles within Teleport. So users are going to get access to infrastructure based on the group management policies that you have defined within your identity provider. If you change them in that one place in the identity provider, then that's going to reflect then when they next log in to Teleport, and they will see and have different infrastructure access based on that change in that one place. Similarly, if they're off-boarded and they leave the organization, you off-board them in a single place, they're gone, and they no longer have infrastructure access, and you don't have to worry or be concerned about zombie credentials or going through quite a tedious process to remove all of their access across all of your infrastructure.

Compliance

Philip: 00:19:25.954 Finally, in terms of compliance, Teleport supports session recording and provides audit logins, so you have full oversight on what's happening within your infrastructure. You can play back those session recordings and see exactly what happened. And that is also for compliance reasons but can also be just for day-to-day forensics. If an issue has happened, then you want to understand what change was made. If you need to roll back that change, session recordings are there for that purpose as well. Similarly, with audit logs, logging everything that's happened in terms of access within the solution. And those audit logs can be also forwarded out to a log aggregation or SIEM solution like Splunk or Datadog or Elastic sack. And it's within those tools that you typically see deeper reporting analysis based on that log content and potentially alerting based on log content. Okay.

Philip: 00:20:29.617 And finally, then we have the concept of just-in-time access requests. And these are requests for elevated privileges to access additional resources within your infrastructure. So, as I mentioned before, we're working on the principle of least privilege. So users have access to what they need to access on a day-to-day basis, but they don't have additional access to other environments that they use on occasion or that they've held over from previous work that they've done. So we have this workflow that we integrate with the likes of Slack, Teams, Jira, and PagerDuty, and other plugins can be built also where you can quickly approve requests to get elevated privileges to support an emergency situation or the fact that someone's on sick leave or that there's an ongoing maintenance window. And users will get a time-based access to that additional resource, can work on that resource once that request is approved, and then they'll immediately revert back to their default role definition after that time. Okay.

Philip: 00:21:44.949 I'll just pause and have a look at the Q&A and see if there's any questions I can pick up and answer at this time. So Dominik had a question in relation to a password management tool in Teleport. So Teleport doesn't manage passwords and won't in a sense. That's not how Teleport works. Where we typically see passwords used will be for database access and potentially Windows access. But in both cases, we're replacing certificate-based authentication. Specifically for Windows desktops, their approach to replacing passwords is using smart card emulation, and we'll see that later in the demonstration, so. And likewise, when you implement Database Access in Teleport, you're moving away from a common username and password and enabling certificate-based authentication on those databases. Now, Richard had a question. Will Teleport have the ability to scan infrastructure and determine which servers and databases have not been onboarded or configured to use Teleport? So we do have what we call auto-discovery features that are being added over time. They're new features that are coming in. So where we can, particularly on the big cloud providers — AWS, for example — auto-discovery of EC2 instances, auto-discovery of RDS databases, auto-discovery of EKS databases. So with more discovery options to come in GCP and Azure as well down the line. But yes, it's not so much a scan, but an auto-discovery is the term we would use for that feature. Great. And I think we'll move on next to a demonstration.

Demo time

Philip: 00:23:51.233 Okay. So I'll start off with the demonstration of a user accessing Teleport within the web user interface. Then we're also going to show you that experience from the command line and a few other options for users accessing the infrastructure. So presented with the login page in Teleport, we can see this as a representation of the proxy that users are accessing. And I've integrated with a number of different identity providers, just as examples, using OIDC and silo-based integrations to these identity providers. And there are options to integrate with an identity provider, but also to use local users in Teleport. So supporting username, password, and second-factor authentication with the use of hardware keys and authenticator apps based on your choice.

Server Access

Philip: 00:24:44.854 So logging in to Teleport, picking one of those single sign-on options that I have, and I land on the server's dashboard. So this represents Linux servers. And we can see along the left-hand side those supported protocols that we support. So applications, Kubernetes, databases, and desktops. And we'll step through each of those protocols as part of the demonstration. But for now, we'll focus on Linux or SSH access into Linux machines. What's kind of standing out on this dashboard are a lot of labels. This could be analogous to tags that you would have with a cloud provider. AWS has the concept of tags or you're tagging servers. And we would integrate with tags to present those same tags within the dashboard if required. So we're tagging our labeling each server here. I've labeled “env” “dev” on this particular Linux server. So I'm defining it as a development machine. And similarly, I have a test label on a different server. So I'm using those labels to define what these servers are used for. And it's those labels on those resources that are then used in role definitions that decide which users get to see and access which resources. So obviously in that dev example, resources with the “dev” label are going to be really mapped to a role for developers, so that when developers log in, they see the right resources.

Philip: 00:26:25.560 When connecting to a Linux machine, I can configure what logins a user can use. Should the route user be restricted, in a sense, or only certain users should be given permission to use the route user or do we want to enforce that users use their own individual account or is it okay for users to share the same kind of common account on Linux machines? Okay. So we can make that choice as part of the configuration as to what we want users to do. So we then have an online SSH session. And within the browser, users can choose whether they wanted to work within the web UI for SSH access or work in the terminal. We'll see terminal access a little bit later. But that's really a user preference for the end users. So I'll execute some commands on this particular session just so we can see some activity in the session and within the audit log and session recordings. Okay. I'm going to log out from that session.

Philip: 00:27:47.383 So we can start multiple sessions in parallel also within the tab structure within the browser. Okay. And then close them out. Now, if I want to look at the auditing of what's happened so far with those sessions that I've undertaken, we can see that I've logged in as that single sign-on user and I've undertaken a number of SSH sessions. We have server sessions tracking that first event that I opened up. I was this user `philip` that opened that session, the time I opened the session, and also the Ubuntu login that was used on that particular session. And all of this data's purposely in this JSON format so that we can forward the content or that detail to a SIEM or log aggregation solution. Okay. And then finally we have the playback, which is the session recording of the session that you previously saw. Okay. And we've captured the raw data within that session and then formulated the playback. So we have access to that raw data, should I need to cut-and-paste out from that recording for debugging purposes.

[silence]

Philip: 00:29:27.340 Okay. So we'll end that and come back to look at an additional — move on from looking at Linux servers. But I see a question from Dominik there. So will Teleport be browser-based only in the future, or are we seeing an application or perhaps a FreeBSD for server development? So at this moment in time, we have three options for users to use: the web user interface, to use their own choice of terminal for command line access, and we also have our own native tool for Mac and Windows, which is Teleport Connect, and it's again, a graphical user interface that can just be installed locally on machines as an alternative to the web user interface, okay? But then you'll see a lot of use of third-party GUI clients, particularly for Kubernetes access, where an example would be Lens for databases. You'll see many, many different database GUI clients used. So long as that database GUI client supports a certificate of authentication, then it's okay. And most do. So typical use cases we'll see will be MySQL Workbench, pgAdmin for Postgres access, DB, or a long list. So there's a lot of options there in terms of tooling and applications that can be used with Teleport.

Application Access

Philip: 00:31:00.329 And moving on to Application Access, then. And we think of applications. These are internally hosted web applications. So these could be tooling, dashboards, wikis, internally that you have, that you're typically protecting with VPN. But now with Teleport, you can provide role-based access to those endpoints. And that is about accessing that application within the web browser, but also controlling access to any API endpoints that that application exposes that could be used on the command line. So again, kind of wrapping access to that application in both ways using certificate-based authentication. Now, examples of that would be Grafana or Jenkins installed in your own infrastructure, where you launch into those applications from Teleport. And we've implemented a JWT integration approach where you can provide users with a seamless logon to applications so that they come into the application as their logged in Teleport user. And again, moving those users away from username and password-based authentication within these applications.

Philip: 00:32:13.515 Now, looking at the URL, we see that it's Grafana gated behind a Teleport cluster. So if anybody bookmarks this URL, they'll be required to log into Teleport to get back to this point and also still have the appropriate role-based permissions to get back to this particular endpoint. Another example is controlling access to cloud provider APIs and consoles. The example I have here is the AWS console. So it can allow users to assume different IAM roles within AWS. So we connect out to that console as that Teleport user with that IAM role. So this user does not exist within the AWS account. It's through our integration that we're allowing the Teleport user to assume that IAM role.

Desktop Access

Philip: 00:33:14.080 Okay. Now, for Kubernetes and databases, kind of next on the left, we typically see access either through the command line or through other graphical tools. So within our own web user interface, we provide information on how to connect to those resources. And we'll see that in a second when I jump out to the terminal window. But the last option within the web user interface is accessing Windows desktops. And this is where we see a passwordless approach to Windows access where we can integrate with Active Directory and auto-discover all of your Windows hosts that are connected to the domain controller or support stand-alone Windows machines individually connecting back to the Teleport cluster. But in both cases, the experience for the user is the same. And similar to the Linux server example that I have, you're allowing or mapping different users to different usernames to access these Windows machines and have labels on these Windows machines to be able to then define roles that would control access to them.

Philip: 00:34:28.560 When we log in as one of the users, we can see that I'm bypassing the password requirement to Windows using that smart card emulation that I referred to earlier in the call. So again, seamless log on for those users. And then within a Windows session, users or administrators can control whether clipboard can be enabled or disabled, and also enable and disable directory sharing. So I can cut-and-paste here from outside of the session into the Windows machine because that is enabled in this instance, as is directory sharing. So I can share it from my local machine into the Windows machine if I need to, but those options can be disabled on more privileged servers if tighter controls are required. Disconnecting from that Windows session, I have a session recording of that then as well to play back, seeing exactly what's happened within that Window session. I can speed that up a little bit. So you'll see that playback of that Windows session.

[silence]

Command line access

Philip: 00:35:50.466 Great. I'll just take a pause and have a quick look at the Q&A. I think we're up to speed. There's no additional questions. So I'll continue on. That's great. So, moving out to command line access to these resources, I log in to the same cluster from the command line. Again, hitting my integration with my identity provider. And now I can see that I'm now logged into the cluster on the command line. Where this is the first time we see reference to the certificate validity. So we can see, based on the roles that I've been given within the cluster, a certificate has been generated that will be valid for two hours. So that's the configurable time to live on certificates based on what the user is accessing. Quickly show you again SSH access. So I'm listing out the servers, the Linux servers, that I have access to. That's the same five servers that you saw within the web user interface. When I SSH into one of those servers, I can then just work as I normally would do within that Linux session.

Database Access

Philip: 00:37:15.500 Moving on quickly and quite easily and switching between protocols. Switching from SSH to databases, I can list out the databases that I have access to and can connect to one of those. Picking MySQL database. And can now have direct command line access to that database where it can execute select commands. And that “select query” is going to be audited in Teleport, and we'll see that in the audit log a bit later. So in terms of database access, you're controlling access to specific databases and the user accounts that are on those databases that users can use, but also then having full auditing of the queries that are executed within those sessions.

Philip: 00:38:04.240 We talked before about looking at using database GUI clients. And we can see, if I look at my tsh folder, and this is my Teleport folder locally on my machine now, I can see where my certificate files are living. And I can use these certificate files to plug into my database GUI clients to use certificate-based authentication within those clients. And that's typically a one-time configuration within those GUI clients to point the connection to the file paths that you see here. And those file paths are reasonably static in that they reflect the cluster name and the user's name. So they don't change over time. Okay.

Kubernetes Access

Philip: 00:39:00.847 Now. Okay. So then next we'll move on to Kubernetes access. So we'll list out the Kubernetes clusters that we have access to, and I can then log in to one of those Kubernetes clusters. So it's from this point, I can move forward with kubectl exec calls. I can execute a `get pods` on that particular Kubernetes cluster. You can see that I have one cluster — one pod within that cluster that I can access. And that API call to get the pods will be audited again in the Teleport audit log. But an even nicer feature in Teleport is the fact that we record kubectl exec sessions. So that gives you full oversight about the API calls and the kubectl exec sessions. So we can execute a few commands within the kubectl exec session and this will be recorded and played back in the same way as you saw the SSH sessions. So full coverage there. What a unique feature that Teleport has to give you that full oversight for Kubernetes access.

Audit log

Philip: 00:40:22.193 Okay. And just jumping back to look at the audit log of what's happened within my time on the terminal window. I've had that additional session that's been recorded. That SSH session. We can see database sessions that have been started and ended, and the query that's been executed on that database. So we can see the specific database query that was executed on that database as part of that session. And similarly, for Kubernetes, capturing the API calls that were made so we can see the get operation on the pods resource and also the session recording of the kubectl exec session. Okay. I'll pause again and look for questions. I think I might have been looking in the wrong place, but I can see a few more questions that I previously missed. So let's take a minute to kind of go through some of these.

Philip: 00:41:27.070 So what would it look — Chidozie had asked the question, what would it look like for a Windows server? Will agents be installed on these? So as I kind of mentioned when talking about Windows Desktop Access, there's two approaches. We can integrate with Active Directory and auto-discover those Window servers through direct integration with Active Directory. So in that case, there's no Teleport process running on the Windows clients. All integration is with Active Directory. But where a Windows machine is standalone and not connected to a domain controller, then there will be a Teleport process running, connecting back that individual Windows machine to the Teleport cluster. Richard — is there any support for sale point provision access to Teleport? I think that's one I'll have to come back to. I'll look for use cases and see if anybody has done that. I don't see a problem, Richard, but I don't want to say for sure now, but it is something we can take away and come back to you.

Philip: 00:42:44.278 We've got one question. I answered Richard's next question. Do you plan password — yeah. So I think I've covered all of the questions now, which is great. Oh. Mircea has a question. Is Teleport installed on-premises or cloud or else? You have a choice there. In terms of Teleport, it can be installed on-premises, on your own cloud, or take our cloud offering. So there's a lot of flexibility there, so. And deploying on the cloud, there's different options to use the different storage backends within those cloud providers. For example, an AWS using DynamoDB and S3 buckets to store your Teleport configuration data and session recordings. So how is password management performed and where and how it links between users? So there is no passwords to be managed, essentially, in this situation. Where we see passwords is typically in your database access, but users no longer have access to passwords — we would enable certificate-based authentication on databases. Or for Windows is where we would see a typical use of passwords, but we now provide a passwordless approach to Windows access. So users are linked to roles within Teleport, and then Teleport itself is then managing how both the databases in Windows, in that sense, connect to the cluster. So Teleport is managing that for you through certificate-based authentication.

Just-in-time access requests

Philip: 00:44:45.570 Okay. Now, one last thing to show is the concept of access requests. So we'll quickly show you that, and then we'll finish up with the demonstration, okay? So in terms of accessing Teleport for different user profiles, I'm going to login in a different browser window now for a different user who we'll see as a contractor. So a contractor that's looking to get access to resources within your infrastructure. `conor` is my contractor here, this user. But he doesn't have access to any servers, applications, databases, or desktops. But what he can do is to make a request for access and be provided with a list, and that list is controlled as to what he can access. So he's going to request access to servers. We'll proceed with that request. Say, "I need access now," and submit that request. Okay. And I have an integration with Slack in my environment. So I can see the message that's come from `conor` that he needs access now, and we can automatically approve that as an approved user and give him access to what he needs. Okay. So this is now escalating privilege, essentially. So `conor` will have temporary access to those server resources based on that approval. You can see the approval message back from myself, the approver, and he can assume the role. And we can see in the top banner that he now has access to servers for two hours, and he now has can see and view servers that he couldn't access before.

Philip: 00:46:43.861 So we'll log into that session as `conor`. We execute a few commands. And another nice feature of Teleport is the concept of active sessions. So myself, as the administrator, can see that `conor` has an active session. And I can actually join that session as a peer and help him out with his session. And we can both see what's going on within the session and perhaps troubleshoot together. And I can also — there we go — contribute to that session as well. When we log out, we come back to the session recordings, we can see that there's a joint session for both `philip` and `conor` and the playback will include all of the commands that are executed by both these features. So another layer of oversight and assistance that can be given within Teleport with active sessions. We do have the concept of Moderated Sessions as well, which is enforcing that a minimum of two users are present within a session before a session begins, and that's implementing the four eyes principle. So that would ensure in that instance, in a highly sensitive environment or privileged environment, that no one works alone — is the concept there. And that's Moderated Sessions.

Wrapping up

Philip: 00:48:14.322 Okay. So I'll finish there in terms of the demonstration. I think at this point, we have covered all of the questions. Alex, any insight from yourself? Have I covered everything? Are we good, do you think? I think I had that one question that we had to take away from [crosstalk] —

Alex: 00:48:34.643 I think. [laughter]

Philip: 00:48:34.751 — and we're all good.

Alex: 00:48:37.643 Yeah. I feel like you've covered pretty much everything at length. Yeah, the differences with CyberArk. I think we've gone through that. Yeah, obviously the differences with credentials and certificate-based. What else have we not covered? Have a look — any new questions. I can't see any new ones that we haven't or that you haven't covered, to be honest. Any more questions? Anyone have any more questions, the remaining 15 people?

Philip: 00:49:22.309 As Kateryna pointed out as well, our community Slack channel is there [crosstalk]. So any technical questions, there's a lot of help in that community. And tag me in that community as well with any specific questions as well to come back on any technical points. And I'm sure we'll follow up with everybody and give everybody an opportunity to have a deeper dive if they want and ask more specific questions directly.

Alex: 00:49:52.974 Yeah, exactly. Yeah. I think we're going to follow up with everybody sort of, yeah, post-call. So yeah, if you need any information on any of the technicals or pricing, anything like that, then we'll reach out to you and we can set up a follow-up session and discuss in more detail. But I suppose other than that, all that's left is to thank everybody for joining. And I hope you enjoyed our first EMEA webinar. Yeah. Anything from you, Phil, or?

Philip: 00:50:24.154 No. I think we're good. That was a great session. Enjoyed it.

Alex: 00:50:28.357 Yeah. Yeah. Hopefully, it all went well. Looking forward to the next one. So hopefully, I think this is going to be a monthly slot. So yeah, just sign up to these every month. And they're just going to get better and better. And hopefully, yeah, we'll get more and more people on them and make them, yeah, more interactive, and yeah, to keep asking the questions. But yeah, okay. Great stuff. Thanks everybody. Thanks for joining. And we'll talk to you all very soon.

Philip: 00:50:54.904 Thank you. [crosstalk] —

Alex: 00:50:55.384 Thank you. Bye-bye.