Get a Demo
TELEPORT MACHINE & WORKLOAD IDENTITY
Delivering and Governing Machine & Workload Identity at Runtime
Trusted by Market Leaders
The Hidden Cost of Machine Access
The hidden cost of machine access isn’t in the budget. It’s in the backlog. In one 200-service organization, platform teams spent more than 530 hours a year just managing credential drift: rotating secrets, restoring broken pipelines, and recovering from access failures no one saw coming. (Read more) The risk was silent. The debt was invisible. And the effort didn't show up in security metrics; it showed up as lost engineering time.
These workloads—CI jobs, Terraform plans, agents, and scripts—are Non-Human Identities (NHI):
Systems acting on behalf of automation, infrastructure, or code. And their access is usually wired in through config, injected at runtime, or shared across environments without clear boundaries.
Teams need a way to issue identity at runtime with the permissions required by the job, with expiration of privileges when the workload ends. Some have started down the path using Kubernetes ServiceAccounts or cloud IAM roles. Others have adopted SPIFFE, the CNCF specification for workload identity built on short-lived certificates and trust domains. But many haven’t formalized anything at all. They’re still relying on static credentials, TF_VAR hacks, and best-effort rotation scripts.
While most companies protect human users with SSO and MFA, automation still runs unauthenticated. That gap creates a silent risk, and it grows as pipelines, scripts, and deployments scale. Wherever these organizations are in the journey, the challenge is the same:
How do you deliver identity to the systems that run your infrastructure and govern it while they're live?
What is Infrastructure Identity?
Infrastructure Identity is Teleport’s approach to assigning and managing strong, cryptographic identities to all components within infrastructure—people, machines, and services—so they can authenticate and authorize access in a trusted environment without relying on static credentials or legacy perimeter-based controls.
For machines and workloads, Teleport issues a cryptographic identity at runtime, bound to the task being performed and the privileges governing authorization. Events are continuously logged for full transparency of tasks being performed. By replacing static credentials with short-lived identity tied to the workload’s context, access becomes governed by design.
Whether you’re securing a CI job, a container, or a VM agent, Infrastructure Identity provides the foundation for governing machine access in real time.
You don’t need to re-architect your platform to adopt Teleport. Infrastructure Identity layers onto what teams already run, delivering real-time access and audit without introducing new control planes or rewriting existing code.
The Two Delivery Paths of Machine & Workload Identity
Some workloads need tightly governed access with RBAC and audit. Others just need to prove who they are across clouds and enviroments. Teleport supports both through two delivery paths; most environments rely on both, and both eliminate static secrets from the access path:
Secure Access
For policy-enforced, session-audited access to protected infrastructure
Universal Identity
For cryptographic identity usable across environments (e.g., cloud APIs, mutual Transport Layer Security (mTLS), service-to-service)
MACHINE & WORKLOAD IDENTITY
Secure Access
Secure Access gives each workload an identity with built-in authorization to access protected infrastructure in a controlled, auditable way.
Teleport issues cryptographic identity at runtime, with short-lived privileges bound to job metadata like workload type, environment, or role. Authorization is designated at issuance based on policy, and every session is logged end-to-end.
This is designed for environments where you control the resource and want full governance: fine-grained Role Based Access Control (RBAC), session-level audit, time-bound access, and no lingering privileges.
This is ideal for scenarios like:
A CI pipeline running tests against a protected database without exposing it publicly
An automation agent connecting to internal infrastructure over an encrypted tunnel
A Helm deployment authenticating into a Kubernetes cluster without shared kubeconfigs. Secure Access ensures every workload is issued exactly what it needs—nothing more—and every access attempt is logged and traceable.
MACHINE & WORKLOAD IDENTITY
Universal Identity
Universal Identity gives a workload a cryptographic identity issued by Teleport that it can use across services, clouds, or trust domains.
The identity travels: it works in mTLS handshakes, cloud-native auth flows, and SPIFFE-compatible systems like IAM Roles Anywhere, service meshes, and container registries.
Unlike Secure Access, Universal Identity isn’t tied to a specific resource guardrail. It provides identity separate from authorization and is designed to integrate with external policy engines or authorization workflows that enforce access downstream.
This is ideal for scenarios like:
An application outside AWS needing to write to S3 or publish to EventBridge
A container issuing mTLS to another microservice or API
A CI/CD pipeline pushing artifacts to a container registry using its SPIFFE ID then deploying via Helm
A background job calling a third-party API that trusts SPIFFE-issued identity
Together, Universal Identity complements Secure Access—and forms the foundation of Machine & Workload Identity.
Secure Access governs how workloads reach protected systems—based on short-lived privileges at the point of access and capturing full session-level audit.
Universal Identity provides workloads with verifiable credentials they can use across clouds, services, and domains.
Whether you're securing access to infrastructure or governing cross-system communication, both identity paths are essential—and both are delivered by the same runtime model.
What is SPIFFE?
SPIFFE (Secure Production Identity Framework For Everyone) is a CNCF standard for delivering workload identity using short-lived X.509 certificates instead of secrets. It defines SVIDs (SPIFFE Verifiable Identity Documents), trust domains, and a spec for mutual TLS authentication between workloads.
Think of it as a model — not a product. SPIFFE doesn’t enforce access or manage workloads. It defines how identity should work.
Teleport implements the SPIFFE model end-to-end, and extends it with:
Dynamic delivery for CI jobs, agents, and scripts
Native audit, least-privileged enforcement, and cross-environment support
A single CA for both universal and runtime identity
NHI Lifecycle Across Common Use Cases
NHI Lifecycle Across Common Use Cases
| Use Case | Legacy Pattern | What Teleport Delivers | Team Impact |
|---|---|---|---|
CI/CD job (e.g. GitHub Actions) | Long-lived secrets injected at runtime | ✅ Runtime-issued cert bound to job metadata | No more static tokens in CI; identity expires with every run |
Terraform plan / apply | Vault tokens or TF_VAR hacks | ✅ Cert issued pre-plan, tied to stack metadata and TTL | Removes vault plumbing and key sprawl across environments |
Kubernetes workload | Shared ServiceAccount JWTs | ✅ Runtime-issued identity via tbot, policy-bound and auditable | Removes over-permissioned tokens; enables workload-level policy |
Cloud VM / EC2 instance | Embedded IAM roles, static keys | ✅ Identity bootstrapped from instance metadata | Removes need for embedded keys; still gets cloud-native identity |
systemd agent / long-lived script | Long-lived API keys, unmanaged credentials | ✅ Certs via persistent tbot, auto-refreshed | Credentials don’t persist between sessions; no SSH key drift |
Policy enforcement | Manual via scripts or config sprawl | ✅ RBAC/ABAC enforced at cert issuance | No more implicit access; job-level permissions are enforced through workload identity at cert issuance |
Audit and revocation | Partial; logs inferred post-hoc | ✅ Session-level audit and cryptographic identity | Every access attempt is logged, short-lived privileges expire |
Secrets lifecycle | Static, rotated manually | ✅ No secrets in runtime path | No more rotation playbooks; nothing left behind |
Machine & Workload Identity in Practice
Most teams already have automation in place. CI pipelines, Terraform plans, Kubernetes clusters, agents on VMs. But machine/workload access is still wired together with static secrets: hardcoded tokens, shared kubeconfigs, embedded keys, and brittle rotation scripts.
Infrastructure Identity replaces that model with cryptographic identity issued at runtime with ephemeral privileges.It eliminates static credentials and makes identity the foundation of machine access, not an afterthought.
Teleport serves as the system of record for machine and workload identities, evaluating workload context, issuing short-lived certificates, and enforcing policies at runtime. This includes metadata like job type, environment, repository, and system role, all factored into the authorization each workload receives.
The tbot binary is a lightweight agent that runs wherever the job runs: inside a CI runner, alongside a Terraform plan, on a VM, or in a Kubernetes pod, and handles short-lived certificate requests at runtime based on workload context and Teleport policy.
tbot authenticates the workload to Teleport, requests an identity based on its context, and receives a short-lived certificate issued according to policy.
Depending on how the workload runs, Teleport issues identity aligned to one of the two paths:
Secure Access — secure access to protected infrastructure based on cryptographic identity and short-lived privileges, backed by audit
Universal Identity — cryptographic identity usable across clouds, services, and trust domains
With this model:
Identity is issued when the job runs, not pre-baked into configuration
Access is governed by what the job is doing, not just where it runs
Nothing is static; everything is auditable
There’s no pre-registration, no static credentials, and no sidecars required.
tbot becomes a runtime primitive, delivered just in time, bounded by design, and governed end to end.
How Teleport Delivers Real-World Secure Access and Universal Identity
How Teleport Delivers Real-World Secure Access and Universal Identity
| Environment / Flow | Identity Bound To | Credential Replaced | How It Works In Teleport | Example Scenario |
|---|---|---|---|---|
CI/CD pipeline (chained) | SPIFFE ID for registry, policy for cluster access | Docker login tokens, kubeconfig | tbot fetches SPIFFE ID to push image, then cert for Helm deploy | Pipeline pushes image to AWS ECR using SPIFFE ID, then deploys to K8s securely |
Terraform plan + internal API call | Stack metadata for API call, job metadata for infra apply | Vault tokens, TF_VAR, API keys | tbot issues identity for cloud API auth + policy-bound cert for infra change | Terraform applies config + calls internal API with identity—no tokens or secrets |
Agent running on VM | VM instance metadata, agent role, internal RBAC | IAM roles, SSH keys | tbot daemon fetches SPIFFE ID for cloud access + cert for protected infra | Agent fetches object from S3, then syncs with internal DB over Secure Access |
Microservice deployment | Pod workload identity, mTLS endpoint trus IAM roles, static keys | Shared ServiceAccount, TLS keys | tbot fetches SPIFFE ID for service mTLS + cert for Secure Access inside mesh | Pod authenticates to external API via mTLS, connects to DB via Secure Access |
Cron job triggering internal workflow | Cron context, service boundary enforcement | Hardcoded secrets, static SSH | tbot invoked at job start to issue both reusable ID and scoped access | Cron job triggers remote workflow + reports results to a cloud API using identity |
The identity path depends on how that identity will be used: Secure Access when access needs to be enforced and audited, Universal Identity when it needs to be portable and verifiable.
Whether the workload is federated or ephemeral, containerized or legacy, the delivery is the same: short-lived identity, governed by design.
Infrastructure Identity eliminates static credentials—without having to refactor.
Adopting Machine & Workload Identity Without a Refactor
You don’t need a platform rewrite to adopt Machine & Workload Identity.
You just need a goal, a use case to start, and a path to scale:
STEP ONE
Define Your Goal
Start by getting clear on what you’re solving for.
This will shape where you start and how you justify the investment
Are you:
Replacing long-lived secrets?
Reducing access drift or audit gaps?
Unblocking cloud-native authorization?
Making CI/CD safer or more portable?
STEP TWO
Start with a Simple, Bounded Use Case
Pick a system with high exposure and low dependencies.
Each of these good first candidates can receive identity from tbot without changing your platform or rewriting your code:
A CI pipeline calling a cloud API (e.g. GitHub Actions → S3)
Terraform applying infra in a new environment
A systemd agent or automation runner connecting to protected infra
STEP THREE
Scale Through Repeatability
Once you’ve validated the pattern, scale it by codifying it.
Teleport empowers teams to speed up delivery, secure automation, and improve governance. It layers identity on top of the infrastructure you already run—with delivery, enforcement, and audit built in.
Define RBAC roles by workload type or repo
Set TTLs and enforce policy at issuance
Add audit tagging tied to job metadata
Replace static credentials incrementally—one surface at a time
Ready to Adopt Machine & Workload Identity?
Teleport Machine & Workload Identity replaces secrets with short-lived, cryptographic identity delivered through Universal Identity or Secure Access, with ephemeral privileges issued at runtime, and auditable end to end—so teams can eliminate policy drift, reduce manual access toil, and govern every workload.
Secure your CI pipelines
Replace injected secrets with least-privileged, short-lived identity—no sidecars, no long-lived tokens.
Apply Terraform with cert-based access
Run bot as a per-plan hook and eliminate TF_VAR hacks and Vault tokens.
Enable service-to-service mTLS
Use Universal Identity to issue certs for cross-service auth, including outside your mesh.
Lock down internal infrastructure
Use Secure Access to enforce RBAC and session-level audit for agents, scripts, and legacy systems.
Build your identity layer
Map where machine access is ungoverned today—and replace secrets surface by surface.
Talk to us
Show us your architecture. We'll help you get started without a refactor.