# Defining runtime security

Runtime security is the protection of workloads against active threats and malicious behavior once the workloads have been initialized and are running.

Accuknox provides framework and tools for Runtime Security for Kubernetes, Containerised and VM/Bare-Metal based workloads.

In the case of a Kubernetes pods, runtime is the state that when the pod has come to a running state - this happens after image scanning of the containers, after the patching has been done, after admission controller has allowed for the deployment of the pods.

When the pod has actually begun to run and interact with its host operating system requesting for resources and communicating via the network is when it can be defined as it currently running. And any security solution that monitors and continously protects the workloads in a runtime state is called a runtime security solution. To understand what is runtime security and what we do, lets look at the following illustration:

When a workload is running, it communicates through its library (java, golang, python..) to the kernel. These calls get converted to syscalls. These syscall events when filtered in the order of relevance can be categorized broadly into the following (not an existive) type of features:

• Application interaction with the OS and other processes including - workloads forking process, establishing new network connections and accessing files.
• Network connections can be further categorized into L3, L4 and L7 connections.
• Request for specific capabilities

A runtime security solution is able to provide full visibility into all of these application interactions with the host kernel and provide the ability to filter or restrict specific actions at runtime.

With Accuknox you can automatically discover the application interaction and network interaction in the form of policy as code subsequently these policies can be audited or enforced at runtime giving you the ability to restrict specific behaviors of the application.

For example you could have a policy that says

• Pod A cannot access /etc/bin folder
• Pod B cannot initiate ptrace i.e. trace the execution of other processes
• Pod C cannot communicate to a remote TCP server running on port 5000.

This list can be as exhaustive as you like, and these policies are enforced within the kernel using kernel primitives and technologies as listed below:

### Application security using KubeArmor¶

• The Linux Security Module (LSM) framework provides a mechanism for various security checks to be hooked by new kernel extensions. It denies access to essential kernel objects, such as files, inodes, task structures, credentials, and inter-process communication objects.
• AccuKnox supports AppArmor, SELinux and BPF-LSM as of today for its enforcement engine at runtime.

### Network Security using Cilium¶

• Network runtime protection in the form of L3, L4 and L7 rules using identity (x509 certificates or K8s labels) for your K8s workloads. In K8s policies this is implemented as a CNI using Cilium.
• For Virtual Machine workloads, labels are used to provide host level network policies for L3, L4 and L7.