Activity Audit
kube exec
requests to the Kubernetes API. This makes them searchable and indexed against your cloud-native assets.Prerequisites
To track
kubectl exec
and other Kubernetes commands, Install Kubernetes audit logging.If you are running on a GKE cluster, review GKE Limitations.
Access Activity Audit
To access Activity Audit:
Log in to Sysdig Secure.
Select Threats > Forensics | Activity Audit.
Understand Activity Audit
Use Activity Audit to view different data sources in-depth for monitoring, troubleshooting, diagnostics, or to meet regulatory controls.
Investigate Events
A system investigation might be triggered by an event generated by Sysdig, or by an alert from another tool or person.
Find contextualized, relevant data - Activity Audit enables you to easily access to the underlying data to help trace the event, evaluate its impact, and resolve the issue.
From Policy Events in Sysdig Secure, go directly to the relevant Activity Audit to investigate details.
Trace commands and connections back to users Activity Audit can correlate interactive requests from a Kubernetes user with the commands and network connections performed inside the container, enabling an operator to trace this activity back to a user identity.
Use Activity Audit for Regulatory Audits
Activity Audit can also provide data about the infrastructure to help prove to auditors that proper data visibility and security measures are in place.
Activity Audit is a critical requirement for many compliance standards:
Navigate the Audit Interface
Activity Audit displays a continuously updated list of activities. Use the UI features to find and filter the information you need.
Select Threats > Forensics|Activity Audit to view the Audit Interface.
Filter Activities
Filtering is the heart of Activity Audit’s power. You can use filters to search, sort, parse, and surface meaningful data and connections.
Ways to filter Activity Data:
Scope: Reduce the scope of your investigation by focusing on a more specific area of your infrastructure. By default, your scope will be set to
Everywhere
, unless a team scope is defined for your currently selected team.Data Source: Choose a data source from the right side of the graph. Currently available data sources are:
network activity
,commands
,kubectl exec
, orfile
. You can also select more than one source.Attribute (=/!=): Choose = or -!= next to an attribute, either from the list or from the detail view, to include/exclude that attribute from the filter
Attribute (manual): If you know the attribute, you can type it into the filter box manually, with the following syntax:
Include an attribute
attribute_name="attribute_value"
e.g.comm="grep"
Exclude an attribute
attribute_name!="attribute_value"
e.g.comm!="grep"
Trace Trace entries to see all relevant activity in a session from a specific user. See the Trace Button paragraph for details.
Frequency graph: Select a section of the graph to zoom in on a time frame and see detailed activity. For details, see Frequency Graph paragraph.
Combine: You can combine these methods as needed.
For example, the following filter surfaces activity on a particular pod, while excluding activity from one IP address that is known to be normal.
resource="pods" name="woocommerce-6877958" sourceaddresses!="172.20.41.2
Frequency Graph
The graph shows the activity frequency for each data source, letting you easily zero-in on anomalies.
The image above shows a spike in network activity (purple line) between 12:00 - 3:00 pm.
Drag the mouse over the peak to auto-zoom on the time frame and see more detail.
Data Sources
Use the legend at the right side of the graph to filter information from one particular data set. The currently available data sources are:
User commands (interactive commands tracked by Activity Audit when a user has logged in and is interacting with the shell via SSH or console login)
Kube exec commands (extracted from the Kubernetes/OpenShift audit log)
Network connections and file activities related to user and Kube/Docker exec commands
Activity Audit captures interactive commands and the network connections and file modifications related to those commands. Interactive
means that the tty
for the process is not 0
. It also logs connections made to and from sshd and telnet.
Time Navigation Buttons
Use the time window navigation bar to show only activities run within that window.
Activity Row and Details
Select an activity row to see its details on the right panel, including all the collected attributes. You can use attributes to quickly add filters including =
or excluding !=
such a value.
See Review Activity Details for the attributes of each data source.
You can also perform quick filtering by selecting attribute and filter type directly from the activity row.
Trace Button for kube exec and Shell Activities
Beside each activity originating a trace there is a Trace button
. The Trace button is only available for the following events:- kube exec
- kube attach
- ssh
- dropbear
- shells (*sh)
The Trace button lets you correlate activities from the originator to each single performed operation. See Follow a kubectl exec Trace use case to see it in action.
This button does not appear if you are running on a GKE cluster.
kubectl run
The Kubernetes event in the activity audit list labeled kube run is received from the AC in the following cases:
- A kubectl run is performed
- A kubectl attach is performed
Review Activity Details
Command Details
Name | Description |
---|---|
Time | The date and time the command was executed. |
Command | The command executed. |
Full Command Line | The complete command, including all variables/options. |
Working Directory | The directory the command was executed in. |
Scope | The entities within the infrastructure impacted by the command, including
|
Host | The hostname and MAC address of the host the command was executed on.
The hostname value is expected to match |
Additional Details | Detailed user/host information:
|
Network Connection Details
Only TCP
connections are currently captured in activity audit.
Name | Description |
---|---|
Time | The date and time of the network connection |
Connection Direction | Incoming or outgoing connection |
Connection Details | Including:
|
Scope | The entities impacted by the network connection, including
|
Host | The host name and MAC address of the host where the connection was made |
Additional Details | The process name and ID (Parent Process ID/PID) that launched or received the network connection |
Kubectl Exec Details
Name | Description |
---|---|
Time | The date and time of the kubectl command |
Kubernetes resource | Including:
|
Kubernetes user and group | Including:
|
Sources addresses | External IP address that initiated the connection |
Scope | Including
|
Host | Host name and MAC address of the host where the kubectl exec was made |
File Activity Details
Name | Description |
---|---|
Time | Date and time the file was modified |
File access details | - File name - File directory - Command used to access the file - Access mode |
Scope | Entities impacted by the file activity, including
|
Host | The host name and MAC address of the host where the file activity occurred |
Use Cases
Look for Suspicious Commands
During an investigation you usually need to find suspicious activities among the most normal and recurring ones.
In this example, a ps
command is executed very frequently,
being noisy and making investigations harder.
To focus on other, more suspicious commands, you can use filters to reduce noise and make the investigation easier.
You can use quick filters to exclude the ps
command,
so that other more interesting commands emerge instantly.
Filtering for Incident Response
A Policy Event reports a dangerous peak in network connections coming from a specific pod. This example describes one way to search for the root cause.
What user and what activity triggered this issue?
Use the Respond button next to the policy event to jump directly to the relevant data.
Here you can determine at a glance:
The pod/namespace on which the heightened activity is occurring.
The process related to the activity (in this case,
ab
, or the Apache Benchmark tool).Related activities in the graph (
cmd
andkube exec
lines).Repetitive entries that can be screened out.
Refine the view through filtering:
Switch from
network
data source tocmd
andkube exe
.Filter out noisy, repetitive entries (such as
comm!="bash"
)Investigate details of a kube exec item for user information.
After filtering, you have a focused incident report detailing:
The Kubernetes user “johndoe”
The external IP he used to connect
The set of commands he used to install and launch the Apache Benchmark stress-testing tool.
Follow a kubectl exec Trace
In a production environment, kubectl exec
commands are typically
suspicious. Also, because such commands are interactive sessions, it can
be difficult to pinpoint which individual has issued the commands and
what other activities the individual performed. You can use Sysdig’s
Trace functionality to correlate kubectl exec commands with a
specific user and the network and command activities performed in that
user’s session.
In this example, suspicious activity has been detected and you want to determine whether someone has downloaded and executed a Trojan horse.
Use the Groups to display your Kubernetes hierarchy by namespace and deployment. Focus on the pod displaying unexpected high levels of activity (based on the number in parentheses).
Check the corresponding activity graph and zero in on a time frame and see
kube exec
activity among the hundreds of commands and network events.Select the
kube exec
item and click the Trace button on left.This session trace displays a formatted report of any container activity (network, commands) that the user performed inside the container.
This button does not appear if you are running on a GKE cluster.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.