Hybrid Cloud

Novel approaches to cloud native ecosystem

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

1. Integrity

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.

2. Confidentiality

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.


Senior Software Engineer, Container Security

More Hybrid Cloud stories

Mono2Micro AI speeds up app ‘refactoring’ before cloud move

To help the developers that update legacy applications, our team has created Mono2Micro (monolith-to-microservice) – an AI assistant that modernizes legacy applications to help move them to the cloud as microservices. Our tool simplifies and speeds up the often error-prone “application refactoring” process of partitioning and preserving the original semantics of the legacy, monolith applications.

Continue reading

AI goes anonymous during training to boost privacy protection

Our team of researchers from IBM Haifa and Dublin has developed software to help assess privacy risk of AI as well as reduce the amount of personal data in AI training. This software could be of use for fintech, healthcare, insurance, security – or any other industry relying on sensitive data for training.

Continue reading

Adversarial Robustness Toolbox: One Year Later with v1.4

One year ago, IBM Research published the first major release of the  Adversarial Robustness Toolbox (ART) v1.0, an open-source Python library for machine learning (ML) security. ART v1.0 marked a milestone in AI Security by extending unified support of adversarial ML beyond deep learning towards conventional ML models and towards a large variety of data types […]

Continue reading