Skip to content

Defining runtime security

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

Accuknox provides runtime Kubernetes Security.

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 done the authentication and authorization.

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 run-time 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 disover the application interaction and network interaction (as described below) 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:

Network Security using eBPF / 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.

Application security using Linux Security Modules (LSM) / [KubeArmor] (https://github.com/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 and SELinux as of today for its enforcement engine at runtime.
Back to top