Infrastructure Auditing Made Easy

Infrastructure Auditing Made Easy

This webinar will be a deep dive into Teleport’s new Audit Log capability, dashboard, and refreshed unified resource UI. Teleport 14 introduces a new audit log backend that provides unrivaled visibility into all activity on a cluster. Allow teams to translate infrastructure audits into faster insights and actions, thus helping them make informed access decisions, support downstream SIEMs, and log consolidation tools.

The second half of the webinar will introduce new Access Control Lists, a new just-in-time access requests flow to grant and review long-term access for employees. With an updated unified resources catalog to quickly view, favorite, and access the infrastructure resources you need.

In this episode, we will cover:

- Teleports’s new Audit Log, available for Teleport Team and Teleport Enterprise Cloud
- How to use the principle of least privilege with Teleport Access Lists
- Teleport's Refreshed UI
- Bonus Teleport 14 Features

Transcript - Infrastructure Auditing Made Easy

Ben Arent: We have Kat from Santa Clara, California, my favorite spot. So also, today we have Kat and Lexi, who are going to be moderating and helping out if anything goes wrong. And it looks like I am fully live. So it is now 10 o'clock. Hi, everyone. Thanks for joining. My name's Ben Arent, and I'm going to be kicking off in one minute. Please get familiar with our platform here. You'll see that we have a little chat box. I'm going to be having a few surveys, and I've also put some media here. So please say hi from where you are. Lexi said, "Raining in Chicago." That sounds chilly. And Teleport team will also be in Chicago next week for KubeCon, for anyone else who will be going. And let me just give it a couple more minutes for people to come in, and then we will kick things off.

So today's webinar is all going to be about infrastructure auditing made easy. And I'm going to go back to some of the fundamentals of infrastructure access. And then, also, auditing is a key part of infrastructure access. What do I mean by making it easy? Well, we'll find out in this webinar as we sort of kick things off. So to start off with, Lena, let us go to some of the basics and the fundamentals, like what is auditing. It's the ability to have the visibility of what happens across the environment to collect aggregate audit logs from every system, a process known as auditing. And so this can be answering questions, such as which assets or identities were compromised, the who, if an audit, which files or resources were accessed, the what? What was the time frame of an attack?

You may be auditing not necessarily for cybersecurity compromises, but this is one reason that you might go back and see what happened. There could be a range of other reasons that you might want to know what was the timeframe. For example, if you have someone accessing systems in the middle of the night, there might be something happening that you may not like. And how did an attack happen? So an audit log might give you some hints of the tools and examples that they use to get access into a system. For types of logs, there is logs of different-- between different systems. So I'm going to go into this a little bit more. But for example, SSH logs are different from MySQL logs, which are different from your infrastructure logs, but they mostly have a few things in common. One is the time or the occurrence of the event.

Next up is the resource, whether it was your database or a specific server. The action, for example, was it a crowd update? Was it a create, read, update, or delete? Or was it just, for example, someone accessing. It might just be a read, or let's say dumping a database would be a delete, or the dreaded RMRF. The identity, who was issuing the command, this could be interesting to debug what happened. One thing that we see sometimes is that people have shared accounts. So you might all be logging in as EC2 user. So you only see that the EC2 user performed the action, but you may have a hard time identifying which member in your team assumed that role to be the EC2 user or Ubuntu, for example. This is another reason why using the root-- among many, that is a bad idea. And then lastly, the parameters that were used to run in the command. And this is, for example, a example from a open SSH log.

You can see here that we have a timestamp and then what was the time zone difference, the IP address, the SSHD, what was the port, and then lastly, what was the action. So there's an invalid user from this IP address on this port. And then if you break it down, this is kind of what you see, so time, resource, action, identity, parameters, and result. And for people who are familiar with logging, you'll notice that many systems, if you are putting all of your logs into a central one, even getting things such as time to be consistent across these logs can pose challenges. And not everything is always consistent between logging platforms and tools. And then there's also multiple different layers of logging.

So for example, databases have their specific logs. Applications might have debug logs or standard libraries that you'll output to, and then different verbosity of logs. So you might want to have a debug, or you might want to have an error log. And then these also get sent off to centralized tools. And then on the host. You have syslog. Network, you might be using something such as AWS Traffic Mirroring to figure out what's happening at the network level. And then lastly, for platform, this would pretend what platform you have, but let's say you're using Amazon Web Services. You can use CloudWatch logs to see what were people doing on the AWS console platform itself. And then we have the human access to the infrastructure. So I'm going to cover a little bit of machine access, but primarily going to focus on human and team access. So for example, for servers, you use SSH keys. For databases, you might use a username and password, which might be shared. AWS, you might've shared a IAM user across a team. And then kubectl, it might be the same thing. You might have a kube config that you share around your team.

And then for auditing, these are all different places that you can get this audit log. So you'll have the audit deconf, audit log, CloudWatch, and then Kubernetes audit log also built in. But there are a few problems with this, and this is one of the problems that Teleport went out to solve. And what happens is, you start off with a relatively simple infrastructure, maybe some few instances, an RDS instance. You just have one teammate. But as you sort of grow and add more members to your team and you add more resources, you might want to split out your account into a production and staging. Now you have multiple fragmented assets in your infrastructure that you're trying to capture, who's accessing which services. And we start off relatively simple. So you might just be having a few teammates who share a SSH config or a MySQL password. But as you add more people to your team, maybe another cloud, even more users, the list kind of goes on.

And so I'm going to introduce sort of how Teleport addressed this problem of all of these resources and all of these teammates needing to get access and some of the problems that they had. And so the Teleport access plane is a tool to consolidate all of the four essential capabilities of access. And we see that as connecting, authenticate, audit, and authorize. The connectivity is all around providing a central gateway that provides strong TLS zero-trust authentication. Authentication is checking that that person can get access to the system to-- the authorization is, once they have access to the systems, what are the resources that they can get access to? And as I've gone back to my previous example, these systems can be different. So for example, if let's say we take the example of an attacker, if they get access to an EC2 instance and you're running Kubernetes on it, they might be able to have lateral movement and get access to all the different systems sort of through a backdoor.

And this is another reason why auditing is so important. And Teleport, for people who aren't familiar, it delivers identity-based access for Linux and Windows databases, Kubernetes clusters, internals apps. I'm actually going to cover a lot of this today. I'm going to give you a demo of database access, AWS access with our application access, Kubernetes, and server. And this is kind of what the configuration looks like. So instead of having all of those different resources that we saw previously, we have one central place that acts as a proxy and gateway to access all of the resources in your infrastructure. And all of the users go through Teleports. And this provides both the connectivity and then also the authentication and authorization gateway to say, "This user can get access to these resources at certain times."

And as I go through this webinar, you'll see some of the things that we put in place to also follow best practices, such as the principle of least privilege. And so yeah, all access, all infrastructure access for our single login tied to a user's identity. Okay, so let's go into the demo. So this first demo, I'm going to cover just auditing and access. And I'm going to come back to sharing my entire screen here so I can show you what's happening. By the way, I am keeping an eye on this chat window here, so please feel free to leave me a message if anyone's interested. Okay, so I'm going to start off, like any good day, with my terminal.

And so I'm going to start off by logging into Teleport. If I make this a little bit bigger, you can see I am logging into a proxy which I'm hosting with my username, Ben Arent, which is my name, and I'm using GitHub. So let's open this. You will see now I have-- since I'm already authenticated with GitHub, my login has been successful. And within my config here, there's a range of options that happened. So you can see that I have my cluster. I have these roles. I have these logins. And so you might see I can log in this principle EC2 user. I have Kubernetes, and I have a few other extensions tied on to my account. But I'm going to start off by accessing a server. And so I'm going to do Ubuntu and then on the Findlay host. And there I am.

So now I have logged into Teleport. I now have access to the Findlay service. And now I have access, so I can-- this is a pretty small box, two hosts. And then I have my Teleport service and everything else running here, so I'm going to exit this one. And one of the benefits of using Teleport to consolidate everything is I can quickly go from a zero-trust method of accessing a server to accessing Kubernetes clusters. So I'm going to switch up my workflow, log into the cookie host, pods, pods, get pods. The only thing is me changing context from servers. And you see I have one shell pod running here, and I'm going to exec into it. And then here I have access to the pod. And so I'm going to access my endpoint.

And so now I've quickly just stayed within terminal. I have access to a server and a Kubernetes cluster. And so what I'm going to show you next is the audit log, which is available to people using Teleport. So let me come in and log into Teleport. As you see here, I also have a web login. I'm going to be using GitHub. And this is an important tool for the fundamentals of Teleport, is using a external identity provider that is the source of truth for identity of everyone logging into your cluster. And like you can see here that, along with the CLI experience that I showed to start off with, we also have a full web UI. And there's certain resources, such as Windows hosts, which can only be accessed through the web UI. So if I come to management here, depending upon your role, we have the audit log of the actions.

And so you can see here that my user, I have done a few things. So I started a session on Findlay, and then I also did some actions of getting pods on the cookie cluster. And so these were the two resources you just saw on the access. These logs are all JSON formats that you can export to a SIEM solution. You can see there's sometimes more information here about the groups and the user. One thing that's very helpful here is that you can see I logged in as Ben Arent. But I adopted the system masters group which, for people who are familiar with Kubernetes, is also a bit of a anti-pattern. And we'll sort of go through a little bit more into why this is a bad idea. But this provides a good level of context and visibility. And another benefit of Teleport is it also records a full playback of the session. So you can see here I'm running the [HT?] command.

You can pause this. And you get a little bit more context about, okay, what exactly was happening. And these are the full recordings of what happened, both for the session that I had and then also for the kubectl exec. So you can see this is the Docker endpoint that I showed the example for. And so very quickly, you can see, even if someone's performing some action, I've taken that problem of all these different resources and all the different logs and consolidated it in one place. Another problem that you might run into is there are certain commands that people may run on resources which you may not get full understanding of what's happening. And I'm going to show you on this host here that I have enhanced session recording turned on. And so I'll just do LS, [nothing?] here.

And I have one command here which is an interesting echo of this Base64 encoded string and a command. And once I've executed this, it's sort of done something kind of interesting. It's gone to this URL, and something interesting has happened. And I think this is hard to say if you saw this in a session recording, what exactly happened. But by turning on Teleport enhanced session recording, we can also get visibility into what happened here. So we'll exit this session, and we're going to come back to our management console. And you can see here that I did a clear console. And let me come back here. Where is it? We have the EBPF session. Actually, it should show up. Okay, let me just run this again because it should show our network connectivity.

We got the Kat [inaudible]. Okay, so we can access Google. We can write command. We'll exit. Sometimes, all of the logs become aggregated. Okay, I'm seeing some questions come in here. I'm just going to go back to my example. You can see that I have the session here. You can see the program has been executed. But I don't know where my network connectivity-- it looks like the demo gods weren't as kind for me today. It should also show network connectivity. I may have broken my demo cluster in the setup. But you can see this also provides a little bit more visibility about what's happening during that session. And like I mentioned, Teleport can be used to consolidate a range of resources. You can use it for your Windows hosts.

And what you notice there, all of the login, there was no passwords. It uses a smart key interface, hello webinar, which is also recorded. You can access your internal apps, for example, Grafana or other internal apps that you have, all through. If you see here, we have grafana.teleport.asteroid.earth. And so it's all protected through the Teleport infrastructure, so it really provides easy access. And then next up, as far as the web UI, I want to show AWS. And so talking about all those different options that we showed, here I have AWS Management Console added into Teleport. And I have one IAM role which has limited the scope of what you can access. I have a GUI CloudWatch full access here. And so this IAM role-- I'm assuming you can see here in the top that I've assumed this role.

But this role only lets me view CloudWatch alerts. So you can see I have one here, which is my read capacity. It's going over. But if I was to go into EC2 here, it's not going to show me all of the actions because I don't have full permissions to do so. And as with everything else, all of this is also audited. So you can see I've connected to the AWS Management Console. You can see I have the Windows session. We also record Windows sessions as well. So you can see here that we have the full session recordings as well for Kubernetes, Windows, and server access. And just to close out my example, the last one I wanted to show was database. And you can see I've added a range of databases here into my Teleport cluster.

We have a huge list of integrations, and you can view them in our goteleport.com/integrations. And we also support both -native and on-prem databases. I'm going to be showing AWS-hosted Postgres here, and so I'm going to DB login. I'm logging in as a shared user here. But because we're using Teleport, it's going to link all of my activity as Ben Arent from my identity from my GitHub identity provider into this DB shared user. And I'm logging into the main Postgres database. And then lastly, Aurora is the name of the database that I've added in Teleport itself. And so you say the connection information has been saved. We can do DB connect.

And you can see the table. I have one table here and then the owner's SRE. I can exit. And to close the loop on our audit trail, you can also see that I did a database connectivity. I executed a query. One thing that's also unique about Teleport, because all of these are at the protocol level, the slash DT under the hood actually runs this command. And so you also get a lot more visibility into what commands are being executed on your database. And you can see I entered the session. You'll note some of our services in your databases. We just provide the audit log, and some have full session recordings. I'm going to stop sharing and just have a quick look at some questions and go back to my slides.

Can we expect some filtering improvements on the audit log UI? We've been [exerted for?] several queries a day, tens of thousand events. Oh, thank you, [for everyone?] sharing this one, especially important for more services. Yes, this is hot on our roadmap, Richard. Especially, if you are currently using Teleport on AWS, you can use our Athena backend, which provides a lot more capabilities for searching. This is currently using our Athena backend. And I'm going to show you access monitoring and some tools that you can use to run specific queries on lots of events coming up. So probably in like five more minutes, I'll get to that. So now I'm going to come back to sharing my slides. Okay, so we covered a lot there. So we covered in maybe eight minutes everything from how you can replace all of the above with Teleport.

So we covered replacing SSH keys with short-lived certificates. And you didn't even necessarily see this under the hood, but that's kind of what's happening. And along with this, you get the JSON-based audit log, the interactive sessions, the EPPF-backed advanced session recording. The Postgres password, we've also replaced this with X.509 certificates. [inaudible] provided the zero-trust connectivity. One thing that you didn't necessarily see there that we had, my database doesn't have public access. And so I run sort of a sidecar service that provides the connectivity to that host. And so I don't have to worry about any jump boxes or bastions. And we cover the protocol-level requests for AWS users. We have the option of sharing a IAM role. I showed the example there of AWS Management Console. The same thing also applies to the CLI if you want to use examples such as Terraform and use Teleport as well.

And then lastly, I also shared this at the beginning, was using a shared Kubernetes role among the team and replacing kubectl login. We also get the benefit of a JSON-based audit log and interactive exec session recordings. Okay, so I have a quick poll for everybody here. So we have, which of the following challenges have you faced in infrastructure auditing? And I'm going to just open the poll and share it. So this is the time to see what challenges everyone is facing with their audit logging. The poll is next to the chat window. So one person's found it. Yeah, they're coming in now.

All right, looks like difficulty in tracking user activities is on the up, followed by trouble consolidating access and then consistent. So yeah, I'll hopefully dive a little bit more into tracking user activities in my next sort of demo coming up. So thanks, everybody. I'm going to stop. Close the poll. Oh, they're still coming in. Close the poll and stop sharing it and come back into my slides here. And so one thing that we've seen at Teleport, and this has also been supported by CrowdStrike, is the attacks on people's infrastructure is also shifting. But actually, most attacks also happen because people are just using valid credentials.

And for a long time, it was mainly malware that was gaining access. But now, people are just using valid credentials from users. And we've seen this as a challenge to protect those identities. It's become much more difficult. And we see, for example, trying to reduce the attack surface of how many people get access to those sources at a certain time followed by monitoring the access patterns, this becomes extremely difficult to be able to see what are the access patterns. What are the longstanding privileges? How can you clean up when somebody sort of leaves your organization, as they join? Over time, do they change team? And then lastly, the last challenge is how do we respond to threats. For example, if someone did have malicious access to their infrastructure, how do you make sure that you can respond appropriately?

Also, of course, all of the user activities, so I know that was top in the challenge that people are facing. If you're tracking a user, how do you make sure that that user, he may not have access to SSH anymore, but maybe he has access to the database? How can you make sure to lock, pause, and provide an incident response quickly? And to solve this, we've come up with a range of features around identity governance and security to eliminate a lot of the weak access patterns that we see, improve access reviews, providing just-in-time access, and some few other benefits of automatic access provisioning, identity logging. I think, to show this, the best way is to go back to my demo and provide an example. So yeah, let me dive into my identity governance and security demo.

And I'm going to share my whole-- I shared tab actually. Let me just open an incognito window here. Actually, you know what? I'm going to share my whole screen because I'm going to go between things. Okay, so let me make this a little bit bigger for everybody. Okay, so I have an incognito window. And I'm going to start my day as user Alice. And so Alice has the availability to see all these resources, but she doesn't have access to access everything. And so most of the flow of Alice is to make access requests. And so Alice starts her day with very minimal privileges, and she's going to use the access request flow to log into a few servers to get her job done for the day. And so she needs to get access to the cockroach server, the cookie server, our cookies Kubernetes cluster, and Grafana dashboard.

And so she needs these resources to get her job done. And so she's going to start by making an access request that combines all of these three roles into a custom role. So she has one role called access. She has the option to provide reviewers, which could be her manager. Let's see. I'll add myself. She has the option for the maximum duration of this role. She can also set an expiry of this request. So since her boss is in a different zone, she gets four hours and say, "I need to debug prod. Fix the error." And then request reason is a very important audit flow as well to know when someone got access or requested access. What was their reason for doing so to start off with? And then if you have an incident, for example, you can say, "Hey, Alice only had access for a 11-hour period, and she needed to perform this action."

So I have sent the request off for these three resources. And as her manager, I'm not always in Teleport. So I am going to open up my Slack room here. And in my Slack room here, you can see I have a new role request from Alice to access these resources. And then, here we have our error message saying I need to debug the production service. So I'm going to copy this. Here I've shown Slack, but Teleport also supports a range of other services. We also have an API. You can use Jira or Discord. There's a whole range of options that you can have. And so as Alice's manager here, I can see that she has made the request to these three resources. And you'll see here, for people who are new to Teleport, these are the options. So I can reject her request. I can approve short-term access. Or we also have a new addition of approving long-term access via access lists.

We've created access lists to provide a better solution for teams that need much longer access but also need auditing. So for this example, I'm going to approve Alice into our freelancers group, who's going to help us with DevOps. And so this has the benefit that I now know that Alice needs access to these resources. I've approved them. We have the visibility into her access. And I'm going to say, "Please go ahead. You now have access." So we've come through. We've seen that we've promoted her request to a long-term list. And if I come back to my incognito window here, you see that I have now been promoted.

And so one thing that Alice needs to do now is she just needs to re-log in. Oh, I'm not quite sure what's happened. Oh, okay, just my fingers are not behaving itself today. And so yeah, so we've been promoted now that we have access to all these resources. And what was it? One of them was CockroachDB. And here we actually have two servers. I have a self-hosted, and I have the instance itself. I can exit. And then, as a manager of Alice, I've come back in here. We can see the audit log of Alice's activities. And then, also, we have a list of information. So we can see Alice also has other audit events around her search for roles and users as well.

You can also see another benefit of Teleport is where you also say, "Hey, the local login failed," since my fat fingers are not getting the password. And so sometimes, this is also important information. You could use this. Say, "Hey, someone maybe has phished Alice's credentials, and there's four failed logins." After a period of time, Teleport does lock out that user. But that can be a helpful information to say what's happening with Alice. So now, if I come back to management here, we'll see that we have access lists. And so this is a new addition in Teleport 14. You can say that we are offering this in preview. It may become limited in future releases. And one benefit of our access lists is you can see a full overview. So I have two members, Alice and Bob. I'm the owner, and they have access to this role.

And we also have a built-in audit capability that you can run at your period of time. And this helps a lot with certain compliance frameworks. And you also have reviews. First of the month, you just come in here and say, "Hey, is Alice still on the freelancers team? Does she still need access to these systems?" And we believe that this greatly reduces the principle of least privilege and possible surface area. And let's say, in the terrible example that Alice's laptop or account is compromised, we have an addition to provide session or identity locks. So in the case of Alice, we can join both Alice's machine and her trusted device. And we can provide a lock. So we can say, "Hey, locking user for 10 minutes [inaudible]," 10 minutes.

And so now, if I come back to Alice's user, you can see that the access has been denied because I've just provided a 10-minute lock for this user. And so we believe this sort of closed the loop on identity security and governance. Let me come back to my deck here. And okay, so I've covered weak access, regular access reviews, just-in-time access requests, automatic user provisioning. I've sort of showed this in a few places, but there's a few other ways in which you can use this. For example, you can use Teleport to automatically create user directories on the fly, create database users. And that's also supported with AWS native ones. And when we have the identity login as well.

Oh, let's review access. So we have here this sessions with weak security. So this is another new edition, a part of our identity governance and security launch. And I believe Richard asked a question around how do you query this large amount of information. And so within the identity governance and security, we have a access monitoring report. Our query editor lets you run a range of queries. I'm going to just look at our built-in reports for privileged access. I'll run a 90-day query. To run this, you can run this self-hosted. You do need to run our Athena backend, and this is currently running a query on our Athena backend. Since I've put in 90 days, this just might take a few more minutes.

You can see here databases with weak security. This is the one I just had this morning, which means it has no access requests or MFA. MFA is another addition that you can add to Teleport that we highly recommend, along with using identity provider. You can enforce people to always tap a hardware token. We have sessions with weak security. So for example, I've had a lot of weak sessions, Kubernetes calls. These are ones which have shared weak security. We have databases, kubectl execs, long-lived certificates both for users and joint tokens. So I was adding servers yesterday with very long tokens. It can help identify these patterns. And we have a query editor here.

I recently wrote a blog post, which was sort of a tongue-in-cheek example of people accidentally hiring North Korean IT workers. And I have some access patterns here of how you can detect, for example, a user with a different IP address which-- let me come back to access monitoring. And it's just the Athena SQL interface. And so we're looking at certificates that have been created through their unique IP address just to make sure that, if someone was logging in with many hundreds of IP addresses, there might be something interesting happening there. It looks like everyone's logging in from the same place. Nice, 90 days. And so this makes it very easy for you to query a large amount of data.

Okay, coming back to my slide, yep. It's going to shout out to Eric. So Elastic have fully implemented and rolled out access requests. And I think one thing I really like here is it's also rolled out more freedom and innovation by removing root access. And so the combination, we believe, of access lists and access request [inaudible] actually provides a lot more flexibility and a lot more speed for team and sort of the secure sandbox that you can get access to. And the less rigidity of using root access, it makes it much easier. And so access lists, I think we covered all of these in my example here. But I think we come to a next question of who has access to what and why. It's an important question. So we just announced this last week at our user conference, the Teleport access graph.

This is going to be a new addition in Teleport starting in November. It lets you model, test, and review access of all infrastructure and resources. Since I am kind of coming up time, I'm probably going to go dive straight into the demo here of the access graph. And we built access graph as a mechanism to better understand an organization's team and access pattern. So for example, if I have myself, you can see that I only have access to this one resource. And this unified pattern and access graph lets us better understand, okay, you've set up tracking users' activities, but also which users and roles have you defined access as an ability, a snapshot in time. Say, "Hey, this user can access these resources. Maybe we should change the access or update our RBAC to follow the best practices."

And so yes, we support user and user groups, resources to resource groups, and then users access actions on staging. For example, we allow-- if you want visibility into who has sort of SSH access, Kubernetes access, or database access, this all has those capabilities. So I've sort of flown a little bit through tag due to time, but it will be available on Teleport Cloud on November 25th. And then access monitoring access lists are available in Teleport 14. Before I dive into Q&A, I have one last poll for everybody. I'm going to go share it. Oh, let me open it. Which features are you interested to try based upon the demos today?

I know I've covered a lot of content today. I think this is the most amount of demos that I've shared. So you'll see polls is next to the chat tab. Give everyone a minute to find it. Hold on. Maybe there's difficulties. Okay, maybe now. Okay, I think I had to reshare it. And then, if I get more on the access graph, I'll definitely do a little bit more of a demo towards the end of the capabilities. Okay, I'll give it another minute or so. It looks like we're winning between Teleport access graph and access requests with ChatOps integration.

And it looks like the audit log is getting no love this morning, unfortunately. But it's sort of a take-and-give. And so I'm glad that it's getting zero votes. Okay, so it looks like the strong winner is Teleport access graph. Maybe I'll just dive into Q&A, and I can answer questions as they come up. So let me stop sharing - I believe it's still open - and come into Q&A. So let me start off with some of these questions. Let me go with Richard. So I think this one has been answered, hopefully for you, Richard, the filtering improvements in the UI.

Audit log UI will stay the same. But now we have the access monitoring view that you can run your logs. I believe there's also an API that you can run queries itself. The one caveat is you do need to be running our Athena backend. And so I think it probably comes to my next question, is will tag be available for self-hosted? I believe it will be, but likely in the beginning of next year. I also want to say that it will be an enterprise-only feature. But if you're interested, we're also looking for people to help deploy this. So reach out to us on our sales team, and we would love to also look for a design partner as we roll this out. We've had lots of interesting feedback and questions for this.

Question from Jose, is Teleport moving to the identity governance area? Yes, I would say. Probably want to learn more about identity governance and security would be go to our page on goteleport.com/igs. I actually believe it's in the media example. This one here, I've seen this question [inaudible] three or four times. Is it possible to mark sensitive information in the audit log? It is not currently possible to mark sensitive information in the audit log. What we would recommend doing is limiting who has access to the information in RBAC. And so one of the RBAC examples I can give is, for example, you can say an engineer can look at their audit log, but they can't look at the other team's audit log. But there might be cases in which you could potentially leak a secret key or a token.

If this goes into the Teleport audit log or it goes into your SIEM, you've already run into the problems of secret leakage that you want to probably alert and see what's happening. And so we don't really have the masking capabilities. I think we're just trying to provide the tooling to alert a monitor on what is happening. [inaudible] on the playback recordings, can they trigger an alert based on what occurs in the session? Yeah, this would be the inclusion of using our enhanced session recording with a playback of the session. You might want to do-- example, if it's a really long session recording. But if you want to say, "Hey, someone is trying to RMRF a folder," if you use the enhanced session recording and alerting, that would be the example that you'd link back to. And then you say, "Hey, we saw this action happening on this host. Here's the session recording. Go and investigate further."

But there are interesting possibilities here, like the combination of enhanced session recording and automated locking. You might say, "Hey, if someone runs this command on a well-known malware site three times, lock the user for an hour to investigate further." Okay, so I think that one has been answered. Please feel free to send in more questions. Any more in here? Okay, this is an interesting one. Will behavior analysis be built on top of tag? Yeah, this is an interesting one. One piece of feedback I heard from people at our user conference was tag is like a slice in time. So you know for this specific day, I can come back to it.

For this specific day, people have access to these resources. So we see Ryan as a requester and an auditor. They don't have access to different things. But if you were to lock a user or change their access over time, how does the access graph-- does the access graph have knowledge of it? We all have all that information there. It's something that we haven't fully built and integrated yet. But I think that's areas that we're also exploring to take our Teleport access graph, which is one of the reasons that we're launching it sort of early on cloud, to get early feedback about how people plan to use it. And then, also, you can also do the reverse. So you say, "Hey, this instance also requires trusted devices," which is another edition of device trust. And so you can go back from also the user or through the resource to see, okay, everyone has access apart from J Bob. J Bob's like the intern, for example.

Okay. Coming back to the questions here, all right. I think it looks like all the questions have been answered. Just want to wrap things up. So next steps, we start off with-- a lot of this information about auditing comes from our book, Identity-Native Infrastructure Access Management. We have a full chapter on building good auditing systems for infrastructure. There is a link there. I believe Kat could probably share it too. You can download this ebook for free from our website. If you want to try Teleport, you can try it for 14 days free with our Teleport team trial. Or if you want to download the open-source edition, you can get started. Check us out on GitHub. Teleport is a open-source open-core company, always appreciate a star. And my one last request - okay, so we've done questions - is just I'm going to launch a survey now. It's just three questions.

I believe it should be launched. This survey will just help us improve our webinars and our presentations, so really appreciate the feedback. Let me just check the chat. Oh, there's one more question in the chat, I hear. I believe there's one question. When I use kubectl exec, only session recordings is available but not the command executed in the session. How do I get session commands in the audit logs? This, I think, will be our enhanced session recording for Kubernetes. I actually don't know the status of this currently. I know it was being worked on for a period of time. I will get back to you and find the GitHub issue. Like everything, Teleport is an open-core company, so you can probably check the status on GitHub. But I can follow up with you too.

Okay. So I think the survey's gone. I think we've done the polls, and then I think that's everything. So I know we've had about 30 people today. I'd like to thank everyone today for coming through this whirlwind demo and tour of Teleport and the audit log. If you want to follow up, more questions, I'd recommend joining our community Slack, which is open to everybody. We are happy to answer your questions. It's available here on goteleport.com/communityslack. Thanks again, and everyone have a great day and a happy Halloween if you celebrate. Thanks for joining us today.