The K8SHIELD Dashboard is a unique and innovative view of the attack threats facing your Kubernetes cluster environments, the vulnerabilities that expose your clusters to these attacks, and the remedies you can apply to plug the gaps.

The view is arranged according to the popular MITRE ATT&CK matrix, which follows the progression of attacks from Initial Access through to Lateral Movement and Impact. Cisco Panoptica has innovated on this scale by adding cells relevant for Kubernetes for each level in the scale.

Cisco Panoptica checks the clusters that are protected by it for threats according to these cells.

In each cell , the K8SHIELD dashboard shows relevant attack techniques, and indicates if your clusters are exposed to them (by a warning symbol).

At the top of the dashboard, you have a summary of your clusters and the security threats. You can select which cluster (or all of them) for which to show the matrix.

Click on any technique in the matrix for a full explanation of the risk, suggested fixes, and affected entities in your cluster.

Panoptica K8SHIELD Kubernetes attack scale

The sections below describe the Panoptica K8SHIELD attack scale, as applied to Kubernetes environments.
For each category in the scale, representing a column in the K8SHIELD matrix, a list of potential threats relevant for Kubernetes are listed, as developed by Panoptica.

Initial Access

Compromised Images - there are active pods [in your cluster] which contain containers that were built from compromised images. A compromised image is an image which was modified/changed after it was “pushed” to its Registry. The modified image didn’t pass through the CI tests/checks process, and the image may contain security risks.

Unauthorized Registries - there are active pods which contain containers that were built from images which were downloaded from an unauthorized registry. Unauthorized registries may contain vulnerable or compromised images.

Vulnerable Apps - there are active pods which contain containers that were built from vulnerable images. A vulnerable image is a docker image that has known vulnerabilities, which might have an exploitation that allows malicious users to break into the container.

Exposed Dashboard - the Kubernetes Dashboard acts as a UI for kubectl commands that can apply any API request on any resource. By default, the dashboard uses the cluster-admin role, which gives it very broad permissions to create or modify any resource. In addition, the dashboard could be open to external access, which could allow malicious users to access it and exploit it.

Exposed Applicative Dashboard - an applicative dashboard was detected in the cluster. This dashboard can create, update and modify resources on the cluster. This dashboard is exposed to external communication, which creates a significant risk due to the fact that malicious users could manipulate it.

Execution

Exec into Container - pods which can be manipulated by malicious users were detected in the cluster. These pods allow users to execute arbitrary code in the pod.

Container creation - attackers who stole/gain administrative permissions can deploy resources (e.g. pods, deployment_sets/replica_sets) in the cluster, allowing them to abuse these resources for malicious purposes.

SSH connection - pods which enable remote SSH tunneling were detected in the cluster. Remote SSH access to containers prevents the basic inspection of incoming traffic.

Persistence

Writable hostpath - pods with a hostPath were detected. The hostPath mounts a file or directory from the host node filesystem into these pods, enabling a powerful escape hatch for malicious users.

Cron jobs - cron jobs (jobs which run on a regular schedule) can be created in the cluster. Malicious users may leverage these jobs to abuse cluster resources.

Privilege escalation

Privileged/root pods - pods which run with root or privileged privileges were detected. Having these privileges allow these pods to get control on all other pods (on the same host), and on the host itself. If an attacker breaks into the privileged/root container it can lead to host exposure, and abuse of other pods in the same host, and other hosts in the cluster.

Privileges escalation enabled - pods allowing privilege escalation were detected. This could allow an attacker who broke into the container to escalate the privileges and gain higher privileges and exposure to more capabilities and information that can be exploited, leading attackers to get more information and capabilities on cluster resources.

Cluster-admin binding - cluster-Admin is a Kubernetes role which grants unlimited capabilities on cluster resources. It is important to restrict the use of cluster-admin. The Panoptica detected cluster-admin roles which are assigned to users/groups/service accounts in the cluster.

Defense evasion

Clear Container logs - hiding breach detections, attackers are trying to hide their tracks, typically by deleting logs that can indicate their activity. Pods which allow logs deletion were detected in the cluster, and it is recommended to remove this option.

Clear K8S events - hiding breach detections, attackers are trying to hide their tracks, typically by deleting logs that can indicate about their activity. Kubernetes allows users to delete events in the cluster to the users which are marked.

Credential access

Expose secrets - exposure of Kubernetes secrets allows the viewer to use credentials and certificates and gain access to any restricted resource in the cluster. This can be a goldmine for potential attackers. Keeping secrets viewing options limited is a critical consideration to reduce attacks potential.

Service account Access - Exposure of Service Account details allows attackers to access Kubernetes elements using the service account, as they seek information they can leverage.

Credentials in config file - A common misconfiguration mistake was detected in the cluster, related to exposed sensitive data (e.g. credentials, tokens, certificates or access data) in environment variables or configuration objects called ConfigMaps.

Discovery

K8S API service - the Kubernetes API server will execute any requested (and authorized) request, by any pods. There are many API calls which impose a risk to cluster elements. It is recommended that these options be removed, to support a better security model.

Extracting Cluster information from UI elements - there are many elements in Kubernetes clusters that can expose sensitive information (the Dashboard is the most notable example). Panoptica detected one or more elements which are suspected to be such elements, based on their Kubernetes Roles (cluster-admin role, or similar). These elements are exposed, allowing malicious users to access them and exploit them.
Instance Metadata API exposure - instances metadata exposure allow malicious users to extract sensitive information about the container which can weaponize an attack. This information can be extracted from the hostPath files or directories.

Lateral Movements

Cluster internal networking - attackers typically try to access more elements after the initial access. It is recommended to create different namespaces in the cluster and to isolate these namespaces, preventing unauthorized communication between the namespaces. Panoptica detected namespaces which weren’t defined/segmented properly.

Tiller endpoint (helm 2) access - the default helm-2 installation is not secure. Tiller is granted cluster admin permissions, and exposes its gRPC port inside the cluster, without authentication. A compromised container can use helm cli to deploy anything he wants w/o special permissions.

Impact

Data Destruction - malicious users will try to destroy/delete valuable information in the cluster. We recommend adding dedicated delete capabilities to selected users/service accounts, and not to leave it broadly available.