Kubernetes Tricks & Treats: Security and Scale without the Scary Stuff

Kubernetes Tricks & Treats: Security and Scale without the Scary Stuff

Kubernetes is powerful — but let’s be honest, managing access and identities across users, clusters, kubectl sessions, RBAC rules, CI/CD pipelines, and AI agents can feel like wandering through a corn maze in the dark. Static kubeconfigs, sprawling IAM roles, and long-lived credentials are the cobwebs and skeletons cluttering your path to secure, scalable infrastructure.

This webinar will show you how to make those spooky challenges disappear. By unifying all humans, machines, and AI with cryptographic identity, you can put an end to standing privileges, enforce just-in-time access, and keep your compliance story as neat as a pumpkin on the porch. With Teleport, identity becomes the treat — delivering secure access, audit readiness, and happier developers across any cloud-native environment.

In just 30 minutes, we’ll unwrap:

• 🍬 The “tricks” of access sprawl. Clusters in multiple clouds, accounts, and environments, each with their own vaults, passwords, and VPNs…scary.
• 🧙How to “treat” your developers with a simplified access path. A single access point, with just the access they need for themselves, their CD pipelines, and their AI workloads across all clouds, networks, and DCs at any scale. Instant just-in-time approvals can allow temporary access just when it’s needed, based on criteria built for your business. No more context switching, juggling access patterns, or password rotations — just the tools needed to get the job done.
• 👻 How Teleport gives you full visibility into kubectl exec sessions, along with kernel-level session recordings for SSH/host access via eBPF — so you can turn compliance from a fright into something sweet.
• 🎃 Why an identity-first model, based on short-lived privileges and cryptographic protocols, makes Kubernetes access seamless across clusters — while improving both resilience and the developer experience.

Key topics on Kubernetes Tricks & Treats: Security and Scale without the Scary Stuff

• Organizations struggle with credential sprawl, VPN management across multiple clouds, fragmented RBAC policies, and lack of visibility when managing numerous Kubernetes clusters.
• Traditional solutions like static kubeconfigs, long-lived credentials, and legacy PAM tools create security risks and compliance blind spots.
• Teleport enables identity-based access using X.509 certificates instead of static credentials.
• The platform unifies authentication and authorization across all clusters, mapping user identities from IDPs (like Okta) to consistent RBAC policies. Engineers maintain their familiar kubectl workflows while security teams gain comprehensive audit trails.
• With Teleport, teams reduce access request times, eliminate credential rotation overhead, and achieve real-time access provisioning/deprovisioning.
• Every action ties to a verified identity, satisfying compliance requirements while improving developer experience. The solution scales to thousands of resources without architectural changes.

Expanding your knowledge on Kubernetes Tricks & Treats: Security and Scale without the Scary Stuff

• Blog - KubeCon Europe 2025: Why Identity is the New Backbone of Secure Infrastructure
• Documentation - Kubernetes Clusters
• Guide - Adding Your First Kubernetes Cluster to Teleport
• Privileged Access Management (PAM)

Transcript - Kubernetes Tricks & Treats: Security and Scale without the Scary Stuff

Introduction

Dan: Hello, hello. My name is Dan Johns. I am a Senior Solutions Engineer here at Teleport. Give me a quick moment to get my screen share going. Cool. Today we are going to talk about Kubernetes Access and how you can scale operations efficiently, ideally without adding complexity for your engineers. The goal today is to simplify Kubernetes Access. Ideally, we don’t want to have things like credential sprawl or trying to figure out compliance or anything like that. We want to have centralized visibility across lots of clusters and lots of environments. Different networks, different cloud providers, different cloud accounts. Quick agenda overview. We’re going to cover the key challenges, the modern security approaches, and how Teleport can enable that. And then we’re also going to talk about some real-world use cases that we’ve seen from prospects and customers. With Kubernetes being one of the types of resources we can protect, we are unifying identities behind humans, machines, and AI using cryptographic-based identities. So you want to put an end to standing privileges and enforce things like just-in-time access. This is what makes compliance auditors happy. Those unified identities are a bridge for removing things like standing secrets, operational toil, and all the security risk that’s associated with that. There’s a lot you can do in terms of business impact as well. Let’s jump in. So let’s talk about why you might be here today. A lot of us have dealt with things like VPNs across different cloud providers. There’s one for production AWS. There’s another one for dev and GCP or Azure, or you have tens or hundreds of accounts across all these providers. And then within those, you have lots of Kubernetes clusters. And then each of them has different RBAC and different auth. And then different teams have to manage these, different clusters need to be managed, all these cloud accounts. You’re not alone. We hear this a lot. We work with a lot of teams that have similar challenges.

The tricks of Kubernetes access

Dan: But before we go into those, I do want to drop a poll and talk about how are you doing this today? Do you manage a bunch of VPNs? Do you have CI/CD pipelines that you have to juggle Kubernetes RBAC with? Do you have to manage a Vault? How does that work as of right now? I’m going to turn off the screen share for a minute and I’m going to leave that poll open. I’m going to give this just a second.

[silence]

Dan: I see some VPN horror stories. I see no visibility into anything. A lot of VPN horror stories. Okay. Yeah, I’m aligned with that. We hear that a lot. Also a lot of no visibility. That’s interesting. We’re hearing more of that as compliance becomes more and more of a big deal for teams to manage. RBAC tangled like a spider web. I like that one. I think that’s real pain. If you’ve had to manage 1 Kubernetes RBAC, you’re probably fine. If you’ve had to manage 20, probably a little bit hurt. Cool. Thank you all very much for participation. I’m going to close this and we’re going to get back to it. Cool. All right, so let’s talk about the challenges that we’ve seen that it sounds like a lot of you are seeing as well. So there’s this problem of managing access and identities when there’s things like users with different clusters executing different kubectl sessions and managing the RBAC rules. And then you also have to manage things like CI/CD pipelines. And now you have to deal with new things like AI agents, this becomes very complex and error prone. And a lot of the solutions that we’ve seen, where it’s just like, “Okay, we need to get this solved now,” so you end up with things like either static kubeconfigs, or you do things like IAM roles, which are overly permissive, or you just do a long-lived credential to just throw a password out there for everyone. This exposes a lot of organizations to unnecessary risk. And I think the last thing anyone wants is to be a headline for X company has been breached.

The reality of Kubernetes access

Dan: When you have things like this RBAC fragmentation and inconsistency across your identity management, it makes compliance really difficult and it causes blind spots. So when your auditor comes along and asks how things are going, you kind of end up in a scramble. This lack of centralized visibility into user and service accounts also hinders incident response. So if your security team gets an alert and they need to be like, “Okay, this user account had X thing happen. Okay, who is the human behind that or who is the pipeline behind that and what was the purpose of it?” You don’t really have any visibility into that when you have all this access sprawl. So what are the common solutions to these problems that we’ve heard? So for the managing access and identities, yeah, it’s complex and it’s error prone. So what we’ve seen is like federation tools, things like Anthos, Rancher, or just like an SSO integration via OIDC or SAML. Like, “Oh, I’m just going to tie in AWS, OIDC into EKS, or I’m going to use Okta,” or something like that. That federation does centralize authentication, but you’re still relying on custom-level RBAC and things like separate kubeconfigs and inconsistent policy management. We have the actual user access level covered, but we don’t really manage the authorization beyond that.

Common approaches and their limits

Dan: The other problem that we see is things like static credentials or overly permissive IAM permissions. The solutions we hear are short-lived tokens with things like kubelogin or using a Vault or IAM roles. And that does reduce long-lived credentials, but it introduces a lot of complexity. Someone has to manage all the systems for Vault rotation and the ephemeral credentials and manage these IAM policies. It’s still a headache. And then RBAC fragmentation and then consistency when you have things like AI versus humans versus CI/CD pipelines and things like that, there are solutions with things like Open Policy Agent or Gatekeeper or some kind of GitOps managed RBAC. I’m sure many of you are using ArgoCD or Flux. Those policies are decentralized and disconnected from real-time identity changes. So for example, if someone, say, leaves their job, we may not have immediate reflection of that in their user identity. So if, say, I change teams or I quit or something like that, are my policies updated in real time? Is my access cut off? How do you know? And that also lends to things like no centralized auditing. People do centralized audit with things like CloudTrail or Datadog, or they use bastion hosts. But this is reactive and incomplete. You don’t necessarily have real-time user behavior, or if you have to manage a bastion, then there’s manual management, you have to load balance, keep that thing online. It can be hard to prove compliance or access lineage. Theodore, I see you in the chat asking if we could go back on a slide. It’s just a summary of what we’re talking about here with the different problems. And now we’re talking about the solutions to those problems. So you haven’t missed much.

Kubernetes is different

Dan: Kubernetes then introduces even more new problems. In addition to things like Vaults and bastion hosts that we’ve had for a long time, now we have Kubernetes that is changing the security game. Traditional servers were things like — they were static. You’d spin up a server and it would be there for the foreseeable future. Kubernetes is dynamic and ephemeral. You’re managing a control plane for workloads, not long-lived hosts, which then means that things like static credentials introduce a problem. When a pod comes up or a node comes up, cluster comes up and then spins down almost immediately. How do you provision that access? And we’ve already talked about the problems with things like static kubeconfigs or shared credentials. Those expire, they go stale, or they get copied around unsafely and indefinitely because they are longstanding permissions. Legacy PAM and Vault tools don’t really solve this problem either. Those were built for things like SSH or RDP. They’re not really built for things like Kubernetes, which is built around an API. And they don’t plug in neatly to things like Kubernetes RBAC or the Kube API for those types of access patterns. This is where we start to see a lot of that fragmentation when each cluster enforces its own rules. When you’re updating or auditing permissions across multiple clusters, that then becomes slow and very error prone. It’s very hard to juggle lots of environments with different permission sets. And then we add complexity to that with things like CI/CD jobs, bots, and controllers. They all need API access. But how do you grant that? Do you do Vault-based static injection? Do you do just like standing persistent credentials? Do you have to manage rotation? It all creates a bunch of unnecessary complexity.

The “treats” of Teleport

Dan: This is also challenging to scale. If you, say, want to do some kind of like access- request-based flow, you can build CI/CD for that, but then that’s high frequency and it becomes hard to automate. If you want to have the team manually manage someone’s user permission, say, when they request something higher, that creates a ticket-based workflow. And at scale, that is just so difficult to keep up with. So the solution, as we see it, is an identity-based pattern. So we treat Kubernetes as just another identity surface, and then we base things around everything as an identity. Humans, CI/CD workloads, AI machines, things like that. Each of them has a unique identity. And then we unify access, auditing, and policy all around those identity. And with infrastructure identity, you can then natively integrate Kubernetes with things like access, audit, and other things into your existing workflows. So what do the users get out of this? We want to improve the user experience for engineers who need access infrastructure. That means we want to also improve resiliency by eliminating static credentials and standing privileges. We need to keep the security team happy. Teleport integrates directly with Kubernetes. So you get seamless access control and auditing over things like kubectl sessions via the API or through an exec session. But also, developers are still just using their kubeconfig. So they continue to use things like Open Lens or anything else that’s built on the kubeconfig. We want to directly integrate with those clusters without adding additional layers or configurations or adding complexity to the way that the engineers work.

How it works

Dan: Let’s talk about what the actual technical solution to this problem is. We issue X.509 certificates for all users and all workloads. So no static kubeconfigs or tokens or keys — they get a certificate and that is their source of auth. We map those certificates to things like IDP-based roles. So for example, if I’m on the DevOps team and I sign in, I get the DevOps role, I get a DevOps-based certificate. That ensures consistent identity-based authorization. And that role, that group, that comes from my IDP. So what permissions I get comes from a single source of truth, something like inherited from Okta attributes or Entra attributes. We then base this on — can Teleport integrate with Keycloak? Yes, we can. We base this on a central certificate authority and identity layer across all of these clusters. So it’s one policy and one single audit trail. This then gives us things like native Kubernetes protocol support. So you get full visibility into Kube exec sessions, port forwarding, API activity — all of that. And you get to do things like eliminate VPNs, bastions, or shared secrets. You access through a single platform that is Teleport with secure access over mutual TLS, all driven by identity. This enables non-human users as well. So things like CI/CD workflows, AI, they all get identities with ephemeral, not standing privileges. And then because Teleport is facilitating all of these connections, you get every session recorded and captured in audit logs for compliance and forensics. So Teleport’s comprehensive capabilities include things like session management, auditing, and support for a wide range of protocols.

Use case: Centralized Kubernetes access across the globe

Dan: So outside of Kubernetes, we do things like SSH, databases, RDP, things like that. This is ideal for organizations that require detailed access controls and auditing capabilities. This is a win-win for security and for engineering. A lot of security solutions will say that they harden security without impeding developers. We harden security while making things easier for developers. I’m going to talk about how that’s actually been implemented in practice. So this is a real customer story that came to us. This “Why Teleport” box here that you’re seeing — we did not write this. This was the requirements they came to us with. They’re a big Azure shop. They needed something that could scale across lots of clouds and lots of environments and also cleanly integrate with Azure AD, which they could self-host. They had specific compliance requirements that said their data had to stay within infrastructure that they owned. They needed to separate dev and production environments behind something like Just-in-time Access Requests, so you couldn’t have simultaneous access to dev and production. They also wanted centralized auditing. And most importantly, they needed something that their engineers would be happy to use. I think we’ve all kind of been in that situation where you introduce friction to devs, and then you either see a slowdown in production because everyone’s waiting for a GRA ticket to get resolved or something like that. Or you see shortcuts and backdoors with engineers basically asking forgiveness instead of permission. We need to meet the engineers where they are to avoid that situation. If we provide them something that they want to use that already integrates with their workflow, they don’t try and go around and they don’t get stuck in red tape. And that’s the ideal situation.

Demo

Dan: On that note, I’m going to dive in and show you what it actually looks like. So I’m going to grab my terminal here, and give me a quick second. All right, so I’m going to log into Teleport, clean, and you’re going to see what this looks like as an engineer who just needs to access Kubernetes. So I have this binary called tsh. This is what I use to actually manage my authentication. This is Teleport software. I run tsh login and I specify where the service I’m connecting to is and what auth source I want to use. These can be specified as logical defaults. I just juggle a lot of environments. I’m going to specify them explicitly. And you can’t see over here, my browser is doing a successful login through, in my case, Okta. Great. And the next thing I’m going to do, now that I’m logged in, is I’m just going to say show me the Kubernetes clusters I have access to. So I’m going to do tsh kube ls. In my case, I’ve only been granted access to one. tsh kube login, and I’m in. And now I have my kubeconfig, my Kube context. This is all set for me. So if I want to do kubectl get namespaces, it’s going to spit out my namespaces. I have that access. I’m going to do kubectl get pods. I’m going to spit out the pods in my default namespace. Now if I terminate my Teleport credentials, so if I do something like tsh logout, or if my administrator decides to cut off my access for whatever reason, now I’m out. So if I try and run Kubernetes commands now with no valid session, no valid certificate, I can’t do anything. Over in admin land, here you can see I’m signed into Teleport and I can see all of my resource types. So this is what I see when I sign in during the day. This is the web UI.

Dan: As you just saw, everything can also be done through the command line, but the web UI is a nice visual aid, so I’m going to use that for right now. So you can see here I have everything from — oh, Clarence, I see you’re asking about how we integrate with something like Lens or OpenLens. Teleport, when you sign in, actually sets the kubeconfig, and it sets it to authenticate through X.509. What’s nice about Kubernetes is it allows us to do native proxying and use certificate management natively. So that means that all OpenLens has to do is just say, “I’m going to use whatever’s in the kubeconfig,” and then it’s going to handle all the connection string. And that does work with OpenLens. So if I sign into Teleport and then I open OpenLens, it just assumes that what’s in my kubeconfig is accurate. And then I can go ahead and access however I need to access. So here you can see all the resources I have access to. Everything from like SSH servers, I have some web applications, a bunch of databases, but I also have Kubernetes clusters. So for something like Kubernetes, I’m going to access this through kubectl. So when I hit Connect, it’s just going to spit out, “Hey, here’s the commands that you should run in your terminal to get signed in.” So if a user is new to Teleport, this will guide them step by step through exactly what it is that they need to do. But then if I wanted to do something like access an SSH server, I can also do that through the web UI here by just hitting this dropdown and it’ll actually open a virtual terminal for me, which is super cool and convenient. I can also do this through the command line. We certainly don’t want to take anyone’s SSH clients away from them.

Dan: Over on the actual role management side. So you saw me sign into Kubernetes and do things like get pods and all that. The way that we actually get that access is through Teleport “Roles”. So when I click on this tab and I click Roles, I’m going to search for K8s. And here’s an example of what a role would look like within Teleport. So again, these roles get mapped based on things like single sign-in attributes. So if I sign in with, say, Okta, Okta sends along all of my metadata, like what groups I’m in. And then I can say this role matches this group. So if I’m on the DevOps team, Okta says my group is DevOps. DevOps gets X role within Teleport like this K8s limited one here. I can do things like just set the Kubernetes groups that I’m going to allow the user to log into, and I’m going to set the Kubernetes clusters that they can sign into. And that’s based on these labels that exist within Teleport. So when I enroll a Kubernetes cluster within Teleport, I can either, A, inherit something like AWS tags or GCP labels or something like that. Or I can actually label it within the cluster itself when I map it. And then those labels are used to grant permissions. So I can say like, “Okay, this is the dev environment. This is the prod environment. This is the front end. This is the back end,” things like that, whatever key value pair you want to use for your permissions management. And I put the user in a group, and we could just stop there. If you’re using Kubernetes RBAC today and you want to keep using it, you map it to a group — great, we’re going to put a user in that group, they’re going to get whatever Kubernetes RBAC says. Or Teleport can actually get granular and be a single source of truth for Kubernetes Access. And that’s what you’re seeing here under these resources. Or I’m saying you’re allowed to do these actions like exec get an update to this specific pod in this specific namespace. I could also do things like wildcards. So I want to be like, you can access any pod in the namespace of sandbox front end. That would work just as well here.

Dan: And then over on the audit logging side. So now we have a map of how the user signs in, where they get their permissions from. Next thing I’m going to cover is the audit log itself. So here you can see Session Data, Session Started, Session Disconnected. Down here you have the Kubernetes request. So for example, we saw me do get pods. If I hit Details here, here you can see all the information about that actual user session. So even though I signed in with impersonation, it’s going to map this to my original Okta user in my case. So I signed in to Teleport with Okta. This would also map for Keycloak or Entra or whatever it happens to be. My username from that identity source is going to be captured here. In my case, I’m doing trusted devices as well. So I’m saying I can only access this cluster from Teleport laptops. And what you’re seeing here is the actual information about the laptop that I use to say this is coming from this specific asset. So if I tried to access this from, I don’t know, my personal PC or something like that, access would be denied and this wouldn’t be captured. You can see the Kubernetes user that I’m using. So again, I’m using impersonation, so I’m just mapping my Okta user to a virtual Kubernetes user. And then here’s the groups that actually map my permissions within Kubernetes. In my case, I’m being very generous and I’m giving myself system:masters because I’m managing this through a Teleport role. So system:masters is letting me do anything within Kubernetes, and then Teleport is giving me allows and denies. Is there any clusters or node number limit? No. We have customers running with tens or hundreds of thousands of resources connected. So we can scale. I am not super worried about any scaling limitations you might have, but hit us up. I’d like to hear about it. And then we do capture as well the things like the actual request. So here you can see I ran a get pods and that’s all captured here with — here’s the API I hit and things like that. All of that is captured in these audit logs as well.

What happens when you rely on identity

Dan: And then these can be easily shipped off to a SIM, like Splunk, Datadog, Elastic, anything like that. So if I wanted to do some kind of log auditing or something like that, or if you have an auditor coming through and be like, “Hey, I want to see who accessed what,” you have a single source of truth to point them to. It’s like, “Here you go. Here’s the audit logs. We know exactly who did what, when.” I think that about wraps it up for the actual demo itself. So let’s wrap this up. What happens when you rely on identity and what are the business outcomes? You get the freedom to scale safely across — Eugene, I will get to you in a second of this slide. You get the freedom to scale safely within teams, move fast across multiple clusters and clouds, and you don’t have to re-architect how access works. You spend less time juggling credentials and getting products out the door. You don’t have to chase down expired kubeconfigs. You don’t have to rotate secrets. It’s all managed through a single control plane that is Teleport. You can focus on enabling developers and not policing access. You get to be confident that you know who’s doing what, and every action is tied to a verified identity. So you don’t have to guess or figure out like, “Okay, someone signed in as root. Okay, what did root do? Someone signed in as system:masters. Okay, who was system:mastersat that time?” You can onboard and offboard team members faster, like we talked about that DevOps example. The second I get put in that group, I get my access. And then when I get removed from that group, I lose that access immediately. Developers get fast, frictionless entry to the clusters that they need, and you get to allocate those hours elsewhere. I spoke with a customer yesterday who said that access requests right now are taking about four days when someone submits a request to change. And her SLA is about 40 minutes. So we are driving that forward as Teleport with that customer to help them simplify that and get away from that four-day manual access approval they’re stuck with right now.

Q&A

Dan: Security gets full visibility without slowing anyone down and they get peace of mind with full session history, no blind spots, don’t have to juggle things like “break glass” accounts, and you have one source of truth. Ultimately, you get the freedom to scale safely when teams can move fast across clusters and clouds, and you don’t have to re-architect how that access works. All right, so I see — do you differentiate Kubernetes centralized administration tool like Brancher from Teleport in the Kubernetes context? So it kind of depends on how you want to manage this. So the way that it works is Teleport is a proxy-based solution. So the user connects to Teleport and then Teleport takes actions using its own pod inside of Kubernetes. So you install a Teleport pod within the Kubernetes cluster, it takes actions against the Kubernetes API, and then the user connects to the Teleport service. And then Teleport dictates, “Okay, I’m going to allow or deny that controller to take X action based on your role.” So it’s going to say like, “Okay, Dan signs in. Dan is allowed to do X. Dan is allowed to do Y.” That’s separate from the actual Kubernetes RBAC, which is something like — for example, I was using system:masters. So Kubernetes, as far as it’s concerned, is saying like, “Dan can do anything.” But then Teleport is going to be like, “Okay, yeah, you can do anything within Kubernetes, but I’m only going to allow you to get certain pods in certain namespaces.”

Dan: Question — do we already have an MSP partnership enabled for these new Teleport features? We do have a variety of partners. I don’t want to get into the specifics here. That could probably be a whole hour-long conversation. Hit us up afterward. I think that can really be an interesting conversation. We do have a number of partner relationships that we’re forming right now. Could you please get in touch? Yeah, absolutely. Yeah, I’ll make sure we copy down your name and we’ll be in touch. Anybody else? Eugene, I’ll hit you up afterward. Cool. All right, team. Thank you very much. Let’s stay connected. We will be at KubeCon coming up here in Atlanta. So if you’d like to book a meeting or hang out with us, we will be around. So please reach out.