November 19, 2020 | Written by: Brandon Lum
Categorized: Hybrid Cloud | Security
Share this post:
Security in today’s cloud native ecosystem is evolving, and building high assurance security in cloud native is not just about copy-pasting traditional security controls, but about exploring novel approaches to adapt to the new paradigm. At KubeCon this week, I explained how to close cloud native security gaps, thus improving cloud native projects from the community at large.
As we see highly regulated industries like federal, financial and medical, make their move to cloud native projects, we start to see an emphasis on control points on integrity and confidentiality of workloads and their underlying infrastructure. This is due to the critical nature of some of these components, as well as from regulatory requirements, such as FISMA, HIPAA, GDPR, PCI-DSS, etc. As the amount of sensitive data and critical workloads in cloud native platforms grow, so do the requirements for security and compliance.
In fact, we can see the effects of this shift in the Cloud Native Computing Foundation (CNCF) community, as many new security focused projects are coming into and maturing within the CNCF, as well as the creation and growth of the CNCF special interest group for security, SIG-Security.
The top three ways to protect cloud native projects
To protect their workloads, organizations need to:
- Know that only approved workloads are running
- Know the provenance of the workloads
- Know what they contain.
- Do they come from a trusted source? Can I trust my supply chain?
- What type of regulatory controls has this workload undergone?
In the community, we see multiple efforts addressing these problems in the ecosystem. These requirements above are usually solved through a set of frameworks coupled with cryptographic signing. Within the cloud native ecosystem, we have seen the creation of several projects and technologies such as Docker Content Trust (DCT), Red Hat Simple Signing, Notary, Portieris, which focus on the integrity and provenance of container workloads.
the community also taps into academic research to develop these technologies. For example, Notary is based on The Update Framework (TUF), which stemmed from research at NYU’s Secure Systems Lab. We’ve seen a lot of great community feedback on these technologies as more and more users start to integrate them into their security framework. The Notary project has gotten a second wind recently, and a Notary v2, is now in the works!
Supply Chain has also been another emphasis within this area – the project in-toto (also stemmed from NYU), aims to solve the supply chain problem across multiple vendors from the group up. CNCF SIG-Security also maintains a Security Chain Compromise Catalog together with information about such threats.
Orthogonal to the integrity of the workloads is also the confidentiality of the workloads, and ensuring only authorized systems and users are able to view and use the workload. Some of the requirements include:
- Protect sensitive workloads, such as trade secrets, proprietary algorithms, from compromise
- Ensure that the workload is only run on approved clusters
- Perform geofencing and export controls (i.e. only run within the EU)
There have been recent efforts in the community such as Encrypted Container Images to address these problems. This work was started by IBM Research, and is part of the ecosystem, from build tools such as buildah, skopeo, to runtimes like containerd and cri-o that support the use of encrypted images. Together with appropriate key management, trust bootstrapping, and trust attestation, it is possible to make statements like “Only run my workload in an EU cluster.”
Another interesting area to take note of is encrypted memory technology and confidential computing. These are based around hardware capabilities such as AMD SEV, Intel TDX and IBM Power PEF. These can be combined with the use of encrypted workloads to ensure the workload is encrypted even when it is running!
There is more work that needs to be done in this area, and I believe Kata Containers is in a good position to take advantage of these ideas.
3. Cryptographic Attestation and Zero Trust
Being able to tie a workload to a host and being able to measure and attest what is running on the host is an important factor in several industries. This allows a user to keep close watch on the inventory and know that the underlying infrastructure is secure and protected, answer questions like:
- Where is my compute node? Which datacenter, and region is it in?
- What is it running? Is it running a patched kernel/OS?
- How do I know it has not been tampered with?
- How do I deal with nodes which may be physically compromised, such as Edge and 5G, and zero-touch provisioning?
The foundation of solving these problems usually stem from security hardware, such as TPM, UEFI, HSMs, among others. There is a lot of work already done in Linux (i.e. IMA, Grub2, secure boot, others) to ensure that it is possible to attest all the software that the machine is booted up secured and measured. On top of that, there were two projects Keylime, and PARSEC, that recently became CNCF sandbox projects, which help cloud native workloads take advantage of these ideas. These technologies help to establish trust with the infrastructure.
However, being able to attest the host and the software is just the start. How do we make use of this trust that we’ve established?
This is where the concept of Zero Trust and Identity comes in. How do we establish a way for workloads to authenticate, and communicate securely, and how do we then govern resources? The SPIFFE and SPIRE project provides an identity framework to authenticate workloads, the Keycloak project is one way to perform authorization and user management, and projects like IBM Research Trusted Service Identity helps to tie these technologies and concepts together into a framework.
Just the Surface
I’ve just scratched the surface of security in the cloud native ecosystem. There are many other aspects of cloud native security. CNCF SIG-Security has written a whitepaper to dive deeper into this. And if you’d like to be more involved with the Cloud Native Security community, definitely drop by SIG-Security. And if you are going to be at Kubecon NA 2020 Virtual, drop by our session: A Special Interest in Cloud Native Security.
Inventing What’s Next.
Stay up to date with the latest announcements, research, and events from IBM Research through our newsletter.