Implementing Zero Trust on Kvaser Edge

Can a cloud-managed edge device remain secure when connectivity is unreliable and resources are limited? Two master students at Kvaser explored whether Zero Trust principles could be applied to an edge-based Kubernetes environment running on Kvaser Edge hardware. Their master’s thesis project combined Kubernetes, KubeEdge, SPIRE, Envoy, OPA, EdgeMesh, and Calico into a lightweight architecture designed for secure edge deployments.

As edge devices become more capable, they no longer function only as passive data collectors. They can run local applications, process data close to the source, filter what should be sent onward, and continue operating even when connectivity is unreliable. This creates new opportunities for systems that depend on real-time data, particularly in industrial and automotive environments. 

At the same time, organizations increasingly want the convenience of centralized management. Connecting edge devices to a cloud-managed platform can simplify deployment, updates, monitoring, and fleet management. However, every new connection also creates a potential attack surface. 

Left to right: Lilly-Ann Stenberg and Angelica Hörngren , Chalmers University of Technology 

This raises an important question: how can edge systems become easier to manage over the air without also becoming too trusting or too exposed? That question formed the foundation of a master’s thesis project carried out by two master students at Kvaser. The goal was to explore how a distributed edge system could be connected to Kubernetes while applying Zero Trust principles and keeping the implementation lightweight enough to run on resource-constrained edge hardware. 

Kubernetes beyond the cloud 

Most people know Kubernetes as a platform for running software in cloud environments, but it can also be used to define what software should run, where it should run, how it should be configured, and how it should be updated. For edge systems, this becomes particularly valuable when managing large numbers of devices. Rather than manually updating individual units, a team can deploy applications such as CAN-processing services, diagnostics tools, data loggers, analytics components, or upload agents from a central location. 

This creates a more consistent deployment process. New software versions can be rolled out to selected devices, tested in the field, monitored, and rolled back if necessary. When systems are distributed across multiple locations, centralized management can reduce both operational effort and the risk that devices end up running different software versions or configurations. Kubernetes also provides visibility into the fleet. Operators can quickly see which devices are online, which software versions they are running, which updates have succeeded or failed, and which devices belong to specific customer deployments or testing groups. 

Adapting Kubernetes to the edge 

While Kubernetes provides many advantages, it was originally designed for relatively stable cloud and data-center environments. Edge systems often have different characteristics. They may have limited resources, unstable network connectivity, and less physical protection than infrastructure located in secure server facilities. To explore how Kubernetes could be adapted to these conditions, the project used a local Kubernetes environment based on K3s and KubeEdge. KubeEdge extends Kubernetes concepts to edge environments and is specifically designed around the assumption that edge nodes cannot always depend on a stable connection to the cloud. 

The hardware platform used was a Kvaser Edge WL400S, equipped with 2 GB DDR RAM and 256 GB eMMC storage. The test setup consisted of an Ethernet-connected edge device operating on the same network as the Kubernetes control-plane host. One of the advantages of KubeEdge is that edge devices can continue running local applications even when connectivity to the control plane is interrupted. The cloud side can define the desired system state, while the edge side retains enough information to continue operating during temporary disconnections. 

The project also explored edge networking using EdgeMesh, a KubeEdge extension designed to help services communicate in environments where direct cloud connectivity cannot always be assumed. However, the same connections that enable centralized management also alter the security landscape. Once edge devices, workloads, cloud services, and management platforms are connected, attackers gain more potential paths into the system. 

Removing implicit trust 

Traditional security approaches often focus on protecting the perimeter through firewalls, VPNs, proxies, and network segmentation. These technologies remain important, but they all share a common assumption: keeping threats out. The challenge is that breaches still happen. Vulnerabilities are discovered, credentials are compromised, and devices can be physically accessed. If security depends on the assumption that everything inside the network is trustworthy, a single successful breach can give an attacker considerable freedom. 

That is precisely the problem Zero Trust aims to address. Instead of granting broad permissions once access has been obtained, Zero Trust requires every request to be evaluated continuously based on identity, policy, and context. Access is denied by default, and every component receives only the permissions it explicitly needs. In distributed edge environments, this approach can help limit the impact of a compromised workload. A breached service should not automatically be able to access other services, impersonate them, or reach sensitive resources simply because it already exists inside the network boundary. 

Building a Zero Trust architecture 

To implement these principles, the project combined several cloud-native security technologies. At the network layer, Calico was used to enforce NetworkPolicies. These policies explicitly defined which services were allowed to communicate, while all other traffic was denied by default. For workload identity, the project used SPIRE, which provides short-lived identities and automatically rotates certificates. This is particularly useful in Kubernetes environments where workloads can move, restart, or be replaced, making identity based solely on IP addresses impractical.

Traffic then passed through Envoy, which acted as an application-level boundary proxy. Envoy enforced mutual TLS, validated identities, and applied authorization decisions before allowing requests to reach backend services. Finally, OPA (Open Policy Agent) evaluated access policies written in Rego. Running policy evaluation locally on the edge node helped ensure that authorization decisions could still be made even when cloud connectivity was unavailable. Together, these technologies created multiple layers of protection rather than relying on a single security mechanism. 

Solving the offline identity problem 

One particularly interesting challenge involved workload attestation. One of SPIRE’s built-in attestation approaches relies on stable access to Kubernetes control-plane information, an assumption that does not always hold true at the edge. To address this, the master students developed a custom workload-attestation plugin that could use local container runtime information as evidence of identity, while optionally incorporating Kubernetes verification when connectivity was available. This provided rich attestation when connected and a more suitable fallback option when operating offline. In practice, this meant the edge device could maintain its security model even during temporary cloud outages. 

Testing the approach 

The prototype was evaluated to determine whether the additional security controls would negatively affect performance, stability, or usability. Testing was conducted over a three-minute period using a combination of HTTP requests and gRPC communication. Depending on the components involved, gRPC traffic was transported either over TCP/mTLS connections or through Unix domain sockets. 

During testing, the system successfully handled 4,059 requests with no failed requests. In addition, 95 percent of responses completed in under 48.67 ms, comfortably below the project’s performance threshold. 

CPU monitoring on the edge device did not reveal any noticeable increase in utilization during repeated request activity, suggesting that the added security mechanisms did not create a significant processing burden under the tested conditions. The security results were equally encouraging. The protected backend service, located at the edge, could only be reached through the intended Envoy authorization path. Attempts to bypass the proxy timed out thanks to Calico-enforced network policies, demonstrating that access control was enforced at multiple layers rather than relying solely on application logic. 

Security scans provided a realistic picture of the prototype’s maturity. The deployment performed well in a MITRE-based assessment, while NSA-oriented scans highlighted areas where additional Kubernetes hardening would be required before any production deployment. In other words, the project successfully demonstrated the architecture, while also identifying the further work needed to transform it into a production-ready system. 

Looking ahead 

The project showed that Zero Trust principles can be adapted to distributed edge systems without removing the local autonomy that makes edge computing valuable. By combining workload identity, secure communication, network segmentation, and policy-based authorization, the prototype reduced the need to trust internal traffic simply because it originated from inside the system. Future work could explore additional sources of trust and identity, including hardware-backed attestation, device-specific identity, location-aware policies, and more advanced monitoring capabilities.  

For organizations deploying edge devices in industrial or automotive environments, the project demonstrated that Zero Trust principles can be implemented without noticeably affecting performance. Rather than assuming that traffic inside a network is trustworthy, each service can continuously prove its identity before communication is allowed. For Kvaser Edge users, this approach could help reduce the impact of compromised devices, strengthen remote deployments, and support future cybersecurity and compliance requirements. While the prototype relied on additional cloud-native technologies and would require further hardening before production use, the results suggest that Zero Trust can be applied to edge computing environments. 

This work was carried out as part of a master’s thesis project by two master students at Kvaser. The thesis is expected to be published following Chalmers University’s review and publication process. 

* SPIRE Agents must run either the same version as the SPIRE Server or one version earlier. For example, when using SPIRE Server v1.11.2, the SPIRE Agent must be v1.11.2 or v1.11.1. 

Kvaser Edge

In a world where every endpoint must be verified and trusted, the Kvaser Edge provides one of the few CAN edge computing platforms that can serve as the foundation of a genuinely secure fleet architecture.
Learn more about Kvaser Edge →