Pod Creation — Detection Telemetry

Collection and providers

Include create on pods in the audit policy; retain namespace, requesting user and response code, and join runtime evidence for actual startup.

• Kubernetes API audit: Who requested a resource action and how the API server handled it.
• Managed Kubernetes audit exports: Provider-managed equivalent when control-plane flags are not customer-configurable.

Configuration

• Configure a lab audit policy and log/webhook backend, or the managed service audit export. Start with Metadata for the required verbs/resources and namespace.
• Add narrowly scoped Request or RequestResponse only when bodies are required; secrets and tokens can leak into audit data.
• Keep auditID, stage, user, verb, objectRef, sourceIPs and responseStatus. Correlate API requests with scheduler, kubelet or runtime state before asserting execution.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    namespaces: ["lab"]
    verbs: ["create"]
    resources:
      - group: ""
        resources: ["pods"]
  - level: None

This intentionally narrow teaching policy is not a production audit baseline. A self-managed API server also needs an audit policy file and log/webhook backend; managed services expose provider-specific controls. Do not replace an existing broader policy with this example.

Synthetic event example

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0019",
  "collector": "illustrative-lab-collector",
  "observation": {
    "verb": "create",
    "resource": "pods",
    "namespace": "lab",
    "name": "demo-pod",
    "response_code": 201
  }
}

Visibility and validation

An API create request does not prove a container ran. Audit stage and response code matter. Pod logs and API audit logs serve different purposes.

• Record the lab scope, collector version, effective configuration and expected source fields before testing.
• Use an approved benign action or read-only snapshot appropriate to this type. For destructive, privileged or physical effects, use a reviewed fixture or existing authorized evidence instead of causing the effect.
• Verify the native source record locally and at the collector; compare timestamps, identity, object, action/result and the type-specific fields listed below. Save a redacted real capture separately from the synthetic example.
• Check a normal baseline and collector-loss case. Fixture parsing proves parser behavior only; it does not prove sensor coverage or malicious-behavior detection.

Primary sources

• Kubernetes audit policies and backends