[![Logo](https://www.paloaltonetworks.com/wp-content/uploads/2021/07/PANW_Parent.png)](https://www.paloaltonetworks.com/)  
[![Unit42 Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/unit42-logo-white.svg)](https://unit42.paloaltonetworks.com/)  
Menu

* [Tools](https://unit42.paloaltonetworks.com/tools/)
* [ATOMs](https://unit42.paloaltonetworks.com/atoms/)
* [Security Consulting](https://www.paloaltonetworks.com/unit42)
* [About Us](https://unit42.paloaltonetworks.com/about-unit-42/)
* [**Under Attack?**](https://start.paloaltonetworks.com/contact-unit42.html)  
  English
* [English](https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/)
* [Japanese](https://unit42.paloaltonetworks.com/ja/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/)
* [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research")
* [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/ "Threat Research")
* [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/ "Cloud Cybersecurity Research")  
  [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/)

# Making Containers More Isolated: An Overview of Sandboxed Container Technologies

![Clock Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-clock.svg) 15 min read

* ![Profile Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-profile-grey.svg)  
  By:

* ![Published Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-calendar-grey.svg)  
  Published:June 6, 2019

* ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-category.svg)  
  Categories:
  
  * [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/)
  * [Learning Hub](https://unit42.paloaltonetworks.com/category/learning-hub/)
  * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/)

* ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-tags-grey.svg)  
  Tags:
  
  * [Containers](https://unit42.paloaltonetworks.com/tag/containers/)
  * [Docker](https://unit42.paloaltonetworks.com/tag/docker/)
  * [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/)
  * [LXC](https://unit42.paloaltonetworks.com/tag/lxc/)
  * [Public cloud](https://unit42.paloaltonetworks.com/tag/public-cloud/)
  * [Rkt](https://unit42.paloaltonetworks.com/tag/rkt/)

* [![Download Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-download.svg)](https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/?pdf=download&lg=en&_wpnonce=af535c9c4e "Click here to download")

* [![Print Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-print.svg)](https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/?pdf=print&lg=en&_wpnonce=af535c9c4e "Click here to print")

Share![Down arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/down-arrow.svg)

* ![Link Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-share-link.svg)
* [![Link Email](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-sms.svg)](mailto:?subject=Making%20Containers%20More%20Isolated:%20An%20Overview%20of%20Sandboxed%20Container%20Technologies&body=Check%20out%20this%20article%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fmaking-containers-more-isolated-an-overview-of-sandboxed-container-technologies%2F "Share in email")
* [![Facebook Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-fb-share.svg)](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Funit42.paloaltonetworks.com%2Fmaking-containers-more-isolated-an-overview-of-sandboxed-container-technologies%2F "Share in Facebook")
* [![LinkedIn Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-linkedin-share.svg)](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fmaking-containers-more-isolated-an-overview-of-sandboxed-container-technologies%2F&title=Making%20Containers%20More%20Isolated:%20An%20Overview%20of%20Sandboxed%20Container%20Technologies "Share in LinkedIn")
* [![Twitter Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-twitter-share.svg)](https://twitter.com/intent/tweet?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fmaking-containers-more-isolated-an-overview-of-sandboxed-container-technologies%2F&text=Making%20Containers%20More%20Isolated:%20An%20Overview%20of%20Sandboxed%20Container%20Technologies "Share in Twitter")
* [![Reddit Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-reddit-share.svg)](https://www.paloaltonetworks.com//www.reddit.com/submit?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fmaking-containers-more-isolated-an-overview-of-sandboxed-container-technologies%2F&ts=markdown "Share in Reddit")
* [![Mastodon Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-mastodon-share.svg)](https://mastodon.social/share?text=Making%20Containers%20More%20Isolated:%20An%20Overview%20of%20Sandboxed%20Container%20Technologies%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fmaking-containers-more-isolated-an-overview-of-sandboxed-container-technologies%2F "Share in Mastodon")
  **Executive Summary**

While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology's limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environment that co-locate containers belonging to different customers. The root of the problem is the weak separation between containers when the host OS creates a virtualized userland for each container. There has been research and development focusing on designing truly sandboxed containers. Most of the solutions re-architect the boundary between the containers to fortify the isolation. This blog covers four unique projects from IBM, Google, Amazon, and OpenStack, respectively, that use different techniques to achieve the same goal, **creating stronger isolation for containers** . IBM Nabla builds containers on top of Unikernels, Google gVisor creates a specialized guest kernel for running containers, Amazon Firecracker is an extremely lightweight hypervisor for sandboxing applications, and OpenStack places containers in a specialized VM that is optimized for container orchestration platforms. The following overview of this state of the art research should help readers prepare for the upcoming transformation.

**Overview of Current Container Technology**

Containers are the modern way of packaging, sharing, and deploying an application. As opposed to a monolithic application in which all functionalities are packaged into a single software, containerized applications or microservices are designed to be single-purpose specializing in only one job. A container includes every dependency (e.g., packages, libraries, and binaries) that an application needs to perform its task. As a result, containerized applications are platform-agnostic and can run directly on any operating system regardless of its version or installed packages. This convenience saves developers tremendous effort of tailoring different versions of software for different platforms or customers. Although not entirely accurate, conceptually, many people like to think of containers as "lightweight virtual machines." When a container is deployed on a host, each container's resources such as its file system, process, and network stack are placed in a virtually isolated environment which no other containers can access. This architecture allows hundreds or thousands of containers to run concurrently on the same cluster and each application (or microservice) can be easily scaled up by replicating more container instances.

Under the hood, the container evolvement is built on top of the two key building blocks, Linux namespace and Linux Control group (cgroup). Namespace creates a virtually isolated user space and gives an application its dedicated system resources such as file system, network stack, process id, and user id. In this isolated user space, the application controls the root directory of the file system starting with PID = 1 and may run as the root user. This abstracted userspace allows each application to run independently without interfering with other applications on the same host. There are currently six namespaces available: mount, inter-process communication (ipc), UNIX time-sharing system (uts), process id (pid), network, and user. Two additional namespaces, time and syslog, are proposed but the Linux community are still defining the specifications. Cgroup enforces hardware resources limitation, prioritization, accounting, and controlling of an application. Example hardware resources that cgroup can control are CPU, memory, device, and network. When putting namespace and cgroup together, we can securely run multiple applications on a single host with each application residing in its isolated environment. This is the fundamental property of a container.

The main difference between a virtual machine (VM) and a container is that the VM is a hardware-level virtualization and a container is a OS-level virtualization. VM hypervisor emulates a hardware environment for each VM, where the container runtime emulates an operating system for each container. VMs share the host's physical hardware and containers share both the hardware and the host's OS kernel. Because containers share more resources from the host, their usages of storage, memory, and CPU cycles are all much more efficient than a VM. However, the downside of more sharing is the weaker trust boundary between the containers and the host. Figure 1 illustrates the architectural difference between a container and a VM.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image1.png)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image1.png)*Figure 1. In machine virtualization, hypervisor or virtual machine monitor (VMM) provides the isolation between each guest OS. In containers, the host operating system provides the isolation between each container.*

*\* Only Type II VMM needs to run on operating system. Type I VMM runs on the physical hardware.*

In general, virtualized hardware isolation creates a much stronger security boundary than namespace isolation. The risk of an attacker escaping a container (process) is much higher than the chance of escaping a VM. The reason for higher container escaping risk lies on the weak isolation that namespace and cgroup create. Linux implements namespace and cgroup by associating new property fields to each process. These fields under the /proc file system tell the host OS if one process can see the other or how much the CPU/Memory budget that the process can use. When viewing the running processes and threads from the host OS (e.g., top or ps commands), a container process looks just like any other process on the host. In general, traditional containers such as LXC or Docker are not considered truly sandboxed as containers on the same host share the same kernel. It is thus not surprising to see container escape vulnerabilities. For example, [CVE-2014-3519](https://nvd.nist.gov/vuln/detail/CVE-2014-3519), [CVE-2016-5195](https://nvd.nist.gov/vuln/detail/CVE-2016-5195), [CVE-2016-9962](https://nvd.nist.gov/vuln/detail/CVE-2016-9962), [CVE-2017-5123](https://nvd.nist.gov/vuln/detail/CVE-2017-5123), and [CVE-2019-5736](https://nvd.nist.gov/vuln/detail/CVE-2019-5736) can all lead to container breakout. Most kernel exploits should work for escaping containers as kernel exploits typically lead to privilege escalation and allow the compromised process to gain control outside its intended namespaces. Besides the attack vectors from software vulnerabilities, misconfiguration such as deploying a container with excessive privileges (e.g., CAP\_SYS\_ADMIN capability, privileged permission) or critical mount points (e.g., /var/run/docker.sock) may all lead to container escape. With these potential catastrophic outcomes, one should understand the risk when deploying containers in a multi-tenant cluster or having containers with sensitive data co-locate with other untrusted containers.

These security concerns motivate researchers to build stronger trust boundaries for containers. The idea is to create a real "sandboxed" container that is isolated from the host OS as much as possible. Most of the solutions involve creating a hybrid architecture that leverages the strong trust boundary from the VM and focus on better efficiency from the container. At the time of writing, there is no single project that is mature enough to be standardized, but the future container development will undoubtedly adopt some of these intriguing concepts. In the rest of the blog, we will go over several promising projects and compare their characteristics.

We start by introducing the Unikernel, the earliest single-purpose machine that packages the application with a minimal set of OS libraries into a single image. The concept of unikernel is fundamental to many future projects that aim to create secure, low-footprint, and optimized machine images. We then look at IBM Nabla, a project aiming to run unikernel applications like containers, and Google gVisor, a project that runs containers on a user-space kernel. After these two unikernel-like projects, we then move to VM-based container solutions, Amazon Firecracker and OpenStack Kata. The last section concludes the blog with a comparison of all the mentioned projects.

**Unikernel**

The advance of virtualization technologies has enabled the movement towards cloud computing. Hypervisors such as Xen and KVM are the fundamental building blocks that power Amazon Web Service (AWS) and Google Computing Platform (GCP). Although modern hypervisors are capable of handling hundreds of VMs in a cluster, VMs built from the traditional general-purpose operating systems are usually not optimized for running in a virtualization environment. A general-purpose OS is designed to support as many types of applications as possible, so its kernel includes all kinds of drivers, protocol libraries, and schedulers. However, most individual VMs deployed in the cloud today are dedicated to a single application such as DNS, proxy, or database. As each application only relies on a small subset of the kernel functions, the rest of the unused kernel functions waste the system resource and increase the attack surface. The larger the codebase is, the more vulnerabilities and bugs need to be managed. These problems motivate computer scientists to design single-purpose OSes with the minimal kernel functionalities to support just a single application.

Operating system researchers first proposed the idea of "Unikernel" in the 1990s. Unikernel is a specialized and single-address-space machine image that can run directly on hypervisors. It packages the application and the application-dependent kernel functions into an image. [Nemesis](<https://en.wikipedia.org/wiki/Nemesis_(operating_system)>) and [Exokernel](https://en.wikipedia.org/wiki/Exokernel) are the two earliest academic unikernel projects. Figure 2 illustrates how a unikernel machine image is created and deployed.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image2.png)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image2.png)*Figure 2. Multi-purpose OSes are built to support all types of applications, so many libraries and drivers are preloaded. Unikernels are specialized single-purpose OSes that are built to support a single application.*

Unikernels break the kernel into multiple libraries and place only the application-dependent libraries into a single machine image. Like VMs, unikernels are deployed and run on virtual machine monitors. Due to their small footprints, unikernels can boot and scale up quickly. Unikernels' most essential properties are improved security, small footprint, high optimization, and fast boot. Because unikernel images contain only the application dependent libraries, and a shell is unavailable unless specifically included, it has minimal attack surface that attackers can leverage. Not only is getting a foothold in unikernels difficult for attackers, but the impact of a compromise is also limited to a single unikernel instance. Because the size of unikernel images is just a few megabytes, unikernels can boot in tens of milliseconds and hundreds of instances can be run on a single host. Using the single-address-space memory allocation instead of the multilevel page table in most of the modern OSes, unikernel applications have lower memory access latency than the same application running in a VM. Because applications are compiled with the kernel when building the image, compilers can perform more static type checking to optimize the binaries.

[Unikernel.org](https://unikernel.org/projects/) maintains a list of the unikernel projects. With all these salient properties, unikernels, however, have not gained much traction. When Docker acquired a unikernel startup, Unikernel Systems, in 2016 people thought that Docker would package containers into unikernels. After 3 years, there is still no sign of any integration. One main reason for this slow adoption is that there is still no mature tool to build unikernel applications and most of the unikernel applications can only run on specific hypervisors. Furthermore, porting an application to unikernel may require recoding with different languages and manually including the dependent kernel libraries. Monitoring or debugging in unikernels is either impossible or causes a significant performance impact. All these limitations hold back developers from migrating to unikernels. One should note that unikernels and containers share many similar properties. Both unikernels and containers are single-purpose images that are immutable, meaning that components in images cannot be updated or patched, and a new image is always created for an updated application. Unikernels today are like the pre-Docker era when no container runtime was available and developers need to use the basic building blocks to sandbox an application: chroot, unshare, and cgroup.

**IBM Nabla**

Researchers from IBM have proposed the idea of "[Unikernel as process](https://dl.acm.org/citation.cfm?id=3267845)": that is a unikernel application run as a process on a specialized virtual machine monitor. IBM's project "[Nabla containers](https://github.com/nabla-containers)" further hardens the unikernel trust boundary by replacing the general-purpose monitor (e.g., QEMU) with their unikernel-specific monitor Nabla Tender. The rationale is that the hypercalls between the unikernels and the general-purpose Virtual Machine Monitor (VMM) still pose a large attack surface, so using a unikernel-specific monitor with fewer allowed system calls can significantly improve the security. Nabla Tender intercepts the hypercalls that unikernels send to the VMM and translates them to system calls. The Linux seccomp policy blocks all other system calls that Tender does not need. A unikernel together with Nabla Tender then runs as a user space process on the host. Figure 3 shows how Nabla creates a thin interface between the unikernel applications and the host.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image3.png)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image3.png)*Figure 3. To interface Nabla with the existing container runtime platforms, Nabla implements the OCI compliant runtime* ***runnc*** *that can be plugged into platforms like Docker and Kubernetes.* *Image source:* [*Unikernels as Process*](https://acmsocc.github.io/2018/slides/socc18-slides-williams.pdf)

The researchers claim that Nabla Tender uses less than seven syscalls to interface with the host. As syscalls serve as the bridge between the user space processes and the OS kernel, the fewer the available syscalls are, the smaller the attack surface exposed to the kernel. One additional benefit of running unikernel as a process is that the unikernel applications can be debugged with most process-based tools such as gdb.

To leverage the container orchestration platforms, Nabla also provides its Nabla runtime *runnc* that implements the Open Container Initiative (OCI) standard. The OCI standard specifies the API between runtime clients (e.g., Docker, Kubectl) and runtime (e.g., runc). Nabla also provides an image builder to create a unikernel image that runnc can execute. Due to the difference in file system between unikernels and traditional containers, Nabla images do not follow the OCI image specification and thus Docker images are not compatible with runnc. At the time of writing, the project is still in its early experimental stage. There are other limitations such as the lack of support for mounting/accessing host file systems, adding multiple network interfaces (needed for Kubernetes), or using images from other unikernel images (e.g., MirageOS and include OS).

**Google gVisor**

Google gVisor is the sandbox technology that powers Google Computing Platform's (GPC) App Engine, Cloud Functions, and CloudML. Google realized the risk of running untrusted applications in the public cloud infrastructure and the inefficiency of sandboxing applications using VMs, and developed a user space kernel to sandbox the untrusted applications. gVisor sandboxes applications by intercepting all the system calls from applications to host kernel and handling them with gVisor's kernel implementation Sentry in user space. It essentially functions as a combination of guest kernel and VMM. Figure 4 shows gVisor's architecture.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image7.png)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image7.png)*Figure 4. gVisor kernel implementation* ***Sentry*** *and gVisor file system implementation* ***Gofer*** *use a small subset of syscalls to interface with the host.* *Image source:* [*gVisor Architecture Guide*](https://gvisor.dev/docs/architecture_guide/), [gVisor Overview and Platform](https://gvisor.dev/docs/architecture_guide/overview/)

gVisor creates a strong security boundary between an application and its host. This boundary restricts the syscalls that applications in user space can use. Without relying on the virtualized hardware, gVisor runs as a host process that interfaces between the sandboxed application and the host. Sentry implements most of the Linux system calls and essential kernel functions such as signal delivery, memory management, network stack, and threading model. [Sentry has implemented more than 70% of the 319 Linux syscalls to support the sandboxed applications](https://gvisor.dev/docs/user_guide/compatibility/amd64/). For Sentry to communicate with the host kernel, it only uses less than 20 Linux syscalls. It is worth noting that gVisor and Nabla share a very similar strategy: defending the host OS. Both of them use less than 10% of the Linux syscalls to interface with the host kernel. While gVisor creates a multi-purpose kernel and Nabla relies on the unikernels, they both run a specialized guest kernel in user space to support the sandboxed applications.

One may wonder why gVisor needs to re-implement another Linux kernel while the open-source Linux kernel is readily available. gVisor's kernel written in Golang is more secure than the Linux kernel written in C due to the strong type safety and memory management features in Golang. Another important selling point of gVisor is its tight integration with Docker, Kubernetes, and the OCI standard. Most of the Docker images can be simply pulled and run with gVisor by changing the runtime to gVisor runsc. In Kubernetes, instead of sandboxing each container, an entire pod can be run in a gVisor sandbox.

As gVisor is still in its infancy, there are still some limitations. There is always overhead when gVisor intercepts and handles a syscall made by the sandboxed application, so it is not suitable for syscall heavy applications. (Note that there is no such overhead in Nabla as unikernel applications don't make syscalls. Nabla uses seven syscalls only to handle the hyercalls.) gVisor has no direct hardware access (passthrough), so applications that require hardware access such as GPU cannot run in gVisor. Finally, as gVisor has not implemented all the Linux syscalls, applications that use unimplemented syscalls can't run in gVisor.

**Amazon Firecracker**

Amazon Firecracker is the technology that powers AWS Lambda and AWS Fargate today. It is a VMM that creates lightweight virtual machines (MicroVMs) specifically for multi-tenant containers and serverless operational models. Before Firecracker was available, Lambda functions and Fargate containers were running inside dedicated EC2 VMs for each customer to ensure the strong isolation. Although VMs create strong isolation for containers in public cloud, using general-purpose VMMs and VMs for sandboxing applications is not very resource-efficient. Firecracker solves both the security and performance issues by creating a VMM specifically for cloud-native applications. Firecracker VMM provides each guest VM with the minimal OS functionalities and emulated devices to enhance both the security and performance. [Users can easily build VM images that run on Firecracker with a Linux kernel binary and ext4 file system image](https://github.com/firecracker-microvm/firecracker/blob/master/docs/rootfs-and-kernel-setup.md). Amazon started developing Firecracker in 2017 and made it open source in 2018.

Similar to the unikernel concept, only a small subset of the devices and functionalities are provisioned to support the container operations. Compared to traditional VMs, microVMs have a much smaller attack surface, memory footprint, and boot time. [Evaluation](https://github.com/firecracker-microvm/firecracker/blob/master/SPECIFICATION.md) shows that a Firecracker microVM consumes ~5 MB memory and boots up in ~125 ms when running on a 2 CPU and 256G RAM host. Figure 5 shows the Firecracker architecture and its security boundary.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image4.png)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image4.png)*Figure 5. Firecracker VMM enforces layers of security boundary to isolate each user's applications.* *Image source:* [*Firecracker Design*](https://github.com/firecracker-microvm/firecracker/blob/master/docs/design.md)

Firecracker VMM relies on KVM and each Firecracker instance runs as a user space process. Each Firecracker process is locked down by the seccomp, cgroup, and namespace policies so that the system calls, hardware resource, file system, and network activities are strictly limited. There are multiple threads inside each Firecracker process. API thread provides the control plane between the clients on the host and the microVM. VMM thread provides a minimal set of virtIO devices (net and block). Firecracker provisioned only four emulated devices for each microVM: virtio-block, virtio-net, serial console, and a 1-button keyboard controller used only to stop the microVM. For security purpose, VMs do not have a mechanism to share files with the host. The data on the host such as container images are exposed to microVMs through File Block Devices. The network interfaces for VMs are backed by the tap devices over a network bridge. All the outbound packets are copied to the tap device and rate-limited by cgroup policy. The layers of security boundary minimize the chance of having one user's applications disrupt the other's.

At the time of writing, Firecracker has not yet fully integrated with Docker and Kubernetes. Firecracker does not support hardware passthrough, so applications that need GPU or any device accelerator access are not compatible. It has limited VM-to-host file sharing and networking models as well. However, as the project is backed by a large community, it should be soon interfaced with the OCI standard and supports more applications.

**OpenStack Kata**

Seeing the security concerns of the traditional containers, Intel launched their VM-based container technology Clear Containers in 2015. Clear containers rely on the Intel® VT hardware-based virtualization technology and a highly-customized QEMU-KVM hypervisor qemu-lite to realize a high performance VM-based container. [At the end of 2017, Clear containers project joined with Hyper RunV, a hypervisor-based runtime for OCI, to initiate the Kata containers project](https://clearlinux.org/news-blogs/kata-containers-next-evolution-clear-containers). Inheriting all the properties of the Clear Containers, Kata Containers now support a wider variety of infrastructures and container specifications.

Kata container is fully integrated with OCI, Container Runtime Interface (CRI), and Container Networking Interface (CNI). It supports various types of networking models (e.g., passthrough, MacVTap, bridge, tc mirroring) and configurable guest kernels so that the applications requiring special networking models or kernel versions can all run on it. Figure 6 shows how containers inside Kata VMs interact with the existing orchestration platforms.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image5.jpg)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image5.jpg)*Figure 6. Kata containers are fully integrated with Docker and Kubernetes.* *Image source:* [*An overview of the Kata Containers project*](https://katacontainers.io/learn/)

Kata has a *kata-runtime* on the host to start and configure new containers. For each container in Kata VM, there is a corresponding Kata Shim on the host. Kata Shim receives API requests from the clients (e.g., docker or kubectl) and forwards the requests to the agent inside the Kata VM through VSock. Kata containers further make several optimizations to reduce the VM boot time. NEMU is a lightweight version of QEMU with ~80% of devices and packages removed. VM-Templating creates a clone of running Kata VM instance and shares it with other newly created Kata VMs. It significantly reduces the boot time and guest VM memory consumption but may be vulnerable to cross-VM side-channel attack like [CVE-2015-2877](https://nvd.nist.gov/vuln/detail/CVE-2015-2877). Hotplug capability allows a VM to boot with the minimal resources (e.g., CPU, memory, virtio block) and add additional resources later when requested.

Kata containers and Firecracker are both VM-based sandbox technology designed for cloud-native applications. They share the same goal but take very different approaches. Firecracker is a specialized VMM that creates a secure virtualization environment for guest OSes while Kata containers are lightweight VMs that are highly optimized for running containers. [There has been efforts to run Kata containers on the Firecracker VMM.](https://github.com/kata-containers/documentation/wiki/Initial-release-of-Kata-Containers-with-Firecracker-support) While the project is still experimental, it can potentially bring together the best features of the two projects.

**Conclusion**

We have looked at several solutions that tackle the current container technology's weak isolation issue. IBM Nabla is a unikernel-based solution that packages applications into a specialized VM. Google gVisor is a merge of a specialized hypervisor and guest OS kernel that provides a secure interface between the applications and their host. Amazon Firecracker is a specialized hypervisor that provisions each guest OS a minimal set of hardware and kernel resources. OpenStack Kata is a highly optimized VM with built-in container engine that can run on hypervisors. It is difficult to say which one works best as they all have different pros and cons. Table 1 shows a side-by-side comparison of some important features across all four projects. Nabla is your best choice if you have applications running in unikernels such as MirageOS or IncludeOS. gVisor is currently integrated best with Docker and Kubernetes, but due to its incomplete system call coverage, some applications still cannot run on it. Firecracker supports customized guest OS images, so it is a good choice if your applications need to run in a customized VM. Kata containers are fully compliant with the OCI standard and can run on both KVM and Xen hypervisor. It can simplify deploying microservices in an environment of hybrid platforms. While it may take some time for one or multiple solutions to eventually be adopted by the mainstream, it is positive to see that most cloud providers have taken action on mitigating the issue. For organizations who are building on-premises cloud-native platforms, it is not the end of the world. Common practices such as patching quickly, least privilege configuration, and network segmentation can all effectively reduce the attack surface.

[![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image6.png)](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/06/image6.png)*Table 1. A comparison of all four platforms.*
Back to top

### Tags

* [Containers](https://unit42.paloaltonetworks.com/tag/containers/ "Containers")
* [Docker](https://unit42.paloaltonetworks.com/tag/docker/ "Docker")
* [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/ "Kubernetes")
* [LXC](https://unit42.paloaltonetworks.com/tag/lxc/ "LXC")
* [Public cloud](https://unit42.paloaltonetworks.com/tag/public-cloud/ "public cloud")
* [Rkt](https://unit42.paloaltonetworks.com/tag/rkt/ "Rkt")  
  [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") [Next: Unit 42 Discovers Vulnerabilities in Adobe Acrobat and Reader and Foxit Reader, Shares Threat Research at Microsoft BlueHat Shanghai 2019](https://unit42.paloaltonetworks.com/unit-42-discovers-vulnerabilities-in-adobe-acrobat-and-reader-and-foxit-reader-shares-threat-research-at-microsoft-bluehat-shanghai-2019/ "Unit 42 Discovers Vulnerabilities in Adobe Acrobat and Reader and Foxit Reader, Shares Threat Research at Microsoft BlueHat Shanghai 2019")

### Related Articles

* [Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years](https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/ "article - table of contents")
* [Understanding Current Threats to Kubernetes Environments](https://unit42.paloaltonetworks.com/modern-kubernetes-threats/ "article - table of contents")
* [Cloud Logging for Security and Beyond](https://unit42.paloaltonetworks.com/cloud-logging-for-security/ "article - table of contents")

## Related Cloud Cybersecurity Research Resources

![Pictorial representation of bucket hijacking technique for cloud data exfiltration. Digital illustration of Europe map highlighting network connections and nodes, depicted as glowing points and lines on a dark blue background, emphasizing major cities and connectivity across the continent.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/09_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg)  
[![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) June 22, 2026 [#### The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)

* [AWS](https://unit42.paloaltonetworks.com/tag/aws/ "AWS")

* [Bucket hijacking](https://unit42.paloaltonetworks.com/tag/bucket-hijacking/ "bucket hijacking")

* [Cloud data exfiltration](https://unit42.paloaltonetworks.com/tag/cloud-data-exfiltration/ "cloud data exfiltration")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/ "The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration")  
  ![Pictorial representation of Vertex AI model uploads. Close-up view of a digital wall displaying various glowing icons, representing a high-tech network interface.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/AdobeStock_1270203474-1-786x354.png)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) June 16, 2026 [#### Pickle in the Middle -- Hijacking Vertex AI Model Uploads for Cross-Tenant RCE](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/)

* [Bucket squatting](https://unit42.paloaltonetworks.com/tag/bucket-squatting/ "bucket squatting")

* [Google Cloud](https://unit42.paloaltonetworks.com/tag/google-cloud/ "Google Cloud")

* [Joblib](https://unit42.paloaltonetworks.com/tag/joblib/ "joblib")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/ "Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE")  
  ![Pictorial representation of Cloud Logging services for defense evasion. A vibrant digital illustration depicting a glowing, neon blue cloud symbol positioned over a circuit board landscape. The cloud symbolizes cloud computing technology, and the landscape features intricate electronic circuits with glowing lines and nodes, suggesting high-tech data transfer and connectivity.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/11_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) June 9, 2026 [#### Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility](https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/)

* [AWS CloudTrail](https://unit42.paloaltonetworks.com/tag/aws-cloudtrail/ "AWS CloudTrail")

* [Cloud logging](https://unit42.paloaltonetworks.com/tag/cloud-logging/ "cloud logging")

* [Defense evasion](https://unit42.paloaltonetworks.com/tag/defense-evasion/ "defense evasion")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/ "Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility")  
  ![Pictorial representation of ROADtools framework in the cloud. An Asian man wearing glasses sits in front of a computer screen. Reflecting in the glasses are lines indicating analysis. Bright blue city lights illuminate the rest of the image.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/10_Cloud_cybersecurity_research_Overview_1920x900-1-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) May 22, 2026 [#### Paved With Intent: ROADtools and Nation-State Tactics in the Cloud](https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/)

* [Curious Serpens](https://unit42.paloaltonetworks.com/tag/curious-serpens/ "Curious Serpens")

* [Entra ID](https://unit42.paloaltonetworks.com/tag/entra-id/ "Entra ID")

* [Microsoft Azure](https://unit42.paloaltonetworks.com/tag/microsoft-azure/ "Microsoft Azure")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ "Paved With Intent: ROADtools and Nation-State Tactics in the Cloud")  
  ![Pictorial representation of autonomous AI attack in cloud environments. Digital illustration of a glowing blue brain connected to a network of lines and lights.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/04/12_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) April 23, 2026 [#### Can AI Attack the Cloud? Lessons From Building an Autonomous Cloud Offensive Multi-Agent System](https://unit42.paloaltonetworks.com/autonomous-ai-cloud-attacks/)

* [AI](https://unit42.paloaltonetworks.com/tag/ai/ "AI")

* [Cloud](https://unit42.paloaltonetworks.com/tag/cloud/ "Cloud")

* [Data exfiltration](https://unit42.paloaltonetworks.com/tag/data-exfiltration/ "data exfiltration")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/autonomous-ai-cloud-attacks/ "Can AI Attack the Cloud? Lessons From Building an Autonomous Cloud Offensive Multi-Agent System")  
  ![Pictorial representation of passwordless authentication. Futuristic cityscape with skyscrapers surrounded by glowing, neon-lit pathways and digital clouds. The sky is vibrant with pink and orange hues, giving a surreal, cyberpunk aesthetic.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/03/02_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) March 23, 2026 [#### Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication](https://unit42.paloaltonetworks.com/passwordless-authentication/)

* [Google](https://unit42.paloaltonetworks.com/tag/google/ "Google")

* [Google authenticator](https://unit42.paloaltonetworks.com/tag/google-authenticator/ "google authenticator")

* [Google Chrome](https://unit42.paloaltonetworks.com/tag/google-chrome/ "Google Chrome")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/passwordless-authentication/ "Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication")  
  ![Close-up of a black woman with glasses examining colorful computer code on a screen. The scene is illuminated by various lights, creating a focused and analytical atmosphere.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/02/13_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) February 6, 2026 [#### Novel Technique to Detect Cloud Threat Actor Operations](https://unit42.paloaltonetworks.com/tracking-threat-groups-through-cloud-logging/)

* [API](https://unit42.paloaltonetworks.com/tag/api/ "API")

* [IAM](https://unit42.paloaltonetworks.com/tag/iam/ "IAM")

* [MITRE](https://unit42.paloaltonetworks.com/tag/mitre/ "MITRE")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/tracking-threat-groups-through-cloud-logging/ "Novel Technique to Detect Cloud Threat Actor Operations")  
  ![Pictorial representation of Azure OpenAI DNS resolution issue. Futuristic cityscape illustration with luminous structures and floating cloud elements, showcasing advanced technology and a dynamic, digitally enhanced environment.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/06/02_DNS_Overview_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) January 20, 2026 [#### DNS OverDoS: Are Private Endpoints Too Private?](https://unit42.paloaltonetworks.com/dos-attacks-and-azure-private-endpoint/)

* [Microsoft Azure](https://unit42.paloaltonetworks.com/tag/microsoft-azure/ "Microsoft Azure")

* [Networking](https://unit42.paloaltonetworks.com/tag/networking/ "networking")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/dos-attacks-and-azure-private-endpoint/ "DNS OverDoS: Are Private Endpoints Too Private?")  
  ![Pictorial representation of cloud discovery with AzureHound. A digital representation of a cloud composed of blue light particles, superimposed over a blurred background of server racks in a data center.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/10/08_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) October 24, 2025 [#### Cloud Discovery With AzureHound](https://unit42.paloaltonetworks.com/threat-actor-misuse-of-azurehound/)

* [Control plane](https://unit42.paloaltonetworks.com/tag/control-plane/ "control plane")

* [Curious Serpens](https://unit42.paloaltonetworks.com/tag/curious-serpens/ "Curious Serpens")

* [Data plane](https://unit42.paloaltonetworks.com/tag/data-plane/ "data plane")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/threat-actor-misuse-of-azurehound/ "Cloud Discovery With AzureHound")  
  ![Pictorial representation of a gift card fraud campaign. A glowing skull and crossbones on a circuit board.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/10/07_Cybercrime_Category_1920x900-786x368.jpg)  
  [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) October 22, 2025 [#### Jingle Thief: Inside a Cloud-Based Gift Card Fraud Campaign](https://unit42.paloaltonetworks.com/cloud-based-gift-card-fraud-campaign/)

* [CL‑CRI‑1032](https://unit42.paloaltonetworks.com/tag/cl-cri-1032/ "CL‑CRI‑1032")

* [Microsoft](https://unit42.paloaltonetworks.com/tag/microsoft/ "Microsoft")

* [Phishing](https://unit42.paloaltonetworks.com/tag/phishing/ "phishing")  
  [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/cloud-based-gift-card-fraud-campaign/ "Jingle Thief: Inside a Cloud-Based Gift Card Fraud Campaign")

* ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg)

* ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg)  
  ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ![Enlarged Image]()  
  ![Newsletter](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/03/unit42-footer-subscribe-desktop.png)  
  ![UNIT 42 Small Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/palo-alto-logo-small.svg) Get updates from Unit 42

## Peace of mind comes from staying ahead of threats. Subscribe today.

Your Email

Subscribe for email updates to all Unit 42 threat research.  
By submitting this form, you agree to our [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use "Terms of Use") and acknowledge our [Privacy Statement.](https://www.paloaltonetworks.com/legal-notices/privacy "Privacy Statement")

This site is protected by reCAPTCHA and the Google [Privacy Policy](https://policies.google.com/privacy) and [Terms of Service](https://policies.google.com/terms) apply.

Invalid captcha!
Subscribe ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) ![loader](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-loader.svg)  
{#footer} Products and Services

* [AI-Powered Network Security Platform](https://www.paloaltonetworks.com/network-security)

* [Secure AI by Design](https://www.paloaltonetworks.com/ai-security)

* [Prisma AIRS](https://www.paloaltonetworks.com/ai-security/prisma-airs)

* [AI Access Security](https://www.paloaltonetworks.com/sase/ai-access-security)

* [Cloud Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions)

* [Advanced Threat Prevention](https://www.paloaltonetworks.com/network-security/advanced-threat-prevention)

* [Advanced URL Filtering](https://www.paloaltonetworks.com/network-security/advanced-url-filtering)

* [Advanced WildFire](https://www.paloaltonetworks.com/network-security/advanced-wildfire)

* [Advanced DNS Security](https://www.paloaltonetworks.com/network-security/advanced-dns-security)

* [Enterprise Data Loss Prevention](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention)

* [Enterprise IoT Security](https://www.paloaltonetworks.com/network-security/enterprise-device-security)

* [Medical IoT Security](https://www.paloaltonetworks.com/network-security/medical-device-security)

* [Industrial OT Security](https://www.paloaltonetworks.com/network-security/ot-security-solution)

* [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security)

* [Next-Generation Firewalls](https://www.paloaltonetworks.com/network-security/next-generation-firewall)

* [Hardware Firewalls](https://www.paloaltonetworks.com/network-security/hardware-firewall-innovations)

* [Software Firewalls](https://www.paloaltonetworks.com/network-security/software-firewalls)

* [Strata Cloud Manager](https://www.paloaltonetworks.com/network-security/strata-cloud-manager)

* [SD-WAN for NGFW](https://www.paloaltonetworks.com/network-security/sd-wan-subscription)

* [PAN-OS](https://www.paloaltonetworks.com/network-security/pan-os)

* [Panorama](https://www.paloaltonetworks.com/network-security/panorama)

* [Secure Access Service Edge](https://www.paloaltonetworks.com/sase)

* [Prisma SASE](https://www.paloaltonetworks.com/sase)

* [Application Acceleration](https://www.paloaltonetworks.com/sase/app-acceleration)

* [Autonomous Digital Experience Management](https://www.paloaltonetworks.com/sase/adem)

* [Enterprise DLP](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention)

* [Prisma Access](https://www.paloaltonetworks.com/sase/access)

* [Prisma Browser](https://www.paloaltonetworks.com/sase/prisma-browser)

* [Prisma SD-WAN](https://www.paloaltonetworks.com/sase/sd-wan)

* [Remote Browser Isolation](https://www.paloaltonetworks.com/sase/remote-browser-isolation)

* [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security)

* [AI-Driven Security Operations Platform](https://www.paloaltonetworks.com/cortex)

* [Cloud Security](https://www.paloaltonetworks.com/cortex/cloud)

* [Cortex Cloud](https://www.paloaltonetworks.com/cortex/cloud)

* [Application Security](https://www.paloaltonetworks.com/cortex/cloud/application-security)

* [Cloud Posture Security](https://www.paloaltonetworks.com/cortex/cloud/cloud-posture-security)

* [Cloud Runtime Security](https://www.paloaltonetworks.com/cortex/cloud/runtime-security)

* [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud)

* [AI-Driven SOC](https://www.paloaltonetworks.com/cortex)

* [Cortex XSIAM](https://www.paloaltonetworks.com/cortex/cortex-xsiam)

* [Cortex XDR](https://www.paloaltonetworks.com/cortex/cortex-xdr)

* [Cortex XSOAR](https://www.paloaltonetworks.com/cortex/cortex-xsoar)

* [Cortex Xpanse](https://www.paloaltonetworks.com/cortex/cortex-xpanse)

* [Unit 42 Managed Detection \& Response](https://www.paloaltonetworks.com/cortex/managed-detection-and-response)

* [Managed XSIAM](https://www.paloaltonetworks.com/cortex/managed-xsiam)

* [Next-Generation Identity Security](https://www.paloaltonetworks.com/idira)

* [Privileged Access Management](https://www.paloaltonetworks.com/idira/human/privileged-access-management)

* [Identity and Access Management](https://www.paloaltonetworks.com/idira/human/identity-and-access-management)

* [Endpoint Privilege Manager](https://www.paloaltonetworks.com/idira/human/endpoint-privilege-manager)

* [Identity Governance](https://www.paloaltonetworks.com/idira/human/identity-governance)

* [Workforce Password Management](https://www.paloaltonetworks.com/idira/human/workforce-password-management)

* [Agentic Identities](https://www.paloaltonetworks.com/idira/agentic)

* [Secrets Management](https://www.paloaltonetworks.com/idira/machine/secrets-management)

* [Unified Secrets Governance](https://www.paloaltonetworks.com/idira/machine/unified-secrets-governance)

* [Application Credentials Delivery](https://www.paloaltonetworks.com/idira/machine/application-credentials-delivery)

* [Vendor Privileged Access](https://www.paloaltonetworks.com/idira/human/vendor-privileged-access)

* [Threat Intel and Incident Response Services](https://www.paloaltonetworks.com/unit42)

* [Proactive Assessments](https://www.paloaltonetworks.com/unit42/assess)

* [Incident Response](https://www.paloaltonetworks.com/unit42/respond)

* [Transform Your Security Strategy](https://www.paloaltonetworks.com/unit42/transform)

* [Discover Threat Intelligence](https://www.paloaltonetworks.com/unit42/threat-intelligence-partners)  
  Company

* [About Us](https://www.paloaltonetworks.com/about-us)

* [Careers](https://jobs.paloaltonetworks.com/en/)

* [Contact Us](https://www.paloaltonetworks.com/company/contact-sales)

* [Corporate Responsibility](https://www.paloaltonetworks.com/about-us/corporate-responsibility)

* [Customers](https://www.paloaltonetworks.com/customers)

* [Investor Relations](https://investors.paloaltonetworks.com/)

* [Location](https://www.paloaltonetworks.com/about-us/locations)

* [Newsroom](https://www.paloaltonetworks.com/company/newsroom)  
  Popular Links

* [Blog](https://www.paloaltonetworks.com/blog/)

* [Communities](https://www.paloaltonetworks.com/communities)

* [Content Library](https://www.paloaltonetworks.com/resources)

* [Cyberpedia](https://www.paloaltonetworks.com/cyberpedia)

* [Event Center](https://events.paloaltonetworks.com/)

* [Manage Email Preferences](https://start.paloaltonetworks.com/preference-center)

* [Products A-Z](https://www.paloaltonetworks.com/products/products-a-z)

* [Product Certifications](https://www.paloaltonetworks.com/legal-notices/trust-center/certifications)

* [Report a Vulnerability](https://www.paloaltonetworks.com/security-disclosure)

* [Sitemap](https://www.paloaltonetworks.com/sitemap)

* [Tech Docs](https://docs.paloaltonetworks.com/)

* [Unit 42](https://unit42.paloaltonetworks.com/)

* [Do Not Sell or Share My Personal Information](https://panwedd.exterro.net/portal/dsar.htm?target=panwedd)
  ![Palo Alto Networks Logo](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/pan-logo-dark.svg)

* [Privacy](https://www.paloaltonetworks.com/legal-notices/privacy)

* [Trust Center](https://www.paloaltonetworks.com/legal-notices/trust-center)

* [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use)

* [Documents](https://www.paloaltonetworks.com/legal)

Copyright © 2026 Palo Alto Networks. All Rights Reserved

* [![Youtube](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/youtube-black.svg)](https://www.youtube.com/user/paloaltonetworks)
* [![Podcast](https://www.paloaltonetworks.com/content/dam/pan/en_US/images/icons/podcast.svg)](https://www.paloaltonetworks.com/podcasts/threat-vector)
* [![Facebook](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/facebook-black.svg)](https://www.facebook.com/PaloAltoNetworks/)
* [![LinkedIn](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/linkedin-black.svg)](https://www.linkedin.com/company/palo-alto-networks)
* [![Twitter](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/twitter-x-black.svg)](https://twitter.com/PaloAltoNtwks)
* EN  
  Select your language  
  ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg)

### Default Heading

Read the article ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg)  
Seekbar

![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg)  
![Volume](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-volume.svg)  
Volume
![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg)
