Pod

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.

Extracting a list of running or existing pods within a containerized cluster environment. Pods are the smallest deployable units in a Kubernetes cluster and typically represent an application or workload. Enumeration of pods provides insight into the structure and state of applications running in the cluster, such as the names of pods, their namespaces, and their associated metadata.

Data Collection Measures:

• Kubernetes API Server Audit Logs:
  • Enable Audit Logging in Kubernetes to capture API requests, such as GET /api/v1/pods.
• Container Runtime Logs:
  • Collect runtime-level logs from tools like CRI-O, containerd, or Docker, which might show relevant API calls for pod enumeration.
• EDR and SIEM:
  • Endpoint Detection and Response (EDR) tools, if configured with cluster-level visibility, can monitor user commands like kubectl get pods.
  • SIEM platforms (e.g., Splunk) can ingest Kubernetes API logs to detect enumeration patterns.
• Host-Based Monitoring:
  • Monitor processes and commands executed on nodes where kubectl is installed using tools like auditd, Sysmon for Linux, or kernel modules.

Changes made to a pod’s configuration or control data within a containerized cluster. This can include updating settings such as resource limits, environment variables, annotations, labels, or even the containers running within the pod. Pod modifications are often executed using commands like kubectl set, kubectl patch, or kubectl edit.

Data Collection Measures:

• Kubernetes API Server Audit Logs:
  • Capture all API calls related to pod modification, such as PATCH, PUT, or UPDATE methods on v1/pods.
• Runtime Security Tools:
  • Tools like Falco, Sysdig, and Kube-bench can monitor pod modifications at runtime and alert on policy violations.
• Container Orchestration Logs:
  • Monitor events logged by Kubernetes itself (e.g., kubectl logs -n kube-system kube-controller-manager).
• SIEM and EDR Solutions:
  • Use SIEM platforms (e.g., Splunk) to aggregate API server logs and detect patterns of unauthorized or suspicious pod modifications.
  • Endpoint Detection and Response (EDR) tools configured with container visibility can monitor commands like kubectl set or kubectl patch.
• Host-Based Monitoring:
  • Collect and analyze logs for processes executing kubectl commands or interacting with Kubernetes configuration files (e.g., .kube/config).