Securing EKS with Teleport!

Securing EKS with Teleport! - overview

Managing access to EKS clusters can be fraught with peril if not done correctly. By leveraging Teleport to manage EKS access, you reduce your potential exposure to attacks, add audit trails, and even achieve compliance! Watch this session with Chintan Sanghavi and Nivathan Somasundharam, where they walk you through how to:

- Manage access to EKS with your SSO provider
- Leverage granular RBAC controls to control and limit access to specific clusters and even pods
- Showcase K8s recording for compliance and auditing

Key topics on Securing EKS with Teleport!

- With Teleport, every connection across your global infrastructure passes through Teleport’s Identity-Aware Access Proxy where it is authenticated and authorized based on human or machine identity.
- Identity-native is comprised of two things: One is secretless, and the other Zero Trust. Teleport is a combination of both these concepts.
- The AWS Shared Responsibility Model for EKS means that when using Amazon EKS, security and compliance are considered shared responsibilities.
- In the shared responsibility model, AWS is responsible for security “of” the cloud whereas you, the customer, are responsible for security “in” the cloud.
- You can use Teleport to manage access to EKS with your SSO provider and can leverage granular RBAC controls to control and limit access to specific clusters and even pods.
- Teleport has a capability where you can audit user behavior, find out who is doing what, and then tune your policies according to that.

Expanding your knowledge on Securing EKS with Teleport!

- Teleport Kubernetes Access Guide

Learn more about Securing EKS with Teleport!

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

Transcript - Securing EKS with Teleport!
(The transcript of the session)

Nivathan: 00:00:05.378 Hello. Hello, everyone.

Chintan: 00:00:08.144 Hello, everyone. Let's wait for few more minutes till everyone joins, and then we can start.

[silence]

Nivathan: 00:00:41.483 Feel free to drop in where you are from so that we can know where everyone is from.

[silence]

Chintan: 00:01:03.558 Yeah. [Hey, there. Hey [inaudible].

Nivathan: 00:01:11.114 Hello. Spain, New York, D.C., amazing. We can see from all around the world.

Chintan: 00:01:31.059 Wow. Portugal. So there's somebody from Spain, somebody from Portugal. We have a lot of people from the US. Nice.

[silence]

Nivathan: 00:02:02.426 Columbia. Nice.

Chintan: 00:02:05.866 So we have somebody from Cairo, Egypt as well.

Nivathan: 00:02:09.386 Awesome.

Chintan: 00:02:09.974 [inaudible] Brazil. It's truly global. And we see people from Mexico, Brazil, Egypt, Portugal, Spain. Awesome.

[silence]

Nivathan: 00:02:48.738 Let's wait for 30 more seconds before we get started. [inaudible] wants to join. Great.

[silence]

Nivathan: 00:03:31.680 Okay. Let's get started. Greetings, everyone. Thank you for joining today's webinar, Securing EKS with Teleport. I'm Nivathan Somasundharam. I'm an Implementation Engineer at Teleport. I've been here for almost a year. I live in San Jose, California. And today, I'm partnering with Chintan on this webinar. I'll let Chintan introduce himself.

Chintan: 00:04:02.698 So thanks, Nivathan. Hey, guys. This is Chintan Sanghavi. I'm a Partner Solutions Architect. And as a part of this role, I work with many ISV solution providers, right, and help them to integrate with various AWS services, right, and help them in creating the product and the roadmap and other things. I joined AWS around three years ago. And prior to that, I was working with many investment banks and the banking and financial services companies and helping them to build products. So that's my background. Nice to meet all of you guys.

Webinar agenda

Nivathan: 00:04:37.570 Nice. Thanks, Chintan. So here's a quick agenda for today's webinar. Let's start with introduction to Teleport, and then Chintan will go over AWS Shared Responsibility Model in respect to EKS. Then we can cover some challenges involved in delegating access to EKS and also see how to solve them with Teleport. And finally, I can share a good demo about Teleport with EKS clusters. And by that, we can do some Q&A at the end. So here is how engineers access infrastructure today. We all know that secured infrastructure access is hard. As an engineer, we want to access various pieces of infrastructure like Kubernetes clusters, servers, Windows machines, databases, CI/CD systems. And how we all access those resources is a good question. It's either through a bastion VPN or any kind of security like passwords, SSH keys, and this list just goes on. So everywhere, there is a dependency for either a secret or a VPN-like perimeter security, always in this infra access. If a single piece of this infrastructure gets compromised, the blast radius will be huge.

Teleport identity-native infrastructure access

Nivathan: 00:06:18.227 To address this issue, let's see how Teleport solves them. You all can see how better it is now. I'm going to introduce you to one of those rare times when a security solution makes it faster for engineers to do their job then with increasing security at the same time. Many organizations we speak with have implemented security solutions, but developers didn't adopt. Why? Because they are a pain to use, and developers are smart enough to get around them. If you want someone to adopt a security solution, it has to be dead simple. And that's what Teleport has done with identity-native infrastructure access. Let's get right into it. Identity-native is comprised of two things: One is secretless, the other one is Zero Trust. So Teleport is a combination of both these concepts. So let's get into secretless first. So there are passwords which are always being stolen or fished. So let's try to avoid legacy PAM systems or key vaults to manage passwords. Developers or engineers have to fight to get access to systems. Let's try to avoid that by eliminating secrets. And the second one is identity native — second part of identity native is Zero Trust that aligns with Google's BeyondCorp initiative for securing their own infrastructure.

Nivathan: 00:08:07.134 Zero Trust completely throws out an idea of access between humans and machines based on identity. The primary component of Zero Trust is an internet-facing proxy that controls access between resources from any location and without legacy VPN kind of solutions. So this prevents any risk involved with access. So let's see how identity-native infrastructure works in respect to Teleport. Here is the high-level architecture diagram of Teleport. Identity-native proxy sits in between users and missions on one side. On the other side, there are infrastructure resources like Kubernetes clusters, server, databases, windows machines, application, CI/CD systems, all that. Teleport itself is a certificate authority. Whenever an engineer logs into Teleport proxy by approving his or her identity, they are provided with a short-lived x.509 certificate so that they can access the cluster. So by accessing the cluster, based on roles, Teleport decides whether they can access a piece of infrastructure or not. Teleport can also be integrated with SSO providers like Okta, Azure AD, GitHub, and you can still maintain your SSL provider itself as an identity source. Teleport also has fine-grained RBAC controls. So you can leverage that for customizing roles and stuff inside Teleport.

Nivathan: 00:09:58.605 And everything is audited in the form of audit logs, and you can integrate that with any SIEM integration and send them to something like Elasticsearch. And users can also request access through Teleport, and you can integrate your workflow like Slack, Jira, PagerDuty, and all those. Teleport integrates also well with wide range of AWS resources, and also, we are platform agnostic. Teleport can integrate well with all your day-to-day workflows, and you can connect 170+ cloud-based resources right now with Teleport. And finally, Teleport is open-source, and this speaks to our DNA. If you compare us with legacy solutions, the key differences are Teleport is user-friendly for developers, and developers love Teleport. At Teleport, we have created a solution from the ground up with developers, DevOps engineers, and SREs in mind. Our founding team came from this world and is very experienced in this space and saw the problems firsthand. This is what truly makes us different and why being open source is so important for us. Now, I'll pass onto Chintan to discuss AWS Shared Responsibility Model with EKS.

AWS Shared Responsibility Model with EKS

Chintan: 00:11:46.209 Thanks. Thanks a lot, Nivathan. But then, before we go ahead, can we do a poll on this? I mean — how many of you are actually currently a Teleporter? And we have created a poll here. So if you don't mind, can you go and let us know what is your view? I mean — whether you are using Teleport or not. And let's pause maybe for two, three minutes, and then once the poll is completed, we can start with the Shared Responsibility Model and EKS. So Kat, if you don't mind, can you start the poll?

[silence]

Chintan: 00:12:40.283 Awesome. So we have so many people already using Teleport, which is great, and we have some people not using Teleport. Since I see some words, where people are saying, they are using something similar as well. I mean — if you don't mind — can you let us know, in chat, what other products and what solution are you using for this?

[silence]

Chintan: 00:13:46.111 Awesome. Awesome. Cool. Nice. Awesome. So we have so many people using already Teleport, a lot of people not using the Teleport. Okay. Cool. So I think we can start. And as Nivathan mentioned, Teleport can actually help a lot in identity and access management and providing a better control on top of EKS, right? So in the next few slides, I'm going to talk about the AWS Shared Responsibility Model and what are the responsibilities, what are the security concerns that we should be considering as a part of the EKS development? Okay. So Nivathan, can you go to the next slide? Cool. So before we go into the shared responsibility model, let's see, what are the services or what are the container services available on AWS, right? So mainly, on orchestration perspective, AWS provides two services. One is EKS, which we already know, which is based on Kubernetes. Another is the Elastic Container Service — what we call an ECS. Now, this is mainly for the orchestration where you can deploy this entire container workload on that. Now, you can run EKS in two different types of compute engines. You can use your EC2 instances, or you can create EC2 instances, and then run Kubernetes on top of it. This is required when you want to manage the overall infrastructure and you want to take care of the underlying OSes and other things, right? And we have a serverless offering as well, which is AWS Fargate. In that scenario, the developer and the companies need not have to worry about the underlying infrastructure. And they can use the serverless infrastructure complete data.

Chintan: 00:15:37.155 And so these are the ways we have — these are the different types of services we have in AWS. For this webinar perspective, we are going to focus on EKS and EC2, and that's where our main focus is going to be. Okay. Nivathan, can we go to the next slide, please? Cool. So this is our Shared Responsibility Model. And as I mentioned, it's a shared responsibility, right? So when you have an EKS cluster, AWS will be responsible for the overall infrastructure, right, where we will take care of the data center, we will take care of the overall underlying infrastructure, where you will run your application. And specifically for the EKS perspective, we take care of the entire control plane, right? And we know that, okay, developing or designing or architecting this entire control plane is very difficult and time consuming. And AWS will be responsible for that. And AWS will ensure that the control plane is very secure. In addition to that, if there are any other things like say, for example, scheduler or etcd, AWS will be responsible for that. And you, as a customer, will be responsible mainly for whatever you develop on top of EKS, right? So it can be your entire customer data, whatever data you are storing, you will be responsible for your VPC configurations and how you create vPCs, whether you will deploy your workload on the public subnet or private subnet and other things. So you'll be responsible for the overall security of it. And in addition to that, you also will be responsible for who is going to access and what is the level of access people or your developer will have. I mean, that is another level of security, and you'll be responsible for that.

Chintan: 00:17:22.975 Yes, AWS will provide a lot of services, which will help you streamline your responsibility part of it. And in the next few slides, I'll go little more deep into that. Okay. And then this slide shows the self-managed nodes and workers where you will be responsible for the overall worker nodes. In the next slide — Nivathan. And the next slide is more about the managed nodes, and what we call it is the managed node, where AWS will be responsible for underlying nodes as well, right? So anything related to operating systems and any IAM configurations, [inaudible] list will be responsible for that. As you can see, the responsibility of AWS, when you go from non-self-managed node to managed node — it increases a little bit. And when you go to even the Fargate, AWS will be responsible for even the VPC configuration as well, right, where you don't have to worry about the overall security and the scaling and other part of it, right? So that's how the AWS responsibility will change based on the type of the installation you do, a type of the deployment you do. Okay. Nivathan, can we go to the next slide? Cool. And so these are the few things related to security, and I have categorized the security-related issues into five or six different categories, right? And first is related to identity and access management. So as we know, when you have many developers working on it, they may require different types of permissions, right? Your EKS containers may have to connect to various kinds of services and other privileges. And that's where identity and access management becomes really important. So within this umbrella of identity and access management, AWS provides a way to create roles, create policies and other things.

Chintan: 00:19:20.576 And you can use these services to create the policy in such a way that it has a certain kind of permissions, and people are not able to perform any task, which is not supposed to be done, right? So that becomes really important. In this webinar, we'll focus more on identity and access management, and we'll see how Teleport and AWS can make it very streamlined, very simple for the customers to use identity and access management along with Teleport. Now, in addition to identity and access management, network security, infrastructure security also becomes really important for EKS. And for infrastructure security and network security perspective, yeah, how you design your VPC, how you create subnets — it becomes really important, right? And the various security groups and rules you apply, that becomes really important, right? So we have seen that sometimes customer will deploy everything in one particular region and then one particular availability zone. Sometimes, you run in public subnet, and these are not the right practices of deploying or developing any products and application on EKS. Generally, our recommendation is to deploy it into multiple availability zones. And depending on your type of requirements, sometimes, you may need the public access. Sometimes, you may not need public subnets. And you can deploy these entire EKS clusters in the private subnet or mix of private and public subnet depending on the type of the user. And for the data encryption, so now since you are responsible for the data, it is going to become really important, and seeing how you secure your data and who has access to that data and other things. And AWS provides many services in this particular space, right? So again, identity and access management becomes very important, where you control who has an access to a certain kind of data.

Chintan: 00:21:19.137 But then you also need to understand whether you have sensitive data or not. And that's where AWS provides services like Amazon Macie, which will help you to understand whether you have confidential information or PII information in it or not. And you can use Macie to go and find out and scan your S3 repository and find out whether you have confidential information or not and then provide the right level of data security. And then again, secret management is also very important, where you store your confidential access keys or some roles and some passwords, etc., into the secret management. Now, apart from this, overall, in general, about the detective controls and the runtime security, we have many services like an Inspector or a GuardDuty or WAF, which is a Web Application Firewall. You can use these services to protect your underlying workload. You can make sure that your web access is very secure and your runtime is pretty secure. So these are the kind of services we have. After this particular webinar, I'm going to send maybe an email or something which will help you to understand what are the different services available and how can you leverage some of the services, okay? Nivathan, can we go to the next slide? Now, let's just focus only on identity and access management. As I mentioned, AWS provides many services. I mean — you can create roles. You can create various users and policies, etc. Sometimes, we have seen that customers — they don't understand the importance of the role, and they provide individual access to every developer. And that becomes really challenging to scale.

Identity and access management (IAM)

Chintan: 00:23:12.542 And our recommendation is to create a role, assign this role to various users, and then assign policies to this role. And this way, you can scale it very effectively. You can have multiple users coming in. You can assign this role to the same user or similar set of users, and then assign permissions according to that. So you don't have to go to individual user and assign permissions and policies. Instead of that, you can create a role and other things. Secondly, how do you create a policy and the role and what kind of access will it have? That becomes really important. And that's where you should follow the least-privilege principle, where you create a role or you give a permission only where it is really required. Sometimes, yeah, somebody will have an access to, say, RDS database, or somebody will have an access to, say, S3 bucket or some particular [inaudible], like starting or stopping instances or something. It does assign that permission to make sure that you provide the least privileges to that particular person. Only based on whatever is required on the access given or creating policy only for required accesses. And that becomes really important. And secondly is auditing. I mean — in AWS, we have CloudTrail. You can audit all this information, whoever is trying to access a certain kind of resources. You should periodically audit all these accesses and see whether the particular person requires access or not. I mean, sometimes, we have seen that people change the department, people move to a different role, and they may not even need this access anymore. And that's where the periodic access becomes really — periodic audit becomes really important, right, where you maybe on quarterly basis, or maybe on the six months or monthly basis, you can go and see who has what kind of permission and then change it accordingly.

Chintan: 00:25:05.196 So these are the kind of guidelines we have as part of the overall EKS and making things secure. And apart from that, yes, we will do — Nivathan is going to provide more understanding on the identity and access management and how Teleport can make it very simple. We will talk more about that. Lastly, in general, how you protect your EC2 instances, whether you will have an access to the metadata or you'll have a separate account or service account created or not. Sometimes, we have seen the customer start their entire EKS clusters with the administrative privileges and very high-level privileges. So I would suggest create kind of separate service role, and then assign it to the EKS and make sure that it has only list privileges. So these are the general guidelines we have in identity and access management — to make sure that it is secure in terms of identity and access management. Okay. Can we go to the next slide, please? Cool. And these are the few challenges we have seen customers facing. I mean, it can be either managing the overall configuration or managing the overall policies and other things. Now, we'll start on the poll, and what I would like to understand is what is your view, and in your opinion, where do you see these issues. And are you facing these issues or not? And in your opinion, what is the most important issues? And then, Nivathan will do a deep dive into some of these issues and see how Teleport can elevate this. So can we start the poll? Cool. And Nivathan, if you don't mind, can we share the screen of poll tab?

Attendee poll

Nivathan: 00:26:59.652 Sure.

[silence]

Chintan: 00:27:19.331 So managing roles and policy is the highest. We are seeing the highest behavior over there. And then we also see auditing user behavior is really tricky.

Nivathan: 00:27:33.023 Nice.

[silence]

Chintan: 00:27:45.089 Awesome. So it seems managing kubeconfig files is not an issue at all for most of the people, right?

[silence]

Chintan: 00:28:07.332 And this managing IAM roles and policy becomes even more critical when you have more and more users. I mean, we have seen sometimes customers having 400, 500 instances or the nodes that are running, and then managing the permissions becomes sometimes challenging.

Nivathan: 00:28:29.135 Or you can use the behavior. Seems to be the priority number one.

Chintan: 00:28:33.082 Yes. And Teleport has a capability where you can audit user behavior as well, and you can find out who is doing what, and then you can trigger, you can tune your policies according to that. Cool. Awesome. So Nivathan, can you go through this poll, and then tap into the various capabilities of Teleport in this area?

Nivathan: 00:29:02.979 Sure. I'll start sharing my screen.

[silence]

A few challenges with native EKS access

Nivathan: 00:29:22.079 Awesome. So we already saw how the Shared Responsibility Model works with EKS. Thank you for that, Chintan. And here are some challenges. And we have also seen from the poll. The main challenges that I see is all the developers should have EKS, like AWS CLI access to get their kubeconfig files. And sometimes managing them is very tedious. And from the admin perspective, managing the IAM roles and policies is tedious, especially when they have so many clusters, so many users, and when they have different accounts that really becomes challenging. And the next one is providing elevated access. Say whenever a user wants elevated access for a certain environment or for a production environment or any critical infrastructure, it again requires the admins to go and change the roles and policies, to grant access for that. And as we all mentioned before, the first priority that came on the poll results was auditing. Yeah, the auditing is sometimes challenging. I can show you how Teleport helps with auditing at the next stage of this webinar and during the demo. So let's get into some of the advantages of using Teleport for EKS access and how some of the challenges are solved by using Teleport.

Advantages of using Teleport for EKS access

Nivathan: 00:31:19.654 So Teleport integrates well with SSO providers. Say you wanted to hold your identity, source of truth to be your SSO provider, our Teleport can integrate well, and you can inherit those groups or their characters from your SSO provider and convert that into Teleport roles. So you can inherit them. So that is the main advantage. And you can give fine-grained access to EKS resources. This can be in any level. It can be in a cluster level, and it can give it a namespace level. You can give as a user or group level, and then even you can give for a particular resource, just for a pod. And you can do all that with Teleport RBAC. Here comes our auditing capabilities. Teleport has two different auditing capabilities. One is audit logs. Anything that happens inside a Kubernetes cluster, all the API calls will be audited, and those logs can be transported to your preferred scene integrations, and you can query for any vulnerable actions inside Kubernetes cluster. And the second one is session recordings. So the session recordings are something like whenever a user logs into a pod and runs any commands, everything will be recorded in the form of video file format. And this could be used in future for any further compliance or any auditing.

Nivathan: 00:33:10.776 And the last one is Just-In-Time Access. As I mentioned before, Teleport can also integrate well with all your workflows like Slack, Jira, Mattermost, Teams, PagerDuty, Discord. Any of your developers, if they want any privileged access, they can create an access request from Teleport, and admin can either approve or deny it based on their request. So that comes along with it. So you don't need to change any roles and IAM permissions on the AWS side. It can be done with Teleport itself. So let's get to the interesting part, the demo. So I'm going to show demo on three things. I'm going to show them all how SSOs can be integrated with Teleport. And I'm going to show how fine granular permissions you can give for a user. And the third one, how you can leverage Teleport for access request. Let me go to my browser. So here is my browser. This is my Teleport cluster and from UI. I am going to login through my SSO now. Okay. Sharing in a different screen. Let me share. Awesome. So here is my Teleport cluster. I have logged in as an SSO user.

Demo 1

Nivathan: 00:35:09.528 Basically, you can see all the inventory of servers, application, Kubernetes, databases, and desktop applications here. And now, all we need to care about the Kubernetes clusters. So you can see we have two clusters, and you can connect to these clusters, and then I'm going to show this. So me as a user, coming from this organization and from the teams, I have been given access and all these roles. Only we are going to care about access here. So roles, access. So this is the role that I have, and I have been given access for all the Kubernetes labels and all the parts and all the namespaces and these users and also `system:masters` group. So basically, I have full admin-level access with the EKS clusters that I have. So I can show that here. So Teleport can be also accessed through CLI. So I'm going to login to Teleport.

[silence]

Nivathan: 00:37:09.581 Okay. So tsh is our binary. So using tsh binary, I log into the Teleport cluster now.

[silence]

Nivathan: 00:37:50.062 I'll go change my auth method. And this is my GitHub username. So I have been already logged in. So let me log out to show you how. So I'm logging into Teleport cluster again. So when I login to Teleport, Teleport automatically opens a browser, and I'm already logged into GitHub. So you can see I'm already — so authentication happens to GitHub now, which is my SSO provider. And you can see I have been logged in as Nivasomo, that is my username, and these are the groups I have permission to access. So let's see what are the Kubernetes clusters that I have access for. `tsh kube ls`. So these are the two Kubernetes clusters that I have access to. So let me log into the first one.

[silence]

Nivathan: 00:39:33.346 So I've logged into the Kubernetes clusters now. So basically, I don't need to manage any kubeconfig files right now. Once I'm logged in, the kubeconfig files are automatically written. And I can do `kubectl get pods` and all the namespaces. Since I'm doing it as a super admin, I can see all the pods that were running in this cluster. And I can also try to exec into the pods.

[silence]

Nivathan: 00:40:15.878 Yeah. You can see I have exec into the pods, and let me do an ls and —

[silence]

Nivathan: 00:40:49.469 — exec. So I can do anything right now without having any kubeconfig files by just logging into Teleport cluster. Now, let's go back to the UI, which is on the browser, and I can show the auditing capabilities. So you can see all the audit logs here. You can see the Kubernetes request from the user, and you can get more details over here. What was the user that I used to login? What were the Kubernetes groups that this user was assigned with? And all that information will be here. And then, you can also see there was a session recorded because I was joining a session too by using kube exec. Let's go right into it. So you can see Nivasomo with this, and it was 36 seconds. And let's play this. So I did an `ls`. And I did an `echo "welcome to webinar”` Everything will be recorded. And this is super useful for compliance. This helps a lot of security folks to see what's happening inside the Kubernetes cluster, and this helps with auditing as well.

Chintan: 00:42:30.574 Yeah. Nivathan, we have one question regarding the auditing. And the question is related to — how do we know who, or particular person, has done what kind of activities?

Nivathan: 00:42:41.954 Yeah. It's everything based on the roles and the username. If you see audit logs, when you go to the audit logs, and you can see on the detail. In this JSON, you can see the login name was Nivasomo. I mean, this whole JSON file gives all the information, who logged in, what were the roles associated with them, and what were the activities they were doing here. And these are the other activities that were going through inside the cluster.

Chintan: 00:43:25.820 Okay. Thank you.

Demo 2

Nivathan: 00:43:28.208 Awesome. So this was my first demo. And the second demo that I'm going to show is in respect to giving fine-grained access. So let's go back to the roles again. So I have this kube-access role, which is very basic. They can see only pods and production and development namespace. Last time when I showed you, you were able to see all the pods in all the namespaces. But here, I'm going to show more of the production and development namespaces. For that, I'm going to log in as a developer user, which is another user. So let me log out first. Oh, last time we used GitHub SSO to login. Now, I'm going to use a local user. And I'm going to use passwordless features from Teleport. So I have a YubiKey here. And I have integrated the YubiKey to log into Teleport. And from the browser — I have opened another browser in Incognito mode, and from the browser, you can see I can login by just —

[silence]

Nivathan: 00:45:35.446 Yeah. I have no server access. I have no application access. I have only the Kubernetes access, and only for those two namespaces, which we saw earlier, which was production and development. So let's get right into the command line and login from CLI as developer user.

[silence]

Nivathan: 00:46:13.152 You can see that username is `developer`.

[silence]

Nivathan: 00:46:36.261 Okay. My YubiKey passed, verification passed. So yeah, I'm in the cluster now. And I can show you login as `developer`.

[silence]

Nivathan: 00:47:09.344 And now, let's try to list on pods, in all the namespaces. I can only see the production. And this is all only read-only information on this namespace. Let's confirm that. Let's try to exec into the pod.

[silence]

Nivathan: 00:47:44.640 Yeah. I can't exec into the pod because I don't have permissions right now. So let's see how the Just-In-Time Access works. So let me request those privileges and try it again.

Chintan: 00:48:05.595 So Nivathan, this will be kind of a very common scenario, right, where some developers wants Just-In-Time Access, and they want some approval or something.

Nivathan: 00:48:14.084 Yeah. So basically, this is a very common scenario. Say, when developers want a privileged access to Kubernetes access, say they need to debug something inside the pod and they don't want to give those permissions all the time, so they just go try to create an access request through Teleport, and they can just — the admins can just approve or deny based on their request that comes. So I'm a `developer` now, which was opened in Incognito. So if we go to `access` — so there is a role name called `access`, which is more of elevated privileges, and you will be able to exec into the pods and do any triage whenever there is an issue going on. So during those situations, this is super useful for Just-In-Time Access. And let's add a request. We proceed to the request.

[silence]

Nivathan: 00:49:39.851 And submit this. So I have requested as a `developer` user, and somebody from the admin side should approve it or deny it. So I have this browser, where I have logged in through my GitHub username. And I have the privileges to approve or deny. And here, on the Review Requests, this can be integrated with Slack and all your workflow on the admin side. They can see the request coming in and notified Slack, PagerDuty, Discord, Mattermost, Jira, and all these kinds of workload, which is already in place.

Chintan: 00:50:31.002 And this becomes really important because sometimes we have seen that developers really want access, Just-In-Time Access, but then they are waiting for an approval, right? I mean, with this integration with Slack and other things, it becomes very easy and faster for approval.

Nivathan: 00:50:45.593 Yes. You're 100% right. Yeah. Definitely. And here, as an admin is there, I can review. So I saw the same request coming in, and I can approve, and this is for 12 hours and submit the request. So once it's approved, let's go back to the CLI. And let me try to do `tsh status`. And you can see I'm still a `developer`. So what I need to do is assume the role that I requested. `tsh request ls`, and yes, I have to — this is the request, and you can see the status is approved. And the ID. You can see here, I have only Kubernetes group developers, and I don't have any other permissions. So let me login and do —

[silence]

Q&A

Chintan: 00:52:33.437 Nivathan, we have a question on this approval. So will this appear in console, or this will be reflected in CLI as well?

Nivathan: 00:52:41.862 This can be seen through CLI as well. As I showed you before, if I log in as an admin, I can also see all the requests that are coming in.

Chintan: 00:52:53.679 Cool.

[silence]

Chintan: 00:54:16.430 So we have a question on the service account and how can you restrict the access to the service accounts. So every service account will have some policy associated with it, and using those policies, you can reduce the overall permissions given to that service account. Cool. So we have one question, Nivathan, and this is maybe on the roadmap side. Is Teleport planning to integrate with any SIEM provider?

Nivathan: 00:54:51.253 By default, Teleport can integrate with all the SIEM providers. What I have seen so far is all the third-party solutions like Elasticsearch and anything other than Elasticsearch, all the ELK-based logging tools can be used. You can integrate that with Teleport and maybe have a collector, something like Fluentd, which will pull all the audit logs and send it over to all your SIEM integrations. That gives you leverage to pass through the logs and query for any vulnerable commands that are running inside Teleport, inside the resources that have access to Teleport. It can be Kubernetes or any other infrastructure pieces as well. So I can show the role on the UI. My Wiki stopped working. So let me see here.

Nivathan: 00:56:15.813 So this is approved from the admin side, and I'll go back as a `developer`. You can see I don't have any access. So review access. I'll assume this role. So I've assumed the role now, and I can see multiple other resources now, and even with Kubernetes, I can login to pod, and I can see all the other namespaces as well. That's the Just-In-Time access. Yeah. Let's go to — so yeah. Here is the slide where you can begin. You can join our Slack community, and we have an AWS Marketplace listing, and we have a new launch of Teleport Teams. You can sign up for early access and join the early access list. And it's to just start something small. And you can go through some of our AWS use cases. And again, we are open source. You can contribute to GitHub, and the GitHub link is over here. Let's get into the Q&A.

Chintan: 00:57:58.605 We have one more question. Let me share it on screen.

[silence]

Nivathan: 00:58:21.378 Create a Teleport version of control. So I assume this will be more, yeah, Kubernetes side? May I know what is SSM?

[silence]

Nivathan: 00:58:52.508 Yeah. For controlling the container-level access, yes, you can leverage Teleport for that. It could be more specific to only a particular container. It could be just a read access. You can define [inaudible] through your roles inside the Kubernetes clusters and map those roles with the users. That could give you a capability just to give access to a particular pod with any verbs in it. You can list the pods, read level, or maybe you can give exec into the parts or write permissions to that.

[silence]

Chintan: 00:59:52.051 So Nivathan, this is the question we already answered, but then we need some more clarification. Let me put it on the screen. So this is related to — we were showing how using Teleport, somebody can understand who has access — what kind of activities he has done. So this is a follow-up to that question.

Nivathan: 01:00:21.836 So if you call — Fred has access? Okay. Say Fred has a role, and they have access. And you can see how they have logged in. You can see are they using an SSO provider to log in? Are they using local user with a YubiKey or a Touch ID to log in? So all that information will be in the audit log as well. Whenever there is a new session created, or whenever someone is logging to Teleport, all that information will be logged in the form of audit logs, which can be exported to see.

Chintan: 01:01:08.019 Cool. Awesome.

Nivathan: 01:01:17.202 Let's see.

Chintan: 01:01:19.010 I think that's it. Thanks a lot, everyone, for joining. And as Nivathan said, Teleport is listed on the Marketplace on AWS. And feel free to reach out to me as well as Nivathan and Teleport team, if you need any additional information on the AWS services or on the Teleport.

Nivathan: 01:01:43.362 Awesome. Thank you very much. Thanks for having me.

Chintan: 01:01:45.428 Thanks a lot, everyone. Thank you.

Nivathan: 01:01:48.358 Thank you.