DC0019: Pod Creation

The initial deployment or instantiation of a new pod in a containerized environment. This includes creating a pod manually, through orchestration tools (Kubernetes), or via Infrastructure-as-Code (IaC) configurations. A Pod is the smallest deployable unit in Kubernetes, typically containing one or more containers. Creation methods include: - Direct pod deployment (`kubectl run`, `kubectl apply`) - Automated deployment via CI/CD pipelines (e.g., ArgoCD, Jenkins, GitOps) - Infrastructure-as-Code (IaC) templates (e.g., Terraform, Helm Charts) - API-based deployments via Kubernetes control plane (create_pod API calls) - Pods can be ephemeral (short-lived) or persistent (part of a StatefulSet or Deployment).

*Data Collection Measures:*

- Kubernetes Audit Logs - Captures all API requests, including pod `create` events. - Kube-api server Logs - Monitors API calls related to pod deployments and modifications. Related Events: `PodSandboxChanged`, `SyncLoop`, `Created pod` - Container Runtime Logs - Logs from CRI-O, containerd, or Docker capture pod creation events. Related Events: `container start`, `container create` - Cloud Provider Logs - GKE, EKS, AKS logs provide insights into Kubernetes API interactions. - SIEM & Log Aggregation - Integrates Kubernetes logs into SIEM solutions. - EDR/XDR Solutions - Monitors container-based activity for anomalous pod creations.

EnterpriseDC0019Data ComponentObject v2.0 Modified Oct 21, 2025, 15:14 UTC (UTC+00:00)

Pod Creation is a Kubernetes/container-environment evidence point: it records when a new pod is instantiated manually, through the Kubernetes API, via CI/CD/GitOps, or from IaC such as Terraform or Helm. For leaders, this matters because pod creation is where new workload execution begins. If the organization cannot reliably explain who or what created a pod, from which pipeline or API path, and whether it was expected, SOC and incident response teams will struggle to distinguish normal deployment activity from unauthorized or risky workload introduction.

Executive priority

Prioritize this as a cloud/container logging and governance readiness question: can teams produce audit evidence for pod creation across Kubernetes audit logs, kube-api server logs, runtime logs, cloud-provider Kubernetes logs, and SIEM aggregation? The business value is faster incident triage, stronger change-control evidence, and better oversight of automated deployment paths such as CI/CD, GitOps, and IaC. Because no ATT&CK tactics or detection logic are supplied for this data component, treat it as foundational telemetry rather than a standalone risk indicator.

Technical view

Validate that pod create events are captured from the Kubernetes control plane and correlated with deployment source: kubectl activity, Kubernetes API create_pod calls, CI/CD automation, GitOps tooling, and IaC-driven changes. SOC and IR teams should confirm that short-lived ephemeral pods are retained long enough for investigation and that persistent pods created by Deployments or StatefulSets can be tied back to their controller, manifest, user, service account, or automation identity where available in local logs. ATT&CK provides collection measures but no official detection analytics, so local baselining and environment-specific allowlisting are required.

Likely telemetry

Kubernetes Audit Logs capturing pod create API requests
Kube-api server logs with events such as PodSandboxChanged, SyncLoop, and Created pod
Container runtime logs from CRI-O, containerd, or Docker with container create/start evidence
Cloud provider Kubernetes logs for GKE, EKS, or AKS API interactions where applicable
SIEM or log aggregation records ingesting Kubernetes and runtime logs

Detection direction

Confirm Kubernetes audit logging is enabled and retained for pod create events, including API-based deployments.
Correlate pod creation with expected deployment channels such as CI/CD pipelines, GitOps, kubectl, Terraform, and Helm.
Tune detections around unusual creators, namespaces, timing, source identities, or automation paths, but account for high-volume legitimate deployment activity.
Pay special attention to ephemeral pods because short lifetimes can create visibility gaps if logs are delayed, filtered, or not centralized.
Because ATT&CK supplies no official detection logic or tactic mapping, build detections from local baselines and change-management expectations rather than assuming every new pod is suspicious.

Mitigation priorities

First ensure complete collection and retention of Kubernetes audit, kube-api server, runtime, cloud-provider, and SIEM logs for pod creation.
Standardize approved deployment paths so pod creation can be traced to an authorized user, service account, pipeline, GitOps workflow, or IaC change.
Review access and automation identities that can create pods, using local IAM/Kubernetes RBAC evidence to support least-privilege decisions.
Include pod creation evidence in incident response playbooks and compliance/change-control reporting for containerized environments.
Test coverage with benign administrative and pipeline-driven pod creation events to verify telemetry arrives with the fields analysts need.

Analyst notes and limits

This object is a data component, not an ATT&CK technique. Its value is evidentiary: it helps determine whether workload instantiation in Kubernetes-like environments is observable, attributable, and reviewable. Relationship context was not supplied, so no technique-, group-, or campaign-specific conclusions should be drawn.

Platforms and tactics are not specified in the supplied ATT&CK fields, and official detection guidance is not provided. The object names Kubernetes and common collection sources, but actual coverage depends on local cluster configuration, cloud-provider logging, runtime choice, SIEM ingestion, and retention settings.

Official MITRE ATT&CK definition

Pod Creation

*Data Collection Measures:*

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 2.0
Created: Oct 20, 2021, 15:05 UTC (UTC+00:00)
Modified: Oct 21, 2025, 15:14 UTC (UTC+00:00)
Raw hash: 2265a4de3ab9ab58...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	Oct 21, 2025, 15:14 UTC (UTC+00:00)	Current bundle	`2265a4de3ab9…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
mitre-attack DC0019
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use