You can skip the virtual machine: Using SELinux with containers to help secure cloud native 5G

Many communication service providers (CSPs) are looking at shifting to containers and a cloud native architecture, but have concerns about security. In this post, we'll explain why you don't need virtual machines to offer the security features the telecommunications market needs. 

Benefits of Cloud Native Network Functions

The performance and cost benefits of moving to cloud native architectures and containers are very clear to vendors and IT managers everywhere, but in the telecommunications market, these benefits can be even more significant. Shifting from Virtual Network Functions (VNFs) in virtual machines, to applications broken into Cloud Native Network Functions (CNFs) and microservices packaged in containers can yield tangible benefits in agility and cost for telcos. It’s not always been easy to quantify the value of that shift for applications. 

A major problem with the equation was that virtual machines in an NFV architecture required their own license or subscription for a guest operating system. Some virtualized functions required many VMs to replicate the performance and function of a physical network function (PNF). The cost of the guest OS instances was significant and grew as applications scaled out. Elimination of these costs makes the justification of going virtual much easier. Frequently, though, an issue of security is cited as a hindrance to this transition.

5G networks support network slicing and multiple tenants at all locations in the network, from the public cloud to the cell site. It’s more dynamic by definition, and containers make rapid set-up and tear down of services possible. The challenge is to provide isolation of workloads and tenants. 

This is required by regulatory bodies (public sector, financial, and health care, for instance) and by consumers of the network alike. It is vital that common exploits cannot be used to disrupt multiple applications on the same host. In addition, there is a need to ensure that the resources required by one container are not taken by another during regular operation, degrading expected performance. Multi-tenancy requires that one user’s systems never interfere with another.

Security in a contained world

Containers and Kubernetes on their own, when deployed on bare metal, do not provide the same isolation of workloads that comes with virtual machines using their own guest operating system. It is easy to forget that this is a function of the OS, not the container platform. But vendors and CSPs that partner with Red Hat for Red Hat OpenShift Platform, which includes Red Hat Enterprise Linux (RHEL), have the security features they need from the start. 

The solution to the security problem for telecom and other markets is SELinux. This set of changes for the Linux kernel originally came right from the National Security Agency (NSA) itself and it is standard with Red Hat CoreOS and RHEL. CoreOS is specifically a hardened version of Linux perfect for support of containerized applications. 

This is an important distinction. Vendors that choose to containerize their applications on other Linux distributions are faced with hardening the OS themselves. And it is reasonably common for one CNF vendor’s offering to use multiple Linux distributions for one solution due to mergers, contractual issues or the preferences of different development teams. Complexity leads to mistakes which threaten security. CSPs specifying the container platform with a requirement that vendors conform, should also consider creating guidelines for the OS. This way they can get the security they need to support their business plans.

An interim step of running containers on virtual machines also addresses the security concern. This is a more common configuration than one would think. The reason is that it is a shorter path for an application vendor to get to a generally available CNF release from a PNF or VNF, as most CSPs require. 

They can defer the security concern by depending on OpenStack or another virtual machine platform, making it another vendor’s responsibility. The tradeoff is in cost, performance, and complexity. The cost of an OS license or subscription for many VMs are still required.  Also, the complexity of two types of virtualization adds to the administration effort. This method of moving to containers is not ideal and cannot compare to the efficiency of choosing the right Linux distribution with integrated SELinux first as well as the right open source container management platform, OpenShift.

CSPs looking for a lower cost, better performing container based 5G environment should deploy one that is Kubernetes-native and move to containers entirely. 

OpenShift has been specified from the start to have the features (including SELinux) necessary to easily deploy and administer workloads in a more secure, and scalable fashion. Red Hat OpenShift is security hardened in other ways as well. 

For instance, root access for workloads is disabled by default, reducing the possibility of an oversight exposing an exploit. Red Hat works with application vendors, including 5G Core, Virtualized RAN, and enterprise workload providers on two different beneficial paths to help secure their applications and to prove interoperability. The available certification programs include an interim step for vendors who have not yet converted to a Red Hat Linux distribution. 

“Vendor Validated” solutions prove compatibility of the application with OpenShift, even if it is not deployed on a Red Hat Linux distribution. CNF vendors that utilize RHEL or RHEL CoreOS and want to be certified for interoperability with OpenShift and improved security can participate in Red Hat OpenShift CNF Certification, described here.