Deployments

OperationDescriptionSampleRule
get-deploymentsYY
list-deploymentsYY
watch-deploymentsYY
create-deploymentsCreates a Deployment; its pod template can carry the same securityContext/hostPath risks as a bare pod. Elastic also treats it as a post-RBAC-change workload step.YY
update-deploymentsYY
patch-deploymentsDeployment patched (sidecar injection via mutating webhook).YY
delete-deploymentsDeletes a Deployment, removing its ReplicaSet and pods. Sigma tags this as a possible data-destruction/availability attack, not just routine cleanup.YY
deletecollection-deploymentsYN
get-deployments-scaleYN
update-deployments-scaleYN
patch-deployments-scaleYN
get-deployments-statusYN
update-deployments-statusYN
patch-deployments-statusYN
any-deploymentsSynthetic aggregation for rules that filter the deployments resource with no specific verb. Not a distinct audit record; hosts rule listings that key on objectRef.resource alone.NN

get deployments

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments",
  "verb": "get",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:21.845402Z",
  "stageTimestamp": "2026-07-02T04:47:21.846709Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches list-deployments: list deployments, watch-deployments: watch deployments, create-deployments: create deployments, update-deployments: update deployments, patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

    Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

    This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

    Possible investigation steps#

    • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
    • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
    • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
    • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
    • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

    False positive analysis#

    • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
    • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

    Response and remediation#

    • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
    • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
    • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
    • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
    • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
    • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

References #

list deployments

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments?limit=500&timeout=3s",
  "verb": "list",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:21.973625Z",
  "stageTimestamp": "2026-07-02T04:47:21.975570Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-deployments: get deployments, watch-deployments: watch deployments, create-deployments: create deployments, update-deployments: update deployments, patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

    Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

    This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

    Possible investigation steps#

    • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
    • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
    • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
    • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
    • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

    False positive analysis#

    • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
    • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

    Response and remediation#

    • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
    • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
    • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
    • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
    • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
    • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

References #

watch deployments

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments?resourceVersion=1466&timeout=3s&watch=true",
  "verb": "watch",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:21.977091Z",
  "stageTimestamp": "2026-07-02T04:47:24.978554Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-deployments: get deployments, list-deployments: list deployments, create-deployments: create deployments, update-deployments: update deployments, patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

    Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

    This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

    Possible investigation steps#

    • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
    • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
    • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
    • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
    • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

    False positive analysis#

    • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
    • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

    Response and remediation#

    • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
    • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
    • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
    • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
    • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
    • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

References #

create deployments

#
Resource
deployments

Description

Creates a Deployment; its pod template can carry the same securityContext/hostPath risks as a bare pod. Elastic also treats it as a post-RBAC-change workload step.

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments?fieldManager=kubectl-create&fieldValidation=Strict",
  "verb": "create",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-scale",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 201
  },
  "requestObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-scale",
      "namespace": "dw-harn"
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn-scale"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn-scale"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {}
  },
  "responseObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-scale",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1809",
      "generation": 1,
      "creationTimestamp": "2026-07-02T04:48:58Z"
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn-scale"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn-scale"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {}
  },
  "requestReceivedTimestamp": "2026-07-02T04:48:58.955259Z",
  "stageTimestamp": "2026-07-02T04:48:58.960335Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

FieldKindValueRulesVendors
kubernetes.audit.objectRef.resource (elastic rule field)incronjobs3 ruleselastic
kubernetes.audit.objectRef.resource (elastic rule field)indaemonsets3 ruleselastic
kubernetes.audit.objectRef.resource (elastic rule field)indeployments3 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.daemonsets.create2 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.daemonsets.patch2 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.deployments.create2 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.deployments.patch2 ruleselastic
EventType (elastic rule field)inio.k8s.batch.v1.cronjobs.create2 ruleselastic
EventType (elastic rule field)inio.k8s.batch.v1.cronjobs.patch2 ruleselastic
client.user.email (elastic rule field)is_not_null2 ruleselastic
objectRef.resource (falco rule field)eqdeployments1 rulefalco

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-deployments: get deployments, list-deployments: list deployments, watch-deployments: watch deployments, update-deployments: update deployments, patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

    Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

    This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

    Possible investigation steps#

    • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
    • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
    • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
    • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
    • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

    False positive analysis#

    • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
    • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

    Response and remediation#

    • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
    • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
    • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
    • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
    • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
    • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
  • GKE Sensitive RBAC Change Followed by Workload Modification source medium: Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment.T1098, T1098.006↳ also matches patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Investigating GKE Sensitive RBAC Change Followed by Workload Modification#

    This ES|QL rule correlates two successful GKE audit behaviors from the same client.user.email within five minutes:

    1. Role or ClusterRole create/update/patch that grants high-risk permissions (wildcards, escalate / bind / impersonate, secret read, or privileged API resources such as pods/exec and serviceaccounts/token)
    2. DaemonSet, Deployment, or CronJob create or patch after the sensitive RBAC change

    Esql.rbac_to_workload_minutes is the gap from the latest sensitive RBAC event to the earliest workload modification in the lookback window.

    Possible investigation steps#

    • Review Esql.event_action_values and Esql.gcp_audit_resource_name_values for the Role/ClusterRole and workload objects touched.
    • Inspect Esql.user_agent_original_values and Esql.source_ip_values for unexpected clients or networks.
    • Check for RoleBinding or ClusterRoleBinding activity around the same identity and time window.
    • Correlate with secret access, pod exec, or token creation from the same actor.

    False positive analysis#

    • GitOps pipelines that manage both RBAC manifests and workloads in one sync cycle.
    • Platform bootstrap that patches built-in roles and reconciles addon workloads.

    Response and remediation#

    • Roll back unauthorized Role/ClusterRole and workload changes, revoke the actor's credentials, and tighten who can mutate RBAC and sensitive workloads.
  • GKE Unusual Sensitive Workload Modification source low: Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster.T1098, T1098.006↳ also matches patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Investigating GKE Unusual Sensitive Workload Modification#

    This new-terms rule alerts on the first create or patch of a DaemonSet, Deployment, or CronJob from a new combination of user_agent.original, source.ip, and client.user.email.

    Possible investigation steps#

    • Review the audit request for image, command, service account, and privileged settings changes.
    • Attribute the actor to its backing identity and validate whether the source network is expected.
    • Correlate with RBAC, secret, or exec activity from the same identity.

    False positive analysis#

    • Legitimate on-call changes from new workstations or updated kubectl versions are common in lab clusters.

    Response and remediation#

    • Roll back unauthorized workload changes, revoke the credential used, and tighten RBAC on workload controllers.

Falco #

References #

update deployments

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments?fieldManager=kubectl-replace&fieldValidation=Strict",
  "verb": "update",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=4cf95d11cbd90036bab41cdc6b88cc8f91550e9135ed4bb61495b02f647812ff"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "uid": "00000000-0000-0000-0000-000000000000",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "resourceVersion": "627"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "627",
      "generation": 1,
      "creationTimestamp": "2026-07-02T21:30:46Z",
      "labels": {
        "dw-harn-patched": "1"
      },
      "annotations": {
        "deployment.kubernetes.io/revision": "1"
      }
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {
      "observedGeneration": 1,
      "replicas": 1,
      "updatedReplicas": 1,
      "readyReplicas": 1,
      "availableReplicas": 1,
      "terminatingReplicas": 0,
      "conditions": [
        {
          "type": "Available",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:49Z",
          "reason": "MinimumReplicasAvailable",
          "message": "Deployment has minimum availability."
        },
        {
          "type": "Progressing",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:46Z",
          "reason": "NewReplicaSetAvailable",
          "message": "ReplicaSet \"dw-harn-deployments-6fc9f46dc6\" has successfully progressed."
        }
      ]
    }
  },
  "responseObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "627",
      "generation": 1,
      "creationTimestamp": "2026-07-02T21:30:46Z",
      "labels": {
        "dw-harn-patched": "1"
      },
      "annotations": {
        "deployment.kubernetes.io/revision": "1"
      }
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {
      "observedGeneration": 1,
      "replicas": 1,
      "updatedReplicas": 1,
      "readyReplicas": 1,
      "availableReplicas": 1,
      "terminatingReplicas": 0,
      "conditions": [
        {
          "type": "Available",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:49Z",
          "reason": "MinimumReplicasAvailable",
          "message": "Deployment has minimum availability."
        },
        {
          "type": "Progressing",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:46Z",
          "reason": "NewReplicaSetAvailable",
          "message": "ReplicaSet \"dw-harn-deployments-6fc9f46dc6\" has successfully progressed."
        }
      ]
    }
  },
  "requestReceivedTimestamp": "2026-07-02T21:30:50.414105Z",
  "stageTimestamp": "2026-07-02T21:30:50.417863Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-deployments: get deployments, list-deployments: list deployments, watch-deployments: watch deployments, create-deployments: create deployments, patch-deployments: patch deployments
    Investigation guide

    Triage and analysis#

    Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

    Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

    This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

    Possible investigation steps#

    • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
    • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
    • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
    • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
    • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

    False positive analysis#

    • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
    • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

    Response and remediation#

    • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
    • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
    • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
    • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
    • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
    • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

References #

patch deployments

#
Resource
deployments

Description

Deployment patched (sidecar injection via mutating webhook).

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments?fieldManager=kubectl-patch",
  "verb": "patch",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "metadata": {
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "responseObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1480",
      "generation": 1,
      "creationTimestamp": "2026-07-02T04:47:21Z",
      "labels": {
        "dw-harn-patched": "1"
      },
      "annotations": {
        "deployment.kubernetes.io/revision": "1"
      }
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {
      "observedGeneration": 1,
      "replicas": 1,
      "updatedReplicas": 1,
      "readyReplicas": 1,
      "availableReplicas": 1,
      "terminatingReplicas": 0,
      "conditions": [
        {
          "type": "Available",
          "status": "True",
          "lastUpdateTime": "2026-07-02T04:47:22Z",
          "lastTransitionTime": "2026-07-02T04:47:22Z",
          "reason": "MinimumReplicasAvailable",
          "message": "Deployment has minimum availability."
        },
        {
          "type": "Progressing",
          "status": "True",
          "lastUpdateTime": "2026-07-02T04:47:22Z",
          "lastTransitionTime": "2026-07-02T04:47:21Z",
          "reason": "NewReplicaSetAvailable",
          "message": "ReplicaSet \"dw-harn-deployments-6fc9f46dc6\" has successfully progressed."
        }
      ]
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:25.045779Z",
  "stageTimestamp": "2026-07-02T04:47:25.050825Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

FieldKindValueRulesVendors
kubernetes.audit.objectRef.resource (elastic rule field)incronjobs3 ruleselastic
kubernetes.audit.objectRef.resource (elastic rule field)indaemonsets3 ruleselastic
kubernetes.audit.objectRef.resource (elastic rule field)indeployments3 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.daemonsets.create2 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.daemonsets.patch2 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.deployments.create2 ruleselastic
EventType (elastic rule field)inio.k8s.apps.v1.deployments.patch2 ruleselastic
EventType (elastic rule field)inio.k8s.batch.v1.cronjobs.create2 ruleselastic
EventType (elastic rule field)inio.k8s.batch.v1.cronjobs.patch2 ruleselastic
client.user.email (elastic rule field)is_not_null2 ruleselastic
objectRef.resource (sigma rule field)eqdeployments1 rulesigma

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Sigma #

  • Potential Sidecar Injection Into Running Deployment source medium: Detects attempts to inject a sidecar container into a running deployment. A sidecar container is an additional container within a pod, that resides alongside the main container. One way to add containers to running resources like Deployments/DeamonSets/StatefulSets, is via a "kubectl patch" operation. By injecting a new container within a legitimate pod, an attacker can run their code and hide their activity, instead of running their own separated pod in the cluster.T1609

Elastic #

  • Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-deployments: get deployments, list-deployments: list deployments, watch-deployments: watch deployments, create-deployments: create deployments, update-deployments: update deployments
    Investigation guide

    Triage and analysis#

    Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

    Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

    This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

    Possible investigation steps#

    • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
    • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
    • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
    • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
    • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

    False positive analysis#

    • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
    • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

    Response and remediation#

    • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
    • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
    • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
    • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
    • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
    • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
  • GKE Sensitive RBAC Change Followed by Workload Modification source medium: Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment.T1098, T1098.006↳ also matches create-deployments: create deployments
    Investigation guide

    Triage and analysis#

    Investigating GKE Sensitive RBAC Change Followed by Workload Modification#

    This ES|QL rule correlates two successful GKE audit behaviors from the same client.user.email within five minutes:

    1. Role or ClusterRole create/update/patch that grants high-risk permissions (wildcards, escalate / bind / impersonate, secret read, or privileged API resources such as pods/exec and serviceaccounts/token)
    2. DaemonSet, Deployment, or CronJob create or patch after the sensitive RBAC change

    Esql.rbac_to_workload_minutes is the gap from the latest sensitive RBAC event to the earliest workload modification in the lookback window.

    Possible investigation steps#

    • Review Esql.event_action_values and Esql.gcp_audit_resource_name_values for the Role/ClusterRole and workload objects touched.
    • Inspect Esql.user_agent_original_values and Esql.source_ip_values for unexpected clients or networks.
    • Check for RoleBinding or ClusterRoleBinding activity around the same identity and time window.
    • Correlate with secret access, pod exec, or token creation from the same actor.

    False positive analysis#

    • GitOps pipelines that manage both RBAC manifests and workloads in one sync cycle.
    • Platform bootstrap that patches built-in roles and reconciles addon workloads.

    Response and remediation#

    • Roll back unauthorized Role/ClusterRole and workload changes, revoke the actor's credentials, and tighten who can mutate RBAC and sensitive workloads.
  • GKE Unusual Sensitive Workload Modification source low: Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster.T1098, T1098.006↳ also matches create-deployments: create deployments
    Investigation guide

    Triage and analysis#

    Investigating GKE Unusual Sensitive Workload Modification#

    This new-terms rule alerts on the first create or patch of a DaemonSet, Deployment, or CronJob from a new combination of user_agent.original, source.ip, and client.user.email.

    Possible investigation steps#

    • Review the audit request for image, command, service account, and privileged settings changes.
    • Attribute the actor to its backing identity and validate whether the source network is expected.
    • Correlate with RBAC, secret, or exec activity from the same identity.

    False positive analysis#

    • Legitimate on-call changes from new workstations or updated kubectl versions are common in lab clusters.

    Response and remediation#

    • Roll back unauthorized workload changes, revoke the credential used, and tighten RBAC on workload controllers.

References #

delete deployments

#
Resource
deployments

Description

Deletes a Deployment, removing its ReplicaSet and pods. Sigma tags this as a possible data-destruction/availability attack, not just routine cleanup.

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments",
  "verb": "delete",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "status": "Success",
    "details": {
      "name": "dw-harn-deployments",
      "group": "apps",
      "kind": "deployments",
      "uid": "00000000-0000-0000-0000-000000000000"
    },
    "code": 200
  },
  "requestObject": {
    "kind": "DeleteOptions",
    "apiVersion": "meta.k8s.io/__internal",
    "propagationPolicy": "Background"
  },
  "responseObject": {
    "kind": "Status",
    "apiVersion": "v1",
    "metadata": {},
    "status": "Success",
    "details": {
      "name": "dw-harn-deployments",
      "group": "apps",
      "kind": "deployments",
      "uid": "00000000-0000-0000-0000-000000000000"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:25.111184Z",
  "stageTimestamp": "2026-07-02T04:47:25.114264Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

FieldKindValueRulesVendors
objectRef.resourceeqdeployments2 rulesfalco, sigma
verbeqdelete2 rulesfalco, sigma

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Sigma #

Falco #

References #

deletecollection deployments

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments?labelSelector=dw-harn-patched",
  "verb": "deletecollection",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=3ffde68ef687218e01296d94b0aa59c81cc98de2bd73ab70e21510c8cd4b9cec"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "apiGroup": "apps",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "responseObject": {
    "kind": "DeploymentList",
    "apiVersion": "apps/v1",
    "metadata": {
      "resourceVersion": "723"
    },
    "items": [
      {
        "metadata": {
          "name": "dw-harn-deployments",
          "namespace": "dw-harn",
          "uid": "00000000-0000-0000-0000-000000000000",
          "resourceVersion": "723",
          "generation": 2,
          "creationTimestamp": "2026-07-02T23:12:47Z",
          "labels": {
            "dw-harn-patched": "1"
          },
          "annotations": {
            "deployment.kubernetes.io/revision": "1"
          }
        },
        "spec": {
          "replicas": 2,
          "selector": {
            "matchLabels": {
              "app": "dw-harn"
            }
          },
          "template": {
            "metadata": {
              "labels": {
                "app": "dw-harn"
              }
            },
            "spec": {
              "containers": [
                {
                  "name": "c",
                  "image": "docker.io/library/busybox:1.36",
                  "command": [
                    "sh",
                    "-c",
                    "sleep 3600"
                  ],
                  "resources": {},
                  "terminationMessagePath": "/dev/termination-log",
                  "terminationMessagePolicy": "File",
                  "imagePullPolicy": "IfNotPresent"
                }
              ],
              "restartPolicy": "Always",
              "terminationGracePeriodSeconds": 0,
              "dnsPolicy": "ClusterFirst",
              "securityContext": {},
              "schedulerName": "default-scheduler"
            }
          },
          "strategy": {
            "type": "RollingUpdate",
            "rollingUpdate": {
              "maxUnavailable": "25%",
              "maxSurge": "25%"
            }
          },
          "revisionHistoryLimit": 10,
          "progressDeadlineSeconds": 600
        },
        "status": {
          "observedGeneration": 2,
          "replicas": 2,
          "updatedReplicas": 2,
          "readyReplicas": 1,
          "availableReplicas": 1,
          "unavailableReplicas": 1,
          "terminatingReplicas": 0,
          "conditions": [
            {
              "type": "Progressing",
              "status": "True",
              "lastUpdateTime": "2026-07-02T23:12:50Z",
              "lastTransitionTime": "2026-07-02T23:12:47Z",
              "reason": "NewReplicaSetAvailable",
              "message": "ReplicaSet \"dw-harn-deployments-6fc9f46dc6\" has successfully progressed."
            },
            {
              "type": "Available",
              "status": "False",
              "lastUpdateTime": "2026-07-02T23:12:51Z",
              "lastTransitionTime": "2026-07-02T23:12:51Z",
              "reason": "MinimumReplicasUnavailable",
              "message": "Deployment does not have minimum availability."
            }
          ]
        }
      }
    ]
  },
  "requestReceivedTimestamp": "2026-07-02T23:12:52.048233Z",
  "stageTimestamp": "2026-07-02T23:12:52.052924Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

get deployments/scale

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments/scale",
  "verb": "get",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=fd038e49e5a46840f8f58360c3f09257f92bccd0cadad3ad68fcfec20b99b52c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "subresource": "scale"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T22:12:02.626854Z",
  "stageTimestamp": "2026-07-02T22:12:02.628437Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

update deployments/scale

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments/scale",
  "verb": "update",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=2f9bb39ae9e6831406f8ad02206bf46e69b5760f7adffe5feb860da290b80a7e"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "uid": "00000000-0000-0000-0000-000000000000",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "resourceVersion": "672",
    "subresource": "scale"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "kind": "Scale",
    "apiVersion": "autoscaling/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "672",
      "creationTimestamp": "2026-07-03T00:14:19Z"
    },
    "spec": {
      "replicas": 1
    },
    "status": {
      "replicas": 1,
      "selector": "app=dw-harn"
    }
  },
  "responseObject": {
    "kind": "Scale",
    "apiVersion": "autoscaling/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "673",
      "creationTimestamp": "2026-07-03T00:14:19Z"
    },
    "spec": {
      "replicas": 1
    },
    "status": {
      "replicas": 1,
      "selector": "app=dw-harn"
    }
  },
  "requestReceivedTimestamp": "2026-07-03T00:14:23.246282Z",
  "stageTimestamp": "2026-07-03T00:14:23.262536Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

patch deployments/scale

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-scale/scale",
  "verb": "patch",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-scale",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "subresource": "scale"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "spec": {
      "replicas": 2
    }
  },
  "responseObject": {
    "kind": "Scale",
    "apiVersion": "autoscaling/v1",
    "metadata": {
      "name": "dw-harn-scale",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1822",
      "creationTimestamp": "2026-07-02T04:48:58Z"
    },
    "spec": {
      "replicas": 2
    },
    "status": {
      "replicas": 1,
      "selector": "app=dw-harn-scale"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:48:59.034760Z",
  "stageTimestamp": "2026-07-02T04:48:59.037805Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

get deployments/status

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-scale/status",
  "verb": "get",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-scale",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "subresource": "status"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:48:59.102544Z",
  "stageTimestamp": "2026-07-02T04:48:59.103578Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

update deployments/status

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-deployments/status?fieldManager=kubectl-replace&fieldValidation=Strict",
  "verb": "update",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=4cf95d11cbd90036bab41cdc6b88cc8f91550e9135ed4bb61495b02f647812ff"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-deployments",
    "uid": "00000000-0000-0000-0000-000000000000",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "resourceVersion": "627",
    "subresource": "status"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "627",
      "generation": 1,
      "creationTimestamp": "2026-07-02T21:30:46Z",
      "labels": {
        "dw-harn-patched": "1"
      },
      "annotations": {
        "deployment.kubernetes.io/revision": "1"
      }
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {
      "observedGeneration": 1,
      "replicas": 1,
      "updatedReplicas": 1,
      "readyReplicas": 1,
      "availableReplicas": 1,
      "terminatingReplicas": 0,
      "conditions": [
        {
          "type": "Available",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:49Z",
          "reason": "MinimumReplicasAvailable",
          "message": "Deployment has minimum availability."
        },
        {
          "type": "Progressing",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:46Z",
          "reason": "NewReplicaSetAvailable",
          "message": "ReplicaSet \"dw-harn-deployments-6fc9f46dc6\" has successfully progressed."
        }
      ]
    }
  },
  "responseObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-deployments",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "627",
      "generation": 1,
      "creationTimestamp": "2026-07-02T21:30:46Z",
      "labels": {
        "dw-harn-patched": "1"
      },
      "annotations": {
        "deployment.kubernetes.io/revision": "1"
      }
    },
    "spec": {
      "replicas": 1,
      "selector": {
        "matchLabels": {
          "app": "dw-harn"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {
      "observedGeneration": 1,
      "replicas": 1,
      "updatedReplicas": 1,
      "readyReplicas": 1,
      "availableReplicas": 1,
      "terminatingReplicas": 0,
      "conditions": [
        {
          "type": "Available",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:49Z",
          "reason": "MinimumReplicasAvailable",
          "message": "Deployment has minimum availability."
        },
        {
          "type": "Progressing",
          "status": "True",
          "lastUpdateTime": "2026-07-02T21:30:49Z",
          "lastTransitionTime": "2026-07-02T21:30:46Z",
          "reason": "NewReplicaSetAvailable",
          "message": "ReplicaSet \"dw-harn-deployments-6fc9f46dc6\" has successfully progressed."
        }
      ]
    }
  },
  "requestReceivedTimestamp": "2026-07-02T21:30:50.583012Z",
  "stageTimestamp": "2026-07-02T21:30:50.586522Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

patch deployments/status

#
Resource
deployments

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/apps/v1/namespaces/dw-harn/deployments/dw-harn-scale/status?fieldManager=kubectl-patch",
  "verb": "patch",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "deployments",
    "namespace": "dw-harn",
    "name": "dw-harn-scale",
    "apiGroup": "apps",
    "apiVersion": "v1",
    "subresource": "status"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "status": {
      "observedGeneration": 1
    }
  },
  "responseObject": {
    "kind": "Deployment",
    "apiVersion": "apps/v1",
    "metadata": {
      "name": "dw-harn-scale",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1835",
      "generation": 2,
      "creationTimestamp": "2026-07-02T04:48:58Z",
      "annotations": {
        "deployment.kubernetes.io/revision": "1"
      }
    },
    "spec": {
      "replicas": 2,
      "selector": {
        "matchLabels": {
          "app": "dw-harn-scale"
        }
      },
      "template": {
        "metadata": {
          "labels": {
            "app": "dw-harn-scale"
          }
        },
        "spec": {
          "containers": [
            {
              "name": "c",
              "image": "docker.io/library/busybox:1.36",
              "command": [
                "sh",
                "-c",
                "sleep 3600"
              ],
              "resources": {},
              "terminationMessagePath": "/dev/termination-log",
              "terminationMessagePolicy": "File",
              "imagePullPolicy": "IfNotPresent"
            }
          ],
          "restartPolicy": "Always",
          "terminationGracePeriodSeconds": 0,
          "dnsPolicy": "ClusterFirst",
          "securityContext": {},
          "schedulerName": "default-scheduler"
        }
      },
      "strategy": {
        "type": "RollingUpdate",
        "rollingUpdate": {
          "maxUnavailable": "25%",
          "maxSurge": "25%"
        }
      },
      "revisionHistoryLimit": 10,
      "progressDeadlineSeconds": 600
    },
    "status": {
      "observedGeneration": 1,
      "replicas": 2,
      "updatedReplicas": 2,
      "unavailableReplicas": 2,
      "terminatingReplicas": 0,
      "conditions": [
        {
          "type": "Available",
          "status": "False",
          "lastUpdateTime": "2026-07-02T04:48:58Z",
          "lastTransitionTime": "2026-07-02T04:48:58Z",
          "reason": "MinimumReplicasUnavailable",
          "message": "Deployment does not have minimum availability."
        },
        {
          "type": "Progressing",
          "status": "True",
          "lastUpdateTime": "2026-07-02T04:48:59Z",
          "lastTransitionTime": "2026-07-02T04:48:58Z",
          "reason": "ReplicaSetUpdated",
          "message": "ReplicaSet \"dw-harn-scale-55c74cf7c9\" is progressing."
        }
      ]
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:48:59.104732Z",
  "stageTimestamp": "2026-07-02T04:48:59.112440Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

any verb on deployments (synthetic aggregation)

#
Resource
deployments

Description

Synthetic aggregation for rules that filter the deployments resource with no specific verb. Not a distinct audit record; hosts rule listings that key on objectRef.resource alone.