ONUG Working Groups “amplify voice to the vendor community,” said moderator Nick Lippis. ONUG currently has six working groups with a total of 373 volunteers that address top challenges in tech. Working groups serve as a vehicle for generating industry change. They include a diverse group of ONUG community members, including IT professionals, larger enterprise cloud consumers, vendors, service providers, and solutions integrators. 

A recent ONUG webinar highlighted four of these working groups. Over the next month, we’ll highlight each group, describing their objective, current priorities, and future plans. 

The first presenters in this webinar were from the Multi-Cloud Container Security Working Group. which includes Co-Chairs Forrest Bennett of FedEx and Michael Clark of Renaissance Tech & Media, as well as Adams Hughes with Sylabs. Watch the entire webinar, and hear about what is going on in each of these working groups. 

Container Security and Challenges

Simply put, container security involves implementing tools and policies that ensure everything in your container is running as it should, and only as intended. This includes protecting infrastructure, the software supply chain, and runtime. However, there are security concerns that arise because cloud providers do not have consistent solutions. Those challenges include:

• Container host security
• Container network traffic
• The security of the application within the container
• The security of the container management stack

Started with Assumptions

Hughes led the update on the container security Working Group’s progress. He started by noting certain facts about container security, including these six. 

• Containers are only as secure as their underlying infrastructure. There’s no protection against runtime side-channel or memory introspection attacks. 
• This Linux kernel plays a key role in security. Containerized workloads running next to each other share kernels. This means flaws can eventually reach the host and can’t be fixed at the runtime level. 
• Security models vary across different cloud providers. 
• There are no comprehensive standards between providers. 
• Security added at the cloud level doesn’t address container security.
• Container security shortfalls present opportunities for improvement that the working group aims to address. 

Next, Hughes described the working group as making four main assumptions.

1. The hardware is trustworthy.
2. The container platform and the platform used to construct the container image is trustworthy.
3. The certificate authority and encryption implementations are trustworthy.
4. The trustworthiness of the container host operating environment is confirmed. 

Reference Solution Details

The Working Group created a reference solution, based solely on open-source software. They presented it at the ONUG Spring conference. Hughes walked listeners through the structure of the reference solution.

Advantages of SIF

First, they used Singularity runtime, which has a unique set of security principles and a very opinionated runtime that reflects the image itself and not necessarily the runtime.  Hughes described the advantages of the SIF image format, which is similar to OCI images in the cloud-native community. However, SIF is different in that it has no layers. “It’s a simpler approach,” he said. “You can add whatever you need into the image and it travels around with that image.”

SIF leverages functionality that encrypts the actual root file system. This is possible in the OCI ecosystem, but SIF takes it a step further. Even while the containerized workload is running, the file system does not need to decrypt out to a disc. This provides an extra layer of confidentiality and protection. Hughes described the process this way. “The key materials are passed along with the encrypted file system to the kernel. The contents are decrypted during running, but only in memory.” 

Bind the Policy

This process creates an encrypted workload policy that travels with the image itself. The ultimate goal is to bind the policy, making it inseparable. “On the policy side, we have the open policy agent (OPA),” said Hughes. The OPA is a cloud-native policy engine that allows you to define a policy and compare that against measurements. Then, an action can be taken based on those measurements. 

The Supervisor Binary is what ties it all together. When a workload is starting up, measurements are taken about the container that’s trying to be run. Measurements are taken from the host to ensure it’s running in a safe environment. Those are all packaged up by the Supervisor Binary and sent over to the OPA, which can then run a policy.

If all goes well, the OPA holds the encryption keys to decrypt the SIF image. If those policy checks pass, the key materials pass back and the container can start running. Confidentiality and integrity are taken care of at this point. “Failability” also plays a key role, ensuring what’s running continues to run well and as expected. The final role of the Supervisor Binary is to keep an eye on what’s going on inside that container and on the host. If it’s no longer in compliance with the policy, it can then take corrective action. 

The Future of the Working Group

Michael Clark noted that Phase 1 of the Working Group’s goals focused on proving the notion that security policy is bound to a workload. It must be mobile, able to travel with the workload across various networks and environmental boundaries. Security effectiveness must also be measurable and verifiable. 

Over the next 18 to 24 months, the group will focus on moving beyond architecture. They will dive into the practice, principles, and management of cloud environments, and explore the opportunity to combine with DevSecOps. Clark described DevSecOps as “the future of security.” He summed up their future goals in these three ways:

• Continue to focus and extend the Working Group’s efforts on container security, specifically container encryption.
• Place additional focus on container management, leveraging DevSecOps to build a “container security practice” model.
• Broaden the group’s focus to address security management practices across technology domains, leveraging DevSecOps here too. 

Call to Action

There’s a lot of work to be done. Clark emphasized the need for more community participation, across all levels of involvement. He divided this call into the following categories.

• Greater community working group participation
• Enhanced cross-working group collaboration
• Greater vendor participation

He concluded by noting that the Multi-Cloud Container Security Working Group “speaks to the largest issues in tech today,” and made the appeal, “Join the conversation. Make an impact.” 

For more information on ONUG Working Groups, click here, or plan to join us at ONUG Fall to hear more about the Working Groups’ activities and progress.