Kubernetes User Exec into Podedit

This rule detects a user attempt to establish a shell session into a pod using the exec command. Using the exec command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets.

Rule type: query

Rule indices:

  • logs-kubernetes.*

Severity: medium

Risk score: 47

Runs every: 5 minutes

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100



  • Elastic
  • Kubernetes
  • Continuous Monitoring
  • Execution

Version: 3 (version history)

Added (Elastic Stack release): 8.3.0

Last modified (Elastic Stack release): 8.4.0

Rule authors: Elastic

Rule license: Elastic License v2

Potential false positivesedit

An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} — ${CMD} ${ARG1} ${ARG2} …​ ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra — sh

Investigation guideedit

Rule queryedit

kubernetes.audit.objectRef.resource:"pods" and

Threat mappingedit


Rule version historyedit

Version 3 (8.4.0 release)
  • Updated query, changed from:

    event.dataset:"kubernetes.audit_logs" and
    kubernetes.audit.objectRef.resource:"pods" and