Logs don't mean a thing: Unraveling IaC-Managed Identity Ownership

Logs Don't Mean a Thing: Unraveling IaC-Managed Identity Ownership

Speakers: Dan Abramov; Eliav Livneh

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=DCZtNldY5iI

Overview

Dan Abramov and Eliav Livneh, both security researchers at Token Security, presented a creative and entertaining exploration of a deceptively hard problem in cloud identity management: determining the actual human owner of a machine identity created through Infrastructure as Code (IaC). Framed as a game show called "Who is the Owner?", the talk addressed the fundamental gap that emerges when cloud audit logs show Terraform or another IaC engine as the creator of a service account rather than a responsible human being. In incident response scenarios where a compromised identity must be quickly rotated or suspended, knowing who to call is not optional — it is operationally critical.

Background

▶ Watch: The SOC alert scenario: who do you call when a service account is compromised? (1:00)

In traditional cloud environments, determining identity ownership is straightforward. You examine CloudTrail logs, find the creation or management events for an identity, and identify the human actor. If Michael created a role and Andrew updated it, those are your owners. But the rise of IaC tools like Terraform, Pulumi, and CloudFormation has introduced a layer of abstraction that breaks this simple chain. When Terraform creates a role, the actor recorded in CloudTrail is not a human — it is the IaC automation itself.

The problem is compounded by the dynamic nature of IaC code. Identity names are rarely hardcoded as simple strings. Instead, they are assembled through templates, modules, environment-specific variable files, and CI/CD configuration YAML files. A single identity like data-ingester-production might trace its definition across four or more different files: a reusable module, an environment configuration, a project-level Terraform file, and a CI/CD pipeline config. Finding the owners means finding the humans who authored and modified all of those files — a problem that scales poorly.

Non-human identities (NHIs) are particularly vulnerable to this gap because they are inherently decentralized, scattered across platforms, and managed by diverse teams throughout an organization. Unlike human identities that typically flow from a centralized HRIS through an IDP, machine identities have no single authoritative registry of ownership.

Key Findings

▶ Watch: Four files needed to create one identity — the code complexity problem (5:30)

The Token Security team evaluated three distinct approaches to solving the identity ownership problem, each with different trade-offs:

Execution-Based Approach (Tags): Clone the IaC repository, inject tags into every resource declaration that record which files contributed to each identity's creation, then execute a Terraform plan to observe the mapping. This produces excellent file-to-identity attribution but requires actually running the IaC engine against the target environment — a significant drawback for a security vendor that cannot interact with customer environments.

Log-Based Approach (Correlation): Correlate CloudTrail management events with CI/CD pipeline logs. When a role creation appears in CloudTrail at a given timestamp, search pipeline run logs from the same time window for the identity name, then trace that pipeline run back to its triggering pull request and commit author. This approach is entirely agnostic to the IaC platform, CI/CD system, and cloud provider. Its weakness is dependency on log retention periods for both the CSP and the CI/CD platform.

Advanced Code Analysis (LLM): Feed all relevant IaC code, state files, and CI/CD configs into an LLM engine to follow the name-templating logic and map identities to source files. While promising in theory, the team reported significant hallucination problems and insufficient accuracy to rely on in production.

Technical Deep Dive

▶ Watch: Contestant 2: Log-based correlation between CloudTrail and CI/CD pipelines (11:30)

The log-based correlation method, which the team ultimately selected as their winner, works through a multi-step pipeline. First, a management event is identified in CloudTrail showing an identity creation by Terraform at a specific timestamp. Using the GitHub API (or equivalent), the system programmatically searches through all CI/CD pipeline runs that occurred in the surrounding time window. It scans the pipeline output logs for the exact identity name that appeared in the CloudTrail event.

When a match is found — confirmed by both identity name and timestamp alignment — the system traces the pipeline run to its triggering pull request. The PR author is then designated as the owner. The actual causal chain runs in reverse: a developer creates a PR, which triggers a pipeline, which runs Terraform, which creates the identity in AWS.

For the execution-based approach, the team leveraged the tags feature available on most cloud resources. By creating a modified copy of the IaC repository with injected tags — each tag recording the source file name — they could execute a plan and observe which files contributed to each identity. This provided rich attribution data including module files, environment configurations, and CI/CD config files.

The team also noted that even outside log retention windows, the API creation timestamps on identities can provide partial ownership signals, since the API returns when an identity was originally created regardless of log availability.

Demo / Proof of Concept

▶ Watch: Contestant 3: LLM-based code analysis and its hallucination problems (14:30)

The talk did not include a live technical demo. However, the speakers walked through concrete examples using real AWS CloudTrail events and GitHub API data to illustrate how their log-based correlation pipeline operates in practice. They showed a specific example where a sales-app role creation in CloudTrail was matched to a specific pipeline run, which was traced to a pull request authored by DevOps-Snake-9.

Defensive Implications

▶ Watch: Q&A: Using API creation timestamps outside retention windows (20:00)

Organizations should recognize that IaC-managed identity ownership is a critical gap in their incident response capability. When a service account is compromised, the clock is ticking and there is no time to manually trace code archaeology across multiple repositories.

Defenders should consider implementing one or more of the approaches discussed: for organizations that control their own environments, the tag-injection approach is immediately actionable and can be baked into CI/CD pipelines. For security vendors or teams evaluating third-party environments, the log-based correlation approach provides broad coverage without environment interaction.

Critically, organizations should extend their log retention policies — both for cloud provider logs and CI/CD platform logs — as the intersection of these retention windows directly limits the ability to perform historical ownership attribution. Some CI/CD platforms have surprisingly short default retention periods.

Key Takeaways

• IaC breaks the ownership chain: When Terraform creates an identity, CloudTrail cannot tell you which human is responsible, turning a simple lookup into a multi-artifact investigation.
• No single artifact solves the problem: The team needed to combine CSP logs, CI/CD logs, pipeline metadata, and code repository data to achieve reliable ownership attribution.
• Log-based correlation is the most portable approach: It works across any IaC platform, CI/CD system, and cloud provider without requiring execution against target environments.
• Log retention is the critical limiting factor: Organizations should maximize retention on both CSP and CI/CD logs; the overlap window is the effective coverage window.
• LLM-based code analysis has promise but is not production-ready: Hallucination and incorrect file-to-identity linkages remain unsolved challenges.
• API creation timestamps provide a fallback: Even outside retention windows, identity creation dates from the cloud API can offer partial attribution signals.

About the Speaker(s)

Dan Abramov is a security researcher at Token Security (and emphatically not the React developer of the same name). He is also a musician who plays piano and saxophone. Eliav Livneh is also a security researcher at Token Security, a cycling enthusiast, and notably a fan of rocks and Taylor Swift piano covers on YouTube. Both researchers focus on non-human identity security and the challenges of machine identity management in cloud environments.