Views:

Policies define the rules that are used to control what is allowed to run in your Kubernetes cluster. You will define one policy for each cluster that you want to protect, with a default set of rules (also known as a "policy definition") that apply to the entire cluster. If your cluster contains more than one namespace, you can also define separate sets of rules for the namespaces. Any namespace rules take precedence over the cluster-wide rules.

For more information, visit the Help Center article, Defining a policy for a cluster.

Exceptions:

When your architecture demands executing containers with privileges, you can create policies based on specific namespaces. This way you can manage it without exposing all your environment to too broad rules.

Recommendations:

Deployment Phase Possible Actions:

  • Log
  • Block
ActionDeployment Phase
Pod properties
Logcontainers that run in the host network namespace
Logcontainers that run in the host IPC namespace
Logcontainers that run in the host PID namespace
Container properties
Blockcontainers that are permitted to run as root
Blockprivileged containers
Blockcontainers with privilege escalation rights
Blockcontainers that can write to the root filesystem
Blockcontainers with capabilities that do not conform with a baseline policy

Continuous Phase Possible Actions:

  • Log
  • Isolate
  • Terminate
ActionContinuous Phase
Pod properties
Logcontainers that run in the host network namespace
Logcontainers that run in the host IPC namespace
Logcontainers that run in the host PID namespace
Container properties
Terminatecontainers that are permitted to run as root
Terminateprivileged containers
Terminatecontainers with privilege escalation rights
Isolatecontainers that can write to the root filesystem
Isolatecontainers with capabilities that do not conform with a baseline policy

Runtime security provides visibility into container activity that violates a customizable set of rules. Currently, runtime security includes a set of pre-defined rules that provide visibility into MITRE ATT&CK framework tactics for containers, as well as container drift detection. Container Security can automatically mitigate problems detected by the runtime security feature. If a pod violates any rule during runtime, the issue is mitigated by terminating or isolating the pod based on the ruleset assigned to its Container Security policy.

This feature is compatible with Kubernetes and supports Amazon EKS, Microsoft Azure AKS, Google GKE, and OpenShift. It is currently supported with default and the most recent Linux kernels. For more information, visit the Help Center article, Configuring runtime security.

Mitre Attack Container Matrix

Most rules are mapped to Mitre Attack Techniques for Containers. Highlighted in orange below are the techniques that are in the Impact tactic.

Runtime Possible Actions

  • Log
  • Isolate
  • Terminate
Rule IDNameDescriptionEnableActionRD Resource
TM-00000002(T1059.004)Update Package RepositoryDetect package repositories get updatedXLogLink
TM-00000004(T1003.008)Read sensitive file trusted after startupAttempt to read any sensitive file by a trusted program after startup. Trusted programs might read these files at startup, but not afterwards.   
TM-00000005(T1021.004)System user interactiveAn attempt to run interactive commands by a system (i.e. non-login) user   
TM-00000007(T1020)System procs network activityNetwork activity performed by system binaries that are not expected to send or receive any network trafficXIsolateLink
TM-00000009(T1613)Contact K8S API Server From ContainerDetect attempts to contact the K8S API Server from a containerXIsolateLink
TM-00000010(T1543)Launch Package Management Process in ContainerPackage management process ran inside containerXLogLink
TM-00000012(T1070.002)Clear Log ActivitiesDetect modification or removal of critical log filesXTerminateLink
TM-00000013(T1059.004)Create Symlink Over Sensitive FilesDetect symlink created over sensitive files   
TM-00000014(T1068)Packet socket created in containerDetect new packet socket at the device driver (OSI L2) in a container. Packet socket could be used for ARP Spoofing and privilege escalation(CVE-2020-14386) by attacker.   
TM-00000015Redirect STDOUT/STDIN to Network Connection in ContainerDetect redirecting stdout/stdin to network connection in container (potential reverse shell).   
TM-00000016(T1547.006)Linux Kernel Module Injection DetectedDetect kernel module was injected (from container).   
TM-00000018(T1105)Launch Remote File Copy Tools in ContainerDetect remote file copy tools launched in containerXLogLink
TM-00000019(T1613)Specific discovery tool executed in containerDetect execution of specific discovery and/or hacking tools inside containerXTerminate 
TM-00000020(T1613)Amicontained download detected in containerDetect download of amicontained   
TM-00000021(T1562.001)Disable Security ToolsDetect an attempt to disable specific security toolsXTerminateLink
TM-00000022(T1609)Docker or kubernetes client executed in containerDetect a docker or kubernetes client tool executed inside a containerXLogLink
TM-00000023(T1611)Escape attempt detected in privileged containerDetect usage of debugfs and mount in container   
TM-00000024(T1496)HugePages changed in containerDetect HugePages modification as part of mining changes done during XMRig usage   
TM-00000025(T1496)Detect crypto miners using the Stratum protocolMiners typically specify the mining pool to connect to with a URI that begins with 'stratum+tcp' and variantsXTerminateLink
TM-00000026(T1053.003)Schedule Cron JobsDetect cron jobs scheduled   
TM-00000027(T1574.006)Dynamic linker changedChanges to /etc/ld.so.preload may indicate rootkit   
TM-00000028(T1059)DB program spawned processDB related program spawned a new process other than itself. Can indicate successful SQL injection.   
TM-00000029(T1021.004)Lateral Movement using SSHSSH execution with StrictHostKeyChecking and BatchMode. Can indicate scripted lateral movement attempt.XLogLink
TM-00000030(T1496)Detect miner termination in containerMiners typically kill other competing miners.XTerminateLink
TM-00000031(T1610)Launch Privileged ContainerDetect the initial process started in a privileged container.XTerminateLink
TM-00000032(T1070)Delete or rename shell historyDetect shell history deletion   
TM-00000033(T1222.002)File attributes changed in containerDetect an attempt to change attributes on file in containerXTerminateLink
TM-00000034(T1548.001)Set Setuid or Setgid bitWhen the setuid or setgid bits are set for an application, this means that the application will run with the privileges of the owning user or group respectively.   
TM-00000035(T1070.004)Dangerous deletion detected in containerDetect an attempt to destroy everything   
TM-00000036(T1071)Possible IRC communication in containerDetect communication based on known IRC port(TCP/6667, TCP/6697 for TLS).   
TM-00000037(T1613)BOtB download detected in containerDetect download of complex analysis and exploitation tool for containers(https://github.com/brompwnie/botb)XTerminateLink
TM-00000038(T1613)Peirates tool detected in containerDetect download of complex analysis and exploitation tool for containers(https://github.com/inguardians)XTerminateLink
TM-00000039(T1041)Interpreted procs inbound network activityAny inbound network activity performed by any interpreted program (perl, python, ruby, etc.)   
TM-00000040(T1041)Interpreted procs outbound network activityAny outbound network activity performed by any interpreted program (perl, python, ruby, etc.)   
TM-00000041(T1552)Search Private Keys or PasswordsDetect grep for private keys or passwords, also includes find command.XTerminateLink
TM-00000042(T1070.004)Unexpected process termination in containerDetect an attempt get specific processes and kill them, often seen as part of miners deployment and rivals termination.XTerminateLink
TM-00000043New executable created (chmod)New executable created in container with chmodXLogLink
TM-00000044New executable created (open+create)New executable created in a container with open+createXLogLink
TM-00000046Out-of-namespace network access attemptsAccess kubernetes out-of-namespace resource   
TM-00000047(T1070.002)Suspicious log manipulationDetect targeted modification of critical log files   
TM-00000048(T1611) Switch Linux namespaceUnauthorized usage of setns syscalls, which could lead to container escape   
TM-00000049(T1105)Launch Ingress Remote File Copy Tools in ContainerDetect ingress remo   
OrientationRD Resource
One of the basic things that you can do to secure the control plane is to perform integrity monitoring for the most critical Kubernetes files. By doing this, you will be alerted immediately of any change in the configuration. From a Kubernetes security perspective, critical files are those that can affect the entire cluster when compromised.Link
There are still organizations that make the critical mistake of leaving the kube-apiserver publicly exposed. Exposing your API server to the public is the most common entry point for attackers, and allows them to take over your cluster.Link
It is important to know that privileged containers can be used as entry points for attacks and to spread malicious code or malware to compromised hosts and networks. But this is not the only issue—there are other misconfigurations in containers that can put the underlying host at risk.Link
To prevent security issues, it is recommended that you do not run privileged containers in your environment. Instead, provide granular permissions and capabilities to the container environment. Giving containers full access to the host can create security flaws in your production environment. This is the reason that, by default, containers are “unprivileged” and cannot access all the devices in the host. However, this doesn’t mean that privileged containers should not be used at all. Some projects and environments may require its usage, but organizations need to make sure that safeguards and security recommendations are set in place when running such containers.Link
The analyzed samples don’t just search for resource-intensive processes on the host machine; they also look for deployed Docker containers that are conducting mining operations. This behavior aims to guarantee that the latest deployed malware gets to use the host’s computing power.Link
A common trend or technique that malware actors used in the past involved exploiting a vulnerability in a publicly hosted service to gain code execution privileges. This technique allowed an attacker to create a botnet or install a coinminer in the system. A newer technique that entails looking for open APIs, which allow sprawling containers or gain code execution privileges, is becoming more common. When it comes to cryptocurrency-mining malware, there has been a move from on-premise devices to containers and the cloud.Link