Cloud-Native Security Was in the Air at KubeCon/CloudNativeCon 2022

As a self-identified movie buff, some movie lines somehow stick with me over the years. One of them is from Ridley Scott’s Gladiator (2000), when a Roman senator says, “The beating heart of Rome is not the marble of the Senate, it is the sand of the Colosseum.”

That line popped up in my head as I walked around the halls at KubeCon/CloudNativeCon (“KubeCon”), the marquee event for the Cloud Native Computing Foundation (CNCF). To me, the beating heart of cloud-native security is most definitely KubeCon.

This year’s North American edition of the event took place last week in Detroit, bringing together thousands of participants on-site plus many others remotely. In addition to the main three-day event, the growing interest in specific projects has led the Cloud Native Computing Foundation to set up various “co-located events” ahead of the main conference.

For the 2022 event, there was not only a specific CloudNativeSecurityCon two-day event but also plenty of security content across other events, including Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon, and more, reflecting the wide interest in cloud-native security topics. Interestingly, the CloudNativeSecurityCon event has itself now “graduated” to an independent event to be hosted separately in February.

Cloud-Native security: Development vs. Operations

So, where is the current state of cloud-native security conversations? To Omdia, there is a strong bifurcation: development-centric concerns and operations-centric concerns. It is not as helpful to call these “Dev” and “Ops” because team structure is in flux in many organizations: some may have site reliability engineering (SRE) teams, some may call them operations, platform teams, and more.

On the development side of the ledger, three topics of interest are provenance, noise, and exposure.

Provenance asks the fundamental question: Can we trust the integrity of the external component we’re incorporating into our software pipeline? While many examples exist, the 2020 SolarWinds attack was a turning point for interest in the integrity of the software supply chain. At KubeCon, there was palpable momentum behind the idea of signing software images: The sigstore project was announced as general availability and is being used by Kubernetes and other key projects.

Noise refers to reducing the number of vulnerabilities that exist in the environment, starting with slimming down the container base images that are being used. This may include using image bases such as Alpine or Debian Slim or considering “distroless” alternatives that are even smaller. The benefit is that these smaller images have minimal footprint and therefore reduced chance of vulnerabilities popping up.

Exposure: For any given vulnerability, how exposed are we as an organization? There is no better example of this in recent industry history than Log4j, of course. This is the realm of discussions on software bills of materials (SBOMs) as it relates to knowing where components may be used either as images sitting in a registry somewhere or running in production. Interestingly, as this essay is being written, there’s advance notice that information about critical vulnerabilities in OpenSSL 3.x will be disclosed imminently, which will likely be another good use case for SBOMs — just where is OpenSSL 3.x used in our organization? Given that SBOM coverage is still not widespread, Omdia expects minimal SBOM usage this time around, unfortunately.

Operations teams are naturally focused on providing and operating an increasingly complex underlying platform and doing so securely. The word “platform” is particularly relevant here: There was notable interest in organizing Kubernetes and many of the growing list of CNCF projects (140 as of this writing, between the various stages of project incubation: sandbox, incubation, graduated) into easier-to-consume platforms. Of specific interest to security audiences, projects such as Cilium (using the underlying eBPF functionality) for networking and observability, SPIFFE/SPIRE (for establishing identities), Falco (for runtime security), Open Policy Agent (for policy-as-code), Cloud Custodian (for governance), and others are worth looking into. The expectation is that these projects will increasingly collaborate with “observability” aspects of cloud-native and will also be deployed using practices such as GitOps.

Reasons for Optimism on Cloud-Native Security

Where do we go from here? It was abundantly clear that the cloud-native community cares deeply about security and is moving forward full-speed with tackling the many topics around it. The guidance to security teams is to quickly come up to speed on how these different projects and initiatives are being implemented. It’s important to note that for many organizations, this will come not in the form of explicitly using the community project (though some will), but rather as part of a packaged platform from vendors such as Red Hat, SUSE, Canonical, and others, or directly from the cloud providers such as AWS, Google Cloud, Azure, Oracle, and others.

Be aware that, in the context of open source usage, there’s no such thing as really “free” — even if one chooses to use the vanilla upstream version of projects, there are inherent costs in maintaining those packages and participating in the community development.