TL;DR: Teleport argues that cloud-native security is shifting toward identity as the control plane, as KubeCon Europe 2025 discussions centered on securing humans, workloads, CI/CD pipelines, AI services, and SSH access with short-lived, auditable identity instead of static credentials. The central change is that infrastructure governance now depends on verifying who or what is acting at runtime, not just hardening the resource itself.
At a glance
What this is: This article argues that identity is becoming the control plane for cloud-native infrastructure, with short-lived, auditable access replacing static secrets and opaque trust paths across workloads, pipelines, and human operators.
Why it matters: IAM, PAM, and NHI teams need this lens because cloud-native environments now fail or succeed on runtime identity governance across humans and machine identities, not on infrastructure controls alone.
By the numbers:
- Over 70% of the sessions touched on AI or machine learning workloads.
👉 Read Teleport's analysis of identity as the control plane for secure infrastructure
Context
Cloud-native infrastructure now exposes a basic governance problem: access decisions are happening faster, across more actors, and in more places than traditional IAM models were built to supervise. In this setting, the primary risk is not simply misconfiguration, but the inability to prove who or what acted at runtime.
For identity teams, the relevant shift is that the control plane is no longer just networking, policy, or orchestration. Identity has to cover human operators, service accounts, CI/CD jobs, workloads, and AI systems with short-lived, auditable access that can be governed consistently across platforms.
The KubeCon discussions reflected a maturing platform engineering model that is still carrying a blind spot around access governance. That makes this topic typical for cloud-native programmes, not an edge case.
Key questions
Q: How should security teams implement runtime security for ephemeral cloud workloads?
A: Security teams should treat runtime security as a live control plane, not a pre-deployment check. Focus on continuous monitoring of running containers and virtual machines, behavioral and anomaly detection, and automated response that can isolate compromised workloads or terminate suspicious processes. In ephemeral environments, security must follow the workload as it scales, shifts, and disappears.
Q: Why do static secrets increase risk in DevOps pipelines?
A: Static secrets remain valid far beyond the task that needed them, which creates a wider window for theft, reuse, and privilege escalation. In fast-moving pipelines, that window often outlasts the visibility teams have into where the secret was copied or cached.
Q: What are the signs that privileged infrastructure access is poorly governed?
A: Common signs include unmanaged admin interfaces, inconsistent ownership of firewall or router consoles, direct internet exposure, and patch state that is tracked separately from privileged access records. If a team cannot name who should administer the device, it is already behind on governance.
Q: How do teams balance least privilege with developer speed in cloud-native platforms?
A: Use just-in-time access with policy-controlled expiry so engineers can get the access they need for a defined task without keeping standing privilege. The key is to make temporary access easy to request, auditable, and scoped to one resource or workflow, so speed comes from orchestration rather than permanent entitlements.
Technical breakdown
Why static secrets break down in ephemeral infrastructure
Static secrets assume the actor and its permissions remain stable long enough for manual rotation, review, and cleanup. In cloud-native systems, jobs, pods, and workloads often exist only briefly, so hardcoded keys and long-lived tokens outlive the session they were meant to secure. That creates exposure windows that are wider than the execution window itself. The real mechanism problem is not just theft, but persistence: once a secret is embedded in CI/CD or a workload, it becomes reusable outside its intended runtime context. Identity-bound certificates reduce that mismatch by tying access to the actor and the session rather than to the pipeline or host.
Practical implication: treat static secrets as a structural mismatch for ephemeral workloads and move sensitive execution to short-lived identity issuance.
How short-lived identity changes workload and SSH access
Short-lived identity shifts enforcement from stored credentials to authenticated sessions. Instead of distributing SSH keys, API keys, or tokens, the platform issues time-bounded certificates or assertions linked to the actor's identity provider and policy context. That matters because the security boundary moves from possession of a reusable secret to the validity of an authenticated session. The benefit is not only reduced secret sprawl, but also tighter traceability: each access event can be associated with a specific identity, resource, and time window. This is especially important where one operator or workload touches multiple targets across clusters, VMs, and databases.
Practical implication: replace reusable access material with session-scoped identity so every privileged action is attributable and time-limited.
Why supply chain security now depends on workload identity
Software supply chain controls such as SBOMs and signed artifacts establish what was built and whether it was tampered with. But they do not answer who deployed it, which pipeline account pushed it, or whether the actor moving code into production was the one entitled to do so. That is an identity problem, not just an integrity problem. When CI/CD systems rely on shared tokens or embedded keys, trust collapses across the deployment chain because the actor performing the change is not strongly bound to the authorization event. Workload identity fills that gap by linking build and deployment actions to a governed non-human identity.
Practical implication: pair artifact integrity checks with deployment identity controls so provenance and authorization are both verified.
Threat narrative
Attacker objective: The objective is to turn reusable infrastructure access into durable control over workloads, deployment paths, or privileged operator sessions.
- Entry occurs when CI/CD pipelines, SSH workflows, or workload launch paths depend on static secrets or long-lived tokens that can be copied or reused outside the intended session.
- Credential access expands when those secrets are embedded in jobs, scripts, images, or operator habits, making them available to insiders, attackers, or unintended automation.
- Escalation follows when the same credentials grant broad access across clusters, databases, or VMs, allowing reuse beyond the original task scope.
- Impact is achieved when attackers or uncontrolled processes can act as legitimate operators, deploy workloads, or move across infrastructure without reliable session attribution.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity is now the governing plane for cloud-native infrastructure: the question is no longer whether a cluster is secure in isolation, but whether every action inside it is tied to a verifiable actor. That shifts the centre of gravity from perimeter and resource controls to runtime identity governance across humans, workloads, and automation. Practitioners should treat identity as the coordination layer that makes zero trust operational in distributed environments.
Static credential assumptions are breaking under ephemeral execution: access review, rotation, and revocation models were built for actors that persist long enough to be enumerated. Ephemeral pods, CI jobs, and short-lived services challenge that assumption because the privileged session may begin and end faster than a governance cycle can observe it. The implication is that governance must move to issuance time and session time, not only review time.
Cloud-native supply chain trust now has an identity dimension: artifact provenance is necessary, but it is not sufficient when the deployer, pipeline, or workload identity is weakly bound. The same signed artifact can be pushed by an authorised system or by a misused credential, and those two conditions are operationally different even if the output looks the same. Practitioners should govern both what is deployed and which identity is allowed to deploy it.
Infrastructure identity is becoming a prerequisite for accountable observability: logging that cannot distinguish human operators from service accounts or AI-driven automation does not produce usable governance evidence. Identity context turns raw telemetry into accountability, which is essential when the same action might be legitimate automation or an abuse of standing privilege. Security teams should treat identity correlation as a core control, not an analytics enhancement.
Shortest-lived access should be the default design assumption for non-human actors: once a workload can be issued a credential on demand, the rationale for standing privileges weakens materially. That does not eliminate governance burden; it concentrates it on policy, lifecycle, and revocation correctness. The practical conclusion is that NHI programmes must be designed around ephemeral access as the normal state, not an exception.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
- Read next: Kubernetes NHI Security Guide
What this signals
Cloud-native programmes are moving toward a model where identity, not network location or static credential possession, defines who can touch production. That change matters because the same access pattern must now govern humans, service accounts, and machine identities across clusters and pipelines.
Identity control plane: this is the practical idea that runtime identity becomes the common enforcement layer for infrastructure access, deployment authority, and auditability. Teams that still separate human IAM from workload identity will keep finding gaps between policy design and the actual actors moving through production.
Security leaders should expect more pressure to prove that privileged actions are both authorised and attributable across ephemeral environments. The governance question is no longer whether access exists, but whether access can be issued, observed, and revoked at the same speed as the workload lifecycle.
For practitioners
- Map all infrastructure access paths Inventory human logins, SSH access, CI/CD credentials, service accounts, and workload-to-workload authentication in one control view so the same actor is not governed by multiple disconnected models.
- Replace static secrets in pipelines Move build and deploy jobs to short-lived certificates or identity assertions so pipelines do not carry reusable keys that outlive the task they were created for.
- Bind privileged sessions to identity context Require an authenticated identity provider, a named resource, and an expiry window for SSH, kubectl, database, and admin access so access events stay attributable.
- Separate deployment authorization from artifact integrity Verify who is permitted to deploy in addition to verifying that the artifact is signed and intact, because provenance alone does not prove the right actor pushed it.
- Correlate observability with actor identity Ensure logs and alerts identify whether an action came from a human, service account, or workload so investigators can distinguish legitimate automation from misuse.
Key takeaways
- Cloud-native security now depends on governing runtime identity across humans, workloads, pipelines, and automation, not treating access as a separate concern.
- Static secrets and broad access paths create a governance gap because the actor can outlive the credential and the credential can outlive the session.
- The practical response is to make identity short-lived, session-bound, and auditable so access decisions stay aligned with ephemeral infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on hardcoded secrets and lingering tokens in CI/CD and infrastructure access. |
| NHI-07 — Long-Lived Secrets | Teleport's argument depends on replacing long-lived keys with short-lived, auditable identity. | |
| NHI-05 — Overprivileged NHI | The piece warns that broad SSH and infrastructure access grants too much standing privilege. | |
| Recommendation — Scan infrastructure and pipeline paths for leaked NHI secrets and remove reusable credentials from runtime access. Replace long-lived machine credentials with time-bounded access and enforce rotation or expiry by default. Reduce standing access scope for machine identities and issue only task-scoped privilege. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI/CD keys, SSH keys, and workload credentials all fall under credential lifecycle governance. |
| IA-9 — Service Identification and Authentication | The article is about authenticating workloads, pipelines, and services, not only people. | |
| Recommendation — Apply authenticator lifecycle controls to issue, rotate, expire, and revoke infrastructure credentials. Use service authentication controls to bind non-human access to named identities and approved sessions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern is reusable secrets leading to broader infrastructure access and movement. |
| Recommendation — Map secret reuse to credential access and lateral movement detections across infrastructure and pipelines. | ||
Key terms
- Infrastructure Identity: Infrastructure identity is the set of credentials and trust relationships that allow systems, workloads, and automation to authenticate to other systems. It is the machine-facing layer of identity governance, and it often carries more operational risk than human access because it is persistent and widely reused.
- Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
What's in the full article
Teleport's full post covers the operational detail this analysis intentionally leaves for the source:
- How Teleport applies short-lived certificates to SSH, kubectl, and database access in mixed infrastructure
- Examples of the platform engineer, SRE, and DevOps access problems discussed at KubeCon Europe 2025
- How the product handles CI/CD key sprawl and secrets replacement in workflow-heavy environments
- The specific access workflow used to unify multi-cloud infrastructure under one identity layer
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org