Difficulty: easy
Estimated Time: 15 minutes

Sysdig's Kubernetes Activity Auditing provides a chronological sequence of user and/or system activity on your Kubernetes cluster. This information can be used to investigate the actions taken, either by a Kubernetes user or by the system, at a specific point in time, perhaps of any security policy event. For example, it could be used to trace a 'kubectl exec' user interaction and correlate that with all the commands and network activity that occurred inside the container, hence allowing the operator to trace this activity back to a user identity.

It allows cluster administrator to answer the following questions:

  • What happened? (i.e. resource was created, listed, modified, deleted)
  • When did it happen?
  • Who initiated it (Kubernetes user or software service account)?
  • On what Kubernetes resource did it happen?

This feature is critical, not only for traceability and compliance reasons, but also to aid fast incidence response.

Activity Audit Forensics

Step 1 of 5

What is Kubernetes Activity Audit

Sysdig Secure Activity Audit parses the live stream of Kubernetes audit information and applies runtime security rules to its events.

All activity is mapped against specific Kubernetes metadata, such as namespace, deployment and pod. This, along with timestamped records of activity within individual pods, allows teams to quickly troubleshoot exactly what happened, where it happened and who or what instigated it. Essentially it helps join the dots between who ran kubectl exec and what exactly happened within the container.

It leverages the high value data from a Sysdig capture file (commands, network connections, etc) and makes it dynamically filterable against Kubectl activity.

This allows SOC teams to spot an abnormal kubectl exec into a pod in Kubernetes, then correlate all activity (commands run, files touched, outbound connections made to unknown IP’s etc) that occurred over a specific time period. This stream includes:

  • executed commands inside the container
  • network activity (src, dst, sport, dport, no payload)
  • kubectl exec requests to the Kubernetes API

    Activity Audits UI

SOC teams can search and filter this data for alert triage -- to determine the cause of the anomaly -- and for incident response.

For Example

  • Kube-user 'john-doe' deleted the 'redis-config' Kubernetes ConfigMap, in the 'redis' namespace at 10amPST
  • 'sysdig-agent' service account in the 'sysdig-agent' namespace listed the cluster namespaces at 10amPST

Activity Logging also provides an audit logging process, a common requirement for SOC2, PCI, ISO, and HIPAA compliance, and allows you to trace and investigate Kube user activity even if the container no longer exists.

Lets explore the Kubernetes Audit Log feature by way of a hands on example.