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.
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:
Hughes led the update on the container security Working Group’s progress. He started by noting certain facts about container security, including these six.
Next, Hughes described the working group as making four main assumptions.
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.
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.”
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.
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:
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.
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.”