Sorry, you need to enable JavaScript to visit this website.


Your feedback is important to keep improving our website and offer you a more reliable experience.

Using ONAP and Kubernetes* to enable a trusted smart home

BY Zhu, Ruoyu Ying ON Jul 30, 2019


The Internet of Things (IoT) has been predicted to grow to more than 75 billion connected things by 2025 (Source: Avast Smart Home Security Report 2019, page 15). When analyzing smart homes worldwide, more than 40% have at least one vulnerable connected device, which puts the whole smart home at risk. The following diagram shows vulnerable areas in a smart home.

Image source:

This article describes a scenario where EdgeX Foundry is deployed by Kubernetes* in the Open Network Automation Platform (ONAP) project.

The EdgeX open architecture enables customers to:

  • Reduce support costs by standardizing on a single foundation across the IoT solution stack.
  • Evaluate their requirements and choose from a wide range of vendors and system integrators.
  • Build once and run everywhere using container functionality.


EdgeX Foundry is not a new standard, but a unified standard and application mode for edge applications. It is a simple, interoperable framework that is separate from operating systems and supports many physical devices and applications, to improve the connectivity between devices, applications, and cloud platforms. Its mission is to simplify and standardize industrial IoT edge computing, while sustaining its openness.

IoT development will enter the fast lane when we achieve Plug and Play, which is the foundation for the large-scale commercialization of EdgeX Foundry. In the future, a factory with many types of equipment will only need to plug in each device to the system, and with simple settings, the device will be connected to the Internet of Things. Mocana*, a leading provider of mission-critical IoT security solutions for the digital industrial ecosystem, has joined the EdgeX Foundry* project.

EdgeX Foundry is equipped with a large number of protocol drivers to enable Plug and Play, and the drivers can easily be configured through the API. In the future, sensors will only need to be connected to the system through hardware to achieve interoperability without the need for complex operations such as installing drivers and debugging. Industrial IoT applications that support many different types of devices can take full advantage of Plug and Play operation, especially the unified P&P architecture that enables manipulation of the devices.

Kubernetes* (K8S*) is one of the most popular container orchestrators and it has already become the de-facto cloud native solution. It is supported by Google Compute Engine*, Azure*, and Amazon Web Services* (AWS*), and will be supported by the Akraino Edge Stack,* which enables edge clouds.

Open Network Automation Platform (ONAP) is an open, standards-driven group of cross-industry members focused on developing an orchestration platform and method for automating physical and virtual network functions.

Two recent releases of ONAP are Casablanca and Dublin. Both releases are described below, however, we used the Dublin release for our testing, because it supports container-based workloads.

The ONAP Casablanca release supports only VM-based workload types. Both Telecom and Customer Service Providers (CSPs) have similar demands to deploy networking applications as containers, due to the following reasons:

  • Resource constrained edges:  Power and space constraints limit the number of compute nodes that can be deployed at the edge.
  • Pervasive container support:  Many cloud providers are now support containerized workloads using Kubernetes.
  • Micro-service:  Containers are considered to be an ideal solution to implement micro-services.

The ONAP Dublin release supports Network Function as Virtual Network Functions (VNFs) and Container Network Functions (CNFs). It also supports the co-existence of Network functions and applications using the multi-cloud component, which includes an additional Kubernetes plug-in and an existing OpenStack plugin.

Use Cases supported by ONAP Dublin Release

There are several use cases that can be supported by using multi-cloud Kubernetes plug-ins. For Dublin, we tested the vFirewall and EdgeX Foundry use cases.

Virtual Firewall is the virtualized version of Firewall, which runs entirely within a virtualized environment. Firewall is a common component for CSP services. It is a network security system that monitors and controls inbound and outbound network traffic based on predetermined security rules. A firewall typically establishes a barrier between a trusted internal network and an untrusted external network, such as the Internet.

Security is a shared industry responsibility which is one of the goals of EdgeX Foundry. The Mocana IoT Security Platform is included in EdgeX Foundry and it ensures that IoT devices can be trusted and communicate securely to the public and industrial cloud platforms. The verification of the interoperability and integration of their cloud to AWS, Microsoft Azure IoT, VMWare-based clouds, and GE Predix* is a significant benefit for companies working with Mocana.


The current release of ONAP has a known limitation:  it uses the Topology Orchestration Specification for Cloud Applications (TOSCA) format to describe cloud applications, services, platforms, infrastructure and data components. This limitation is quite significant, because in the Kubernetes world, Helm* is the most commonly used application package manager and has charts for almost every application you can think of, including databases, big data, monitoring, ERM, KV databases, firewalls, WAF, IPS, EdgeX Foundry, IMS, EPC and many more.

In the near term, it is impractical to convert so many charts to TOSCA and validate them. In addition, defining K8S capabilities as TOSCA node types will take a lot of time for two reasons: K8S is ever-expanding with new capabilities and, based on TOSCA history, agreement between the committee members can take a long time. We chose to wrap the Helm charts to act as an SDC attachment in our implementation. The following diagram describes how to deploy a Helm chart in ONAP using EdgeX Foundry as an example.


Image source =

  1. One time setup: prepare Kubernetes-based site using Kubernetes Reference Deployment (KRD) and register the Kubernetes site in ONAP by adding a Kubeconfig file.
  2. EdgeX Foundry onboarding: load it into Service Design and Creation (SDC) as a resource, composing it into a service.
  3. EdgeX Foundry distribution: distribute it using SDC and notify the registered SDC clients like Service Orchestrator (SO) and artifactbroker (a component of Multicloud) to decouple and download Kubernetes-related artifacts from SDC. Also, complete any specified post-processing during design-time because artifacts can be used/retrieved during instantiation time.
  4. Instantiate EdgeX Foundry: call Multicloud Service API via SO.
  5. Check if all EdgeX Foundry containers are successfully brought up on the site by using Kubernetes utilities on the site.
  6. Basic EdgeX Foundry testing to ensure that functionality also works by using consul dashboard to check the services and their status.

Repeat steps 4 - 6 by installing more instances of EdgeX Foundry on a different namespace.


In this article, we have described how to use the latest ONAP Dublin version to deploy CNF in an EdgeX application, which can be integrated with Mocana’s Security Platform, to keep your data and devices trustworthy using an automated system of cybersecurity. These tools work efficiently together, leading us into a smart, safe, and connected home.



Libo Zhu, Cloud Software Engineer at NST/DSS/SSP, Intel Corporation