Introduction

AccuKnox is thrilled to announce the availability of its runtime observability tool – AccuKnox Insights. This provides observation of workloads (k8s pods, processes in VMs) at runtime. This delivers deep visibility into the workloads and their behavior with respect to the host environment and other services.

AccuKnox insights are part of a CLI (and API) tool that provides runtime visibility in an aggregated form (by pods, processes, workloads)

• Network: The L3, L4, and L7 connections with eBPF-based observability. Ingress and egress..
• System: The files accessed, processes forked, network connections, and capabilities requested

This telemetry is derived from observing system calls that processes make while interacting with the host environment.

Solving the runtime security problem

AccuKnox insights help you to understand what exactly is happening to your workload at runtime after static security checking and controls (image scanning, patching, configuration checks, and after admission control). Posture management tools are increasingly applied to secure cloud workloads. But,  these static checks are blind to unknown (zero-day) vulnerabilities, unintended misconfiguration, and coding bugs, etc.

AccuKnox provides easy to understand visibility  into:

1. What network connections have been established and across what ports; what connections were denied
2. What files were accessed, directories, and how many times
3. What process forking is happening and by how many times
4. What processes have even attempted network connections?

Many of these events can detect anomalous behavior as identified by the MITRE ATT&CK Framework. Examples could be a java microservice that has been compromised through the Log4J vulnerability and is attempting to make an external network connection.

AccuKnox insights provide anomalous behavior as an aggregated log so that the user can take an action and remediate the same.

AccuKnox insights work by tapping into the system calls that each workload does while interacting with the host operating system. By collecting the series of events that occur as the workloads interact with the host operating system and other workloads.

AccuKnox Insights

AccuKnox insights allow you to get an aggregated view of the key events at runtime as described above and also allow you to filter based on specific events or field types. AccuKnox insights in turn leverage Cilium and KubeArmor for observability

Network-specific features: AccuKnox insights provide many network-specific fields that are summarized to reduce verbosity.

For networks, AccuKnox insights can identify and aggregate

• All network (L3, L4, and L7) connections from a particular workload (inbound/outbound) and whether it was allowed by the policies or not.

For KubeArmor, AccuKnox can identify a summary of

• processes getting forked
• directories and files getting accessed
• network connections being attempted

In the following example, we see a workload with various pods making ingress and egress (these are summaries and therefore unique events) with various source and destination IP addresses.

The pod traffic might have been allowed or denied. And if there’s a policy attached that is explicitly denying the pod, the tag of the policy is shown to the right.

In the above example, the KubeArmor observed insights are shown in an aggregated view, showing the host interaction of the pod including files opened, processes forked, etc.  The operation is indicated under the operation field along with last observed, the resource used as well as whether the operation was allowed (or denied) due to a security policy implemented in KubeArmor.

Please keep in mind that these are unique summaries (without repetition). The tag for which the policy was denied is also mentioned to the right.

Demonstrating an attack and observing it with insights:

A common use case is to prevent untrusted shell access within pods. Let’s apply the following KubeArmor policy to this workload:

You’ll need to replace the pod labels with your current pod label to ensure that the policy is applied to the correct pod.

The Kubearmor policy can then be applied with the following CLI command:

Kubectl -f policy-name.yaml

Now let’s try to exec into the pod by using the following command

kubectl exec -it <pod_name> — /bin/bash</pod_name>

The above policy will  deny the attempt and generate a log.

Summary

This is just one example of how you can easily use AccuKnox’s Insights to observe runtime security violations. Stay tuned to this blog for more examples, or contact us with any questions at [email protected].