Top Use Cases & Trends in Machine & Workload Identity

Top Use Cases & Trends in Machine & Workload Identity - Overview

As infrastructure becomes increasingly automated, the systems that deploy, manage, and scale it—CI/CD pipelines, service agents, orchestration tools—rely on a growing class of non-human identities (NHIs). These machine actors often operate with persistent credentials, excessive privileges, and limited visibility—leaving critical trust gaps in modern environments. 

This session explores three high-impact use cases where addressing NHI is both urgent and achievable:

• CI/CD Pipeline Security: CI/CD platforms frequently use static secrets and over-permissioned service accounts to deploy infrastructure. We’ll walk through how to apply strong identity controls—short-lived credentials, just-in-time access, and session-level auditing—to harden these systems without slowing down delivery.
• Infrastructure-as-Code Workflows: Provisioning and orchestration tools often authenticate with long-lived credentials and execute plans with sweeping access. Learn how to introduce scoped, ephemeral identities into your automation flows—without disrupting developer velocity.
• Federated Workload Identity: Multi-cloud and hybrid services need to authenticate and authorize without relying on shared secrets or brittle one-off integrations. This talk will outline patterns for issuing verifiable, short-lived credentials across environments, enabling secure service-to-service trust without sacrificing velocity.

These use cases establish a clear model for managing non-human identity risk—one rooted in Zero Trust, built for automation, and grounded in real-world implementation.

Key topics on Top Use Cases & Trends in Machine & Workload Identity

• Non-human identities (NHIs) have become a critical security vulnerability, with 24 million hard-coded credentials found in public GitHub repositories in 2024 and NHIs outnumbering human identities 25-50x in most organizations.
• Traditional secret management using API keys and passwords creates operational complexity, enables shared credentials, lacks visibility, and allows humans to inappropriately use machine identities—leading to breaches and business disruptions.
• Teleport’s solution replaces long-lived secrets with short-lived cryptographic identities issued at runtime, automatically expiring when jobs complete and providing full audit traceability.
• Two implementation models address different needs: Secure Access manages both identity and resource access through Teleport proxy, while Universal Identity issues SPIFFE-compatible certificates for flexible integration.
• Engineers are freed from credential management tasks through a unified identity layer that governs people, hardware, and software with consistent role-based access control.
• Complete audit logs show exactly who or what performed each action, eliminating anonymous “admin” access and enabling compliance with regulatory requirements.
• Teleport’s approach prevents operational risks from manual credential rotation, enables secure automation at scale, and positions organizations for the coming proliferation of AI agents.

Expanding your knowledge on Top Use Cases & Trends in Machine & Workload Identity

• Teleport Machine & Workload Identity
• Docs - Teleport Workload Identity
• Blog: Your Infrastructure Has a Non-Human Trust Problem
• Blog: Workload Identity Meets Supply Chain Security: Teleport's Sigstore Integration

Transcript - Top Use Cases & Trends in Machine & Workload Identity

Diana: Good morning, good afternoon, and good evening, all. Thank you for joining us today. I’m Diana Jovin and your moderator for today. We’ll get started in just a minute. While we’re waiting for people to roll in, maybe if you can post in chat where you’re dialing in from today. I’m dialing in from the coast of California. How about you, Lalit?

Lalit:  I’m just outside London in the UK.

Diana: How about you, Noah?

Noah:  I’m in London in the UK, so we’re probably not all that far, Lalit.

Introduction

Diana: Great. I feel like I should be in the UK today. I also want to note and thank Lexi who’s behind the scenes making sure that the logistics go extremely smoothly. So thank you, Lexi, for helping us all out here today. And nice to see you all. I see Illinois and, oh, more London. That’s awesome. Okay. Well, let’s get started. So thank you for joining today’s webinar. We’ll be talking about the top use cases and trends in Machine & Workload Identity. So if you expected to come here to learn about something else, that’s the topic. We have a couple of housekeeping things to cover before we get started. Please note the chat box on the right side of your screen. You can use that to ask questions, post comments, engage with the speakers, and we’ll keep an eye on that throughout the webinar. If you have any questions, please feel free to add them to the Q&A tab at the top of the chat box at any time, and we will address them at the end of the webinar. And if we do not get to them in time, we will email you afterwards with a follow-up. There are a few linked resources in the Docs tab. Feel free to download these. And we will send you a recording of the webinar 24 hours after the event, so don’t worry about furious notetaking.

Diana: So let’s get started. First, let me introduce the speakers today. We’re joined today by Lalit Choda, also known by many as Mr. NHI, right? And there’s the great t-shirt that goes with that persona. Lalit is the founder of the Non-Human Identity Management Group through which he educates the industry on the risks associated with NHI and strategies to address them effectively. And Lalit comes to this effort with some really high-impact real-world experience. Prior to founding this group, he managed some of the largest global NHI programs within the investment banking sector. And through the group, he’s also published two very useful reports: The Ultimate Guide to Non-Human Identities and the 52 Non-Human Identity Breaches report. And both of those are downloadable from that resources tab that we talked about. And in particular, if you want to reference the impact that breaches can have on organizations, the second one is extremely valuable in pointing to some of the consequences of taking no action.

Diana: We also have Noah Stride on the webinar with us today. Noah leads the Machine & Workload Identity team within Teleport’s engineering organization, and he’s been a key contributor there for the past three years, bringing a strong background in platform and infrastructure engineering. Noah is actively involved in the SPIFFE community where he contributes to the development of open-source standards for workload identity. Noah’s a frequent speaker in Teleport webinars and conferences, sharing insights on workload identity management in cloud native and heterogeneous environments. Thank you both for joining today. All right. So to kick us off, we’ll start with you, Lalit. So in your role as the founder of the NHI Group, you hear daily about forces shaping this market. So a few questions about NHI and why people are focused on it now. Let’s start with breaches. So I just referenced the report on breaches that you published through the group. So thank you so much for that report. What’s one breach in particular that stands out to you as noteworthy?

Lalit: Hi, everyone, and thanks, Diana, for having us join you and Noah at this webinar. Look, I think we’re seeing definitely with our 52-week breach report a significant increase in the frequency that non-human identities or machine/workload identities are being compromised by primarily external threat actors. I think the one that stands out the most, or my favorite, from last year was in October. Some attackers hijacked a large language model on some cloud infrastructure to run some rogue chatbot services. The threat actors leveraged some AWS access keys that they discovered. Maybe they were available in public repos that could be discovered. And they hijacked some Anthropic models provided by AWS Bedrock for dark role-playing activities that unfortunately involved children in some of that activity. So we’re definitely seeing kind of attacks around sort of AI-based LLM infrastructure on the increase, and that’s very concerning, especially with now the growth of agentic AI as well. So in terms of recap, NHIs are now easy to discover. Threat actors are finding them very easily. They no longer need to attack an organization through some phishing campaigns. They’ve got NHIs, API keys, tokens, other types of non-human identities that are easy to discover and get into an organization or into a third-party supply chain as well.

The need for NHI strategies

Diana: All right. So, certainly, breaches are one huge motivator for why you want to take a look at NHI strategies. You’ve also called out some other reasons why people are motivated. What are some of those other reasons that have come up?

Lalit: Yeah. Look, we do get asked sort of quite a lot why now, and as many of you know on this call, non-human identities have been around ever since computers existed. My first exposure dealing with non-human identities was 25 years ago as part of Sarbanes-Oxley SOX controls, where we had to cycle NHI passwords on databases at the time, but I think what’s changed is really the last 5, 10 years. We’ve now got so much more hyper-fragmentation with our infrastructure. Before, everything was primarily on-prem, so it was really hard for NHIs to get compromised externally. But with hyper-fragmentation that we have with multi-cloud, SaaS, on-prem, API-based services, and obviously with containerization and microservices, we’ve now seen a proliferation of NHIs across kind of the industry and across the environments. And because before the NHIs were hard to get at, now that they’re so widely distributed, we call it secret sprawl.

Lalit: There was a recent survey done where, in 2024, nearly 24 million public — sorry, hard-coded credentials, passwords, were found in public GitHub repositories. So I think that’s one big reason why things have now got to the forefront. I think, clearly, previously people were focused on human controls, PAM controls protecting their borders, and now this is the next logical step that we see. And typically, unfortunately, this was always the forgotten problem child in an organization. Everybody knew they had the problem. They knew it was hard to solve, and it’s just something they never touched. So, normally, most organizations will have very weak controls around managing the life cycle of NHIs. So that’s some of the reasons why now it’s really important that people can start addressing these huge exposures that are out there.

NHI issues

Diana: So one of my favorite topics to center on when we talk about non-human identities is actually humans, right? So before the webinar, we were talking about the role that humans play. So can you comment on that briefly?

Lalit: Sure. And if you could maybe just bring up a slide I’d prepared. I’m going to spend a few minutes talking about a specific issue that occurred at an organization I was working at. I got a call from this head of IAM and CISO, and they said, “Look, we’ve had a big operational issue. We feel there was some issue to do with non-human identities, and we feel someone inappropriately used a non-human identity, got into production, and caused some massive business impact. We need you to investigate, and we need you to sort of cycle the password within 24 hours.” So as we started talking to the team in question, it turned out there was an IT support — sorry, someone in IT that had access to a database non-human identity. It was for one of the business applications. And unfortunately, this non-human identity was using kind of password-based authentication. The IT person knew the password and inappropriately used this non-human identity to connect into what they thought was a QA database, but accidentally they connected to production. That was then the second issue, where clearly, due to a lack of environment segregation, the NHI in question had the same password in prod and non-production. So human inappropriately using an NHI and accidentally connecting to production. You’ve all heard these stories before.

Lalit: We then start talking to the team, saying, “Look, you need to sort of secure-cycle this password so we can reduce the surface area of risk around who knows this credential.” The team said, “Look, we don’t really know where we’re using this credential. It’s used in lots of scripts. It’s going to take us some time to find out everything that’s using this credential.” At the time, that organization didn’t have a really mature secrets vault solution, so a lot of hard-coded credentials in code, scripts. So we then had to sort of help that team do some scanning and try and uncover all the dependencies. Clearly, if you miss any of those dependencies and prematurely cycle the password before getting these hard-coded credentials in a vault, you could cause further operational risks. So, clearly, a lot of risk with cycling the password. The next thing the team said, “We think we’ve shared this credential with some other teams, some upstream/downstream consumers that want to connect to our database. We probably gave them our credential, I don’t know, maybe 5 years ago, 10 years ago. We don’t even know who else is using our credential.” So then we had to work with DBAs. It was an Oracle database. We had to turn on monitoring and logging. We could then start to see kind of where the connections were coming in from, which IP addresses were [inaudible]. And then we were able to determine quite a few other applications — all had used this hard-coded credential in their code, their scripts. So then we had to work with all of those teams and then get them to move to their own unique credential, so no longer sharing, and then cycle the password finally after three weeks. And there’s clearly also identified gaps around lack of monitoring controls. We didn’t know who was using the credential, humans using the credential.

Lalit: And then the final thing was — the organization in question didn’t have any policies around cycling NHIs. So just from one incident, six kind of core issues that you’ll see again and again in many organizations where they have weak controls in managing NHIs. And once we fixed this issue, my CISO then said, “Look, we now need to start a large NHI program to start addressing this exposure that I’d been telling them about for years and years.” So quick recap, humans using NHIs is clearly a big risk exposure. So I guess I’ll pause there. Hopefully, that was helpful to give some insight. Okay. I guess, Diana, I’m going to sort of throw things back at you. At the EIC conference last month in Berlin, the KuppingerCole conference, you actually spoke in one of the NHI sessions about some primary use cases that you talk about when it comes to sort of Machine & Workload Identity. Do you want to maybe share with the audience some of those top use cases?

Diana: Yeah, thank you. So, certainly, in the case where people come and talk to Teleport about Machine & Workload Identity, because we’re focused on infrastructure, often these use cases focus on automation. So examples of this may be engineers who are responsible for infrastructure as code and deploying infrastructure throughout the organization using tools like Ansible and Terraform. They talk about the challenges of looking downstream to 10,000 servers. They don’t own management of all those servers, and those servers have different ways that their credentials and identities are being handled. And they talk about how the orchestration of all that just becomes a logistical nightmare, and you either default to having privileges that are too big of a surface area or it just becomes really problematic to try and get that executed. The second is extremely common. We see people starting here a lot. And this is looking at how to secure CI/CD pipelines, where people are deploying application code from code repositories, often through mechanisms such as Jenkins and GitHub. And here, often, the challenge is that these pipelines have been configured with super admin privileges, making them a key target of threat actors. The third are engineers who are operating in multi-cloud accounts. And so they have service accounts that they’re setting up that are operating across different cloud environments. Maybe there’s some function that they need from different places. Maybe it’s one from AWS, one from GCP. Or they’re needing to replicate service accounts in their different data centers or business units. And just the friction that comes from crossing the boundaries of technologies that have different identity and security and authentication and credential architectures becomes very high. And then, finally, you just have a lot of automation bots, right, that are running often without identity or any kind of privilege management whatsoever.

Common machine & workload identity use cases

Diana: And so when you look at the surface area here and you reflect on just the incident that Lalit just mentioned, you can see the headache that people start to have around thinking about not just security but also engineering productivity. And this is where we really see these two concepts of both of them beginning to go hand in hand. People talk about challenges, right? They’ve talked about the speed versus security trade-off. We’re seeing these two needs beginning to converge. You need both at the same time. And one of the things that people are trying to address is getting super user privileges out of their environments, beginning to narrow down the blast radius so that if there is an incident, they don’t have to take down all of their operations to resolve it. They’re worried about orphaned accounts, where engineers set up an account and then left the company but those SSH keys or API keys are still resident. Or maybe the engineer left, but they still have access 10 years later, right? That is not uncommon. There are identities that are now ephemeral, so you can’t think about ways that you’ve thought about static credentials to manage these. There’s compliance, which is who is doing what in the infrastructure, and cloud credential complexity. And generally, there’s one word that is kind of persistent through here, and this is this idea of secrets and credentials which I’ll come to in a moment.

Diana: Often, this preliminary idea about how to improve handling of NHI centers on how companies manage secrets, and you see this sometimes in the language of how people express their problems. They say that they’re trying to focus on robust secrets management or automating least privilege, and then in tandem trying to audit that. Or we’ll hear, “We need visibility, discoverability, and management of these identities.” And then the example given is, if an API key hasn’t been used or accessed for several months, they want to remove it. But when you focus on secrets, right, this really becomes problematic at the scale the infrastructure requires. Even one secret in infrastructure can pose a risk. The breach of one secret can be so problematic because of the role that it plays in the code deployment and the operations of a company environment. And also, when you think about everything that’s happening at the scale of complexity, it just becomes a very difficult thing to manage. And so the way that people express kind of how they’re coming to terms with this — we have one company who said they had a recent audit finding that required them to start rotating all of their secrets because they were being persistent for a little too long, and they said, “But if we do that, we’re going to consume all of our engineers’ time only on that, not even on anything else that’s important to the business.” And then another leader expressed it this way. They said, “If you look at our cloud infrastructure, there’s so many static credentials. It just creates complexity.” And what they’re trying to do is abstract this complexity out so they can focus on their jobs. In other words, they don’t want engineers to be in the business of credentials management. It just is getting in the way of doing their job.

Teleport Machine & Workload Identity

Diana: And so the way that we’re approaching this problem, then, with Teleport Machine & Workload Identity is to replace secrets with cryptographic identity that is issued at runtime. And if you look at the language of these two models, if you’re managing secrets, you’re talking about provisioning cloud keys, rotating tokens, locking down service accounts, setting up vaults. If you’re governing cryptographic identity, basically, you’re issuing short-lived identity at runtime that has attestation to attributes in the platform that it comes from that run with it, right? So you know where it came from and why. And that identity has least privileged access by default that’s determined by role and policy. That access and the identity automatically expires when the job is done, and within the audit log, you have full traceability of where it came from, what action it took, what the privileges were. And so your audit log, then, doesn’t have things like admin, where you have to go figure out who is behind the admin. And then you also don’t have the situation where you have shared credentials. You also don’t have the situation where a human can do something with a non-human identity. Basically, everything is governed by their own unique identity that is tied back to cryptographic attestation.

Key ideas: Eliminate secrets, unify identities (people, hardware, software)

Diana: So this key idea #1 that we’re introducing here, that Noah will speak to, is: eliminate secrets. So you don’t want secrets. You don’t want passwords. You don’t want credentials. You want to get them out of the way. Zooming back for a minute, when we talk about NHI, we actually are thinking about it at Teleport from a broader context, which is that in infrastructure, you actually want to consider the cryptographic identities of people and hardware and software, which are kind of the three things that are in your infrastructure, together. And if you unify those identities into a common layer, you can begin to reason about policy in a really interesting way. You can have insights and identity security in a really interesting and powerful way. And then, further, it becomes much easier to incorporate new technology into the existing security framework that you have. And there certainly is new technology these days that is of interest to everybody, right, LLMs and agentic AI. They can all fit into this architecture much more easily because they actually are beginning to have some attributes that need to be governed, like people, some software. You probably want some hardware in there as well to enforce who’s coming from what place to interact with these systems. And so I’d invite you all, if you want to learn more about infrastructure identity and what that means — Lexi will post in the chat a URL that you can go to, to learn more and download some assets about that. But zooming back into NHI and Machine & Workload Identity specifically, I’ll now hand it over to Noah who will talk about kind of the primary architectural models that people use to deploy Machine & Workload Identity and how they’re solving these problems that we’re talking about.

Secure Access

Noah: Awesome. Thank you, Diana. So yeah, at the highest level, Teleport Machine & Workload Identity is solving these problems by applying those two kind of key ideas you’ve highlighted, right? So we’re eliminating those long-lived shared secrets, like API keys or passwords, and replacing them with proper identities and short-lived cryptographic credentials that can encode those identities. Now, machines authenticate to Teleport through an attestation process. They prove some attributes about themselves. This can leverage federation of platform-specific credentials, or in on-prem environments, we can use hardware roots of trust, like TPMs. Configuration within Teleport can then be used to map those kind of distinct identities — well, those attributes, into sort of a distinct identity, right? And this creates a central form of identity for all machines and workloads within your infrastructure, kind of regardless of whether we’re talking about a CI/CD pipeline, a virtual machine, maybe a physical piece of [inaudible], or a Kubernetes pod. And this is going to be really valuable in an era where infrastructure is commonly sort of spanning multiple cloud platforms, on-prem environments, and people are using all sorts of technologies, right? People have Kubernetes, and maybe they’ve got some machines that aren’t using Kubernetes. They’re using Cloud Run or kind of serverless tech, right? There’s all these different platforms, and on all those different platforms, everything’s got kind of its own distinct different identity, but if you can tie them all together in a central place, it becomes so much easier to manage. Now, these short-lived cryptographic credentials can then be used by machines and workloads to access infrastructure or to authenticate themselves to one another.

Noah: Getting a little bit more technical, Machine & Workload Identity supports kind of two different implementation models, and this allows it to cater for the needs of kind of a wide range of use cases. So this first model is Secure Access. Now, in this mode, Teleport is not only providing identity for your machines but is also managing their secure access to protected resources based on this identity. These could be SSH hosts, databases, Kubernetes clusters, or HTTP/TCP applications. The tbot agent is installed on the machine that will require access to resources through Teleport. There, it handles that kind of initial process of attesting the machine’s identity to Teleport and then requests the issuance and the renewal of these short-lived certificates that encode that identity. These certificates can then be used by workloads running on those machines to access resources through the Teleport proxy. Now, whether or not the machine can access the resource and what level of privilege it has when doing so is governed by Teleport’s role-based access control mechanism. This is the same RBAC mechanism that Teleport uses for humans, which provides this really nice opportunity to understand, access, and enforce policies for humans and machines alike. We’ve got a really great customer who— one of the things they wanted was that a CI/CD pipeline that belongs to a team can access the exact same sort of resources as that actual team can. And this really helps at scale. When you have 100, 200, 300 teams, and tens of thousands of servers, you don’t want to be manually setting up all that access, right? It kind of makes sense that a CI/CD pipeline has access to the same category of resources as the actual engineers. Now, in addition to kind of providing this access, Teleport can also provide audit logging and kind of session recording. Now, this makes it easier to spot and react to suspicious activity, but it also allows you, kind of when it comes to sort of compliance and audit time, to prove that certain policies are in place and that access has followed certain rules. This will make Secure Access a really great fit for those kind of CI/CD use cases. It’s really simple to adopt. And if you’re already using Teleport for humans, there’s very little you need to actually set up, but in doing so, you’re eliminating the security risk presented by long-lived secrets and the engineering overhead of creating, rotating, and cataloguing those secrets.

Universal Identity

Noah: The second mode is Universal Identity. Yeah, perfect. So Universal Identity provides a strong standardized foundation of cryptographic identity for workloads within your infrastructure, but it leaves how those identities are used up to you, kind of the customer. This makes it much more flexible than Secure Access and ideal for use cases where control, performance, and reliability are of the utmost importance. Now, rather than issuing certificates which are optimized for access through Teleport, like Secure Access does, Universal Identity issues versatile X509 certificates and JWTs. The content of these identity documents is dictated by the results of attestations performed against the machine and workload and the policies you’ve configured in Teleport. Now, Universal Identity is compatible with the CNCF SPIFFE standard. This is the Secure Production Identity Framework for Everyone, and it’s a set of standards around workload identity. This SPIFFE compatibility brings a whole range of benefits, but primarily, for me, it’s that it reduces engineering effort to adopt because there’s a whole bunch of kind of SDKs, tools, and platforms that exist specifically for SPIFFE or support SPIFFE as a standard for workload identity.

Noah: Now, as with Secure Access, the tbot agent is installed on the machine where workloads will require identities. The tbot agent performs an initial attestation to the Teleport cluster to identify the machine it is running on and then performs additional attestations against the workloads that are requesting identities, for example identifying the systemd service they’re running as or the Docker container they are running within. This allows fine-grained control over who can receive an identity credential and the contents of that identity credential itself. Now, workloads can use their short-lived identity credential to authenticate to a whole range of services. Previously, if you had a workload that had to connect to three or four different things, maybe that workload would have three to four different secrets. But in this case, that one identity credential could be used to authenticate to other microservices in the cluster, with things like mTLS, to authenticate to databases, or even to cloud service provider APIs, like AWS S3. Now, to be able to validate identity credentials presented to them, services are configured to trust Teleport Machine & Workload Identity as an issuing authority. Through the wonders of public key cryptography, services are then able to validate these credentials without needing to directly ask the issuer if they’re legitimate. This avoids introducing any significant performance or reliability impact. Finally, as with Secure Access, the attestation process used by Teleport eliminates the need for long-lived shared secrets and the associated security risks and engineering overhead in managing them.

Demo: Secure access from CI/CD

Noah: So we have a little demo now. Yeah, perfect. So in this demo, we’re going to be leveraging the Secure Access functionality of Machine & Workload Identity for a CI/CD use case. My hypothetical organization has a GitHub repository that contains code and artifacts and a GitHub Actions pipeline that deploys these artifacts to our fleet of production servers using Ansible and SSH. In a world before Machine & Workload Identity, we’d have generated an SSH key pair, configured all of our production servers to trust the public key, and then placed the private key into the secrets vault in GitHub Actions. Now, since this key pair is going to hold high levels of privilege against our production environment, we’d probably want to rotate this every so often, and we’d have to go through the whole dance of creating a new key pair, distributing it again and again. We also suffer from a lack of insight. Looking at a key pair alone in a secrets vault, we have no clue what it actually grants access to. Perhaps it grants access to more servers than we intended it to. Instead, with Machine & Workload Identity, we’ll create a bot identity within Teleport to represent our CI/CD pipeline, and then we’ll grant it access to resources using roles. We’ll define rules that control which GitHub Actions pipelines can authenticate to Teleport based on their attributes, and then we’ll use tbot within our CI/CD pipeline to generate the short-lived certificates and configuration files that Ansible will use to access our SSH servers. Cool. I will have to take over screen sharing, if I can find the button, that is.

Diana: It’ll be in the upper left of your screen there.

Noah: Yeah, I was hiding it. Hold on. Cool. Okay, awesome. So this is my little GitHub repository that is kind of our organization’s repository. Now, the first thing I’m going to show you, just to prove that there’s no kind of magic or secrets going on here, right, is we can go and look at whether any secrets are configured for our CI/CD workflow. And, right, we can’t see anything. Now, what I’m going to do just whilst I’m talking is I’m just going to kick off the CI/CD pipeline. And what we’re going to do is we’re going to change some artifact that needs to be deployed to our production servers. So let’s go ahead and write a short message, “Hello, audience.” Now, when we commit this file, it’ll kick off our CI/CD workflow and try to deploy it.

Noah: So now we can take a look at how this is kind of all actually set up. So I think it’d be useful first to look at kind of the configuration that’s actually involved in the Teleport side, right, all of our access control. I’ve used Terraform here to define this, but you can do this with YAML, or you can do this through the Teleport UI. First of all, what we’ve defined is this bot identity. Now, this is just kind of a user or a service account, right? It’s designed to be a way to give a name to a group of machines or a machine. We assign these roles within Teleport to control what it can access. This join token here is how we control which machines or which CI/CD pipelines can authenticate as that bot. And you can see here, we’ve got a very specific rule that’s saying, “Hey, we only want GitHub Actions that are running in this repository against this branch to be able to authenticate as this bot and access our production environment.” Finally, we have our role. This is what actually kind of defines the access policy and what’s been kind of given to that bot user. Here, it’s fairly simple. We’re saying, "Grant access to the Ubuntu user via SSH to any node in our sort of cluster that has this “env = [“mwi-demo”]. In a production case, maybe what you’d have instead of env is, hey, production and staging, and you’d only have your staging pipelines able to access your staging environment. In terms of our actual configuration, this is a fairly standard, simple GitHub Actions configuration here. I’ll try not to go into too much detail because we support a bunch of different CI/CD platforms, and this is just an example.

Noah:  What we do have here is our Ansible playbook. It’s really, again, super simple, “Connect to all of the hosts in our inventory as the Ubuntu user and copy this artifact to all of our hosts.” Within our GitHub Actions workflow here, first of all, we kind of fetch and download a couple dependencies, like Ansible, Python, and the tbot binary. And then, finally, we use this step here. This is something that we published just to make the configuration a little bit simpler. You’ll note here that I’ve given the address of my Teleport cluster, and I’ve also given the name of that join token we configured earlier that controls who is allowed to authenticate. When this part of the step finishes, it’ll output the SSH certificates and also an SSH config that uses those certificates. So you can see here, we’re going to be running the Ansible playbook, and we’re going to be telling it to use the SSH config that was generated by this step. So if we go back over, we should hopefully see that our CI/CD pipeline has successfully run. There we go. And we can just take a quick look at what that looks like. So you can see here, in this step, it went off and it authenticated to Teleport, and then we can see the Ansible playbook itself was able to run.

Noah: Now, the most interesting thing for me here is then to go and look at sort of the auditing and sort of the session recording functionality over on the Teleport side. So this is my Teleport cluster. If I head over to my audit log, we should be able to see some events relating to this sort of access that has just occurred. I’m just going to filter this down. Okay, cool. So you can see here, we have this audit log event called bot join. Now, this basically holds information about that attestation that the machine or the workload performed when it authenticated to Teleport to receive its identity. Now, we can see here, these are all of the attributes that were attested to during that process. So we know exactly which user kicked off the CI/CD run, we know which exact commit SHA it is, and we know all the information about the repository it was running against. Now, this is going to be really useful if you ever see any kind of suspicious activity because you can look back and you can kind of trace it to what initially triggered it and how did we end up here. What we can also see is audit log events for all of the SSH sessions that it created when sort of connecting out and running that Ansible playbook. You see a couple of things here, some file transfers. And, again, all of these contain a bunch of information. So we can see the command that it tried to run when it connected. We can see, of course, the name of the host, the remote IP address, as well as a reference back to our bot here.

Noah: Now, just for the final part of the trick, I’ll just sort of demonstrate that we have indeed pushed out this file. So if I connect to my host as a human using Teleport, I should now see— yep, we see we have our file here. And we can cut that out, and we can see, “Hey, that’s our message that we updated.” So that’s really kind of the whole end-to-end flow on this. But you can see we’ve gone from a situation before where, in GitHub, I would’ve been managing this private key, rotating it every so often — maybe not rotating it every so often because I’d have to go out and kind of reconfigure all of my nodes to now trust a new public key, and also not really understanding when those machines are connected to. If I was to go look at the SSH logs on those machines before using Machine & Workload Identity, all I’d see is, “Hey, this key pair connected.” I wouldn’t necessarily know which individual CI/CD run or which user triggered it. Cool. And that is everything from the demo.

Diana: Thank you, Noah. So I think at the end there, you were beginning to address why existing tech stacks are problematic for achieving the same goal. Can you maybe speak to that from the point of view of an engineer? How does this improve engineer productivity? How does it make people happier?

Noah: Yeah. So for me, when we’re talking about existing tech stacks, we’re kind of talking about using technologies like vaults that try to mitigate some of the problems associated with long-lived secrets, or we’re using kind of various secret scanning technologies that find all of our secrets. And the problem for me is they don’t really address the problems at their root in the same way that a cryptographic identity would. So to give an analogy, if we were to think about securing access to a door, sort of the simplest thing we could do is give everybody a copy of the key who should have access to it. But this isn’t going to be so great. Someone can leave that key on the train, or someone could borrow it. And if we wanted to change the key every so often, if it’d been copied without permission, we’d need to go and distribute that new key to everybody who should have access. And that’s going to make us not want to do that rotation process, even though perhaps we probably should have. Now, we can make that rotation process easier if we just locked that key in a little box, right, and we told everyone the PIN code to open that box. Now we can very easily go and change that key anytime we want, and it’s kind of less of a pain, but now we’ve got to try and keep that PIN code secret, right? This is your secret zero problem: how do you authenticate to your vault? And somebody can still copy that key and use it for a while before we notice and rotate it. But the bit that’s most important to me here is that we actually have no clue who actually used the key to open the door. We just know it was someone who actually had possession of the key, right? And this, to me, is the real problem with long-lived secrets, like API keys. Access isn’t clearly bound to a defined identity. It’s just based on knowing some secret. Now, just to finish it off, what if we were to swap out this lock on the door entirely and we no longer had some key to open it, right? What if we used a biometric, like a fingerprint? Not only do we no longer need to worry about rotating the key every so often or creating new keys and our engineers spending time doing that but our access is based on kind of specific, distinct identities. We know that it was Bob or Alice who opened the door on Tuesday, and we can revoke Alice’s access without having to give Bob a new key. And that, for me, is sort of that journey moving from long-lived secrets to cryptographic identity is like.

Diana: Excellent. Thank you. And so there’s a lot covered, right — the demo is fairly complex — in a webinar environment. If you’d like to have a deep dive with one of our sales engineers, please note in the Q&A, and we’ll be sure to follow up with you after the webinar. I also have a question for Lalit. As we were just talking about, this is a deeply technical topic, right? And so I’m sure that there are engineers on the call who followed every word that Noah said, but if you’re not technical, there may be some words that are new to you, like even SPIFFE, right, as an open-source standard. So how would you approach the idea of convincing C-level that this is actually important? And you talked about your use case at the beginning. What are some tools that people use to make that case?

Lalit: Yeah. Look, it’s a great question. We even had a session on this at Identiverse a few weeks ago at a workshop we hosted. Look, I think Noah’s analogy was fantastic, actually, about the door. I think that in itself, if you kind of explained that but then said to an exec, “Well, we’ve actually got tens of thousands or hundreds of thousands of these doors that we need to manage.” And that’s the reality, right? NHIs outnumber human identities 25-to-50x, even 100x. I guess, with agentic AI, that’s just going to extrapolate exponentially. There was a stat recently I saw that Salesforce expects a billion AI agents to be in service by 2026. So in summary, I would say these are easy kind of compromised vectors, right, for both external and internal threat actors. They can cause operational impact because they’re used inappropriately by humans. There’s clearly major control issues. You’re probably all going to have within your organizations compliance issues, SOX issues, where folks are using these NHIs inappropriately when they should be using the human controls. And given the fact that these are highly privileged accounts — many of them are static, been around for a long time, probably not removed after their use — we’re sitting on a huge ticking time bomb. And that’s the reality.

Lalit: So I think it’s really just something C-level execs need to really pay attention to now and get in front of it and ideally move to kind of the sort of model that you’re presenting with the Teleport product around solving this more strategically with sort of zero trust principles. You clearly need to have a hybrid approach, where you need to manage your existing tech debt of all your static credentials as you move to kind of more of a strategic sort of footing. But I would say you’re going to have a two-pronged approach. With all your crown jewel apps, your agentic AI that you’re now developing, you need to use best-in-class zero trust principles and then figure out how you can understand the risk exposure around all your existing tech stack, all those static credentials, and try and minimize to the best of your abilities the risk there.

Lalit: Look, one thing that I think C-levels do need to understand is, the auditors and the regulators are playing catch-up, right? We got hit very hard at a previous bank where the regulators were saying to us, “Do you have hard-coded credentials? Do you have passwords that you’re not cycling? Do you have monitoring controls?” And when you hit that kind of situation, then you have no way to get out of that by doing a lot of legacy remedial work. So I think if you can get in front of things and do things more strategically, show the regulators, the auditors that you are dealing with this in a holistic but strategic way, then the impact of an inevitable kind of audit point and red team finding where they find hard-coded credentials in your public repos — this is a problem that’s just guaranteed that someone will pick you up on this in the next few years, so I would urge you’ve got to get in front of it.

Diana: Thank you. Okay. Well, let’s turn to the Q&A now. I see two questions here. Do you have any Ansible modules for Teleport?

Q&A

Noah: Obviously, as we’ve seen, Teleport Machine & Workload Identity can be used as a way for Ansible to be able to authenticate and actually reach sort of the SSH host targets it wants to reach. As to whether we actually have any Ansible modules for Teleport, I’m actually less sure. I know that there’s definitely one floating around for sort of deploying Teleport out, but probably not something that we see too much at the moment.

Diana: Second question. Could you run through an example with Terraform Cloud touching AWS?

Noah: Yes. So this is a use case we’re actually seeing a fair bit at the moment, especially in terms of Terraform accessing any sort of cloud service provider API, right? Because, I mean, people are rightfully worried about sort of the security risks there, because where you’re going to run this Terraform needs really administrative-level access to your whole AWS or GCP account, right? So people are obviously super worried about that. And yeah, this is something that Teleport Machine & Workload Identity can solve for. We support attestations from Terraform Cloud and Spacelift, and even if you’re going to run that Terraform in a standard CI/CD provider, we support the attestations on that front there that will allow it to authenticate to Teleport secretlessly. And then what we can do with that sort of Universal Identity side is issue back that Terraform run a certificate that encodes its identity. Now, both GCP and AWS support using certificates as a form of authentication to their APIs. And then, sort of Azure, I think, at the moment, you could use the kind of JWT form of Universal Identity for it. But this is a use case that we’re kind of seeing all the time. I think, particularly when people want to get started on their Machine & Workload Identity sort of journey, the place they’re starting is sort of CI/CD and infrastructure as code, because it’s sort of the most bang for your buck. It’s pretty simple to start rolling it out, right?

Diana: And then a new question has just popped up regarding the GitHub Actions example. Is the Teleport token intended to be stored in plain text, or was it just for the demo?

Noah: 00:45:23.776 So, yeah, it’s completely — so it’s a bit of a misleading name, unfortunately. The name join token has been kind of part of Teleport for, I think, about 10 years now, and it really sort of predates the introduction of these sort of attestation methods we’ve introduced. So in the case of GitHub Actions, we support a join method, right? We support attestation there. So that token name is — that’s not a secret value at all. It’s effectively just describing a set of rules around which GitHub Actions runs are able to authenticate. So yeah, it’s actually completely fine for that to be in plain text.

Closing words

Diana: Thank you. Let me see if there are any other new questions here. I don’t see any. If you asked a question and we haven’t covered it, we’ll be sure to follow up by email after the webinar. There are a couple of additional resources that I want to point you to. One is, if you’re interested in the world of AI, we have a couple of pages on our website that speak to how you secure MCP servers and agentic AI. Lexi can post the URLs to those in the chat. Second, we have our next webinar coming up in July, touching on the topic of identity security. And this one is relevant to both identity security as it pertains to people and as it pertains to machines and workloads. And so it’s, I think, a follow-on topic that may be of interest to this audience. And then, finally, we have a brief survey at the end. It’s three questions. It’s brief. It will help us improve our content for the next time around. I’d like to thank you all for joining us today. It’s been a pleasure sharing this morning, afternoon, or evening, depending on where you are, with you, and hope to see you next month, in July.

Lalit: Thanks.