You’ve probably heard about containers before. In the unlikely case that you missed the hype, but here’s a quick recap: containers are bundles of applications and their dependencies. With containers, it’s possible to reliably/predictably/consistently run apps regardless of the underlying computing infrastructure they run on. Containers run in the same way everywhere and also isolate the application from its environment and other applications.
Containers are typically lightweight and share some of the underlying machine’s OS system kernel, driving higher efficiencies and reducing storage, compute and licensing costs. Furthermore, support/operation teams can spend less time debugging and diagnosing differences in environments, and more time shipping new functionality to users. App delivery teams can make assumptions in staging and test environments they can be sure will hold true in production.
When talking about containers, we typically refer to data center or cloud application containers. However, while containers can really improve how we handle these apps on the server side, our IT environment is not just about server apps. We live in a world in which users still need a bunch of local fat clients / applications to run on their devices and cannot yet enjoy the benefits of containers.
For example, the following app categories are still deployed locally:
- Security agents (e.g. EDR/EPP)
- Manageability agents (e.g. VPN clients, helpdesk agents)
- Browsers (e.g. Chrome, Firefox, …)
- Office suites (e.g. Microsoft Office)
- Video conferencing tools (e.g. Webex, Zoom, Skype, …)
- Collaboration tools (e.g. Slack, Teams, …)
- Development tools (e.g. Visual Studio Code, Git, …)
- File sharing tools (e.g. Google Drive, Dropbox, OneDrive, …)
- File viewers/editors (e.g. Zip, Adobe Acrobat, Visio, Video players/editors, …)
- A long tail of home-grown enterprise apps and scripts
The long tail of traditional Windows apps (source: Microsoft)
In many cases, there is no standard container-like repository from which these apps can be delivered in a simple predictable way. The problem of consistently running these apps in a way that is easy to support and secure, with minimum friction, is still an unresolved issue.
This problem is further amplified when these apps need to be deployed on a variety of unmanaged user devices, e.g. in a BYOD environment in which users can access corporate resources from their personal/3rd party-owned devices. This could be needed to support work-from-home, contractors/partners/vendors, franchises, branch offices, etc.
For example, an organization might ask users to install a VPN client, a security agent, and a specific browser version on their personal devices (the user’s device will typically run Windows). This might sound simple in theory, but even this simple set of apps introduces a bunch of tough challenges for IT teams:
- Some of these apps might have compatibility issues with the operating system on the user’s device, e.g. because other conflicting apps are already installed in the operating system. Support will need to step in and try to troubleshoot these issues. However, support might not have permissions to fully control the user’s device to help troubleshoot issues.
- The installation experience of some of these applications may not be trivial to some less tech-savvy users and they might need additional assistance.
- The user’s device might be compromised with malware. Malware may tamper with applications, prevent users from running these applications, or exfiltrate documents and credentials used within these apps. There’s no real isolation between the user’s operating system and apps and the corporate apps.
- The user is able to freely mix information between non-corporate apps and corporate apps, either by mistake or intentionally, which could potentially lead to corporate data leaks or to the storage of personal data in corporate systems.
- Some of the applications might be collecting data as part of their operation (e.g. an endpoint security agent that needs to audit file access or a support system that collects logs and other data). This is a privacy issue that users might not be ok with and, in some cases, a violation of privacy regulation.
If we could apply the benefits of containers to client apps and endpoint devices, many of these challenges would be solved, by design. What if we could provision a lightweight predictable isolated operating system container to user devices in which corporate apps live? By applying the same principles of containers to client apps, we could simplify the work of IT teams and eliminate a lot of the deployment, maintenance, and support headaches associated with client apps.
Deploying new apps or app versions would be dramatically simpler, as IT could test these apps on the same operating system that would be eventually running on the user’s device.
As corporate apps will be running in a separate isolated operating system, it doesn’t matter if the user’s operating system has conflicting apps or configurations, corporate apps will run in the same way regardless.
If the user has malware on his device, that malware is not running as part of the corporate operating system container and cannot freely exfiltrate data out of that container or tamper with running applications.
The user would also find it harder to mistakenly copy data out of corporate data into personal apps or vice versa and the container can restrict this type of cross-environment transfers.
Furthermore, by applying the same design of server containers, we could reduce the footprint of such containers to a bare minimum, so that it’s not necessary to keep two full operating system instances and require a double amount of underlying hardware resources.
This approach had been evolving for smartphones, but is now also becoming relevant for omnipresent Windows 10 devices. At Hysolate, we were able to make this vision a reality. We leverage OS virtualization to split a user’s OS into two isolated zones, each with its own OS instance. By doing so, we reap many of the container benefits and apply them to client apps, while further improving security by adopting VM-grade isolation that goes beyond container kernel-based isolation.