Kubernetes-Related Security Projects to Watch in 2023

January 12, 2023 TH Author 0 Comments

It’s not so much whether organizations are using Kubernetes today, but how they are expanding its use. The use of multiple clusters, for example, is increasing and moving across organizational boundaries. Kubernetes itself is being shored up to meet the resulting security issues. The newest version, Kubernetes 1.26, adds features designed to strengthen the chain of trust, among other security updates. In fact, there are a number of projects organizations should be watching — and potentially evaluating — to ensure they are optimizing their use of Kubernetes while building stronger security, observability, governance, and compliance.

SPIFFE and SPIRE

Identity for everything is an important part of securing your Kubernetes environment, but end-to-end identity is still an unsolved problem — especially in multicluster Kubernetes environments. Say you have a service in Kubernetes and you need to authenticate to an off-cluster service that’s running in the cloud or on-premises. How do you ensure you have a secure chain of identity from the launch of the service to all of the things it’s communicating with and connecting to — on and off cluster?

The SPIFFE project is a set of open source standards for securely identifying software systems in workloads across heterogeneous environments and organizational boundaries. Secure Production Identity Framework for Everyone (SPIFFE) defines short-lived cryptographic identity documents, or Shadow Virtual Intrusion Detection System (SVIDS), that workloads can use to authenticate to other workloads. SPIFFE’s partner in identity is SPIRE, the SPIFFE runtime environment. SPIRE implements the SPIFFE spec, enforcing multifactor attestation to issue identities. While there is still work to be done, the SPIFFE and SPIRE projects — both incubated by the Cloud Native Computing Foundation (CNCF) — are helping set the groundwork not only for end-to-end identity but also zero trust.

Sigstore

The old adage that a chain is only as strong as its weakest link couldn’t be truer than when it comes to the software supply chain. As shown by the rash of supply chain hacks we’ve seen in the past few years — attacks that are likely to increase as the stakes grow higher — it’s increasingly important to ensure that nothing in the supply chain has been tampered with. One of the ways to do that is to sign everything — especially if you are doing everything (or even most things) as code.

Sigstore — under the auspices of the Linux Foundation — is intended to make cryptographic signing in the supply chain easier. Sigstore removes the cryptography burden from developers, enabling them to use an email address via the OpenID Connect (OIDC) protocol as a preexisting identifier to sign their code. We’re seeing organizations implement Sigstore in more traditional ways, but it will be interesting to see if they adopt OIDC-based signing (through the Fulcio portion of the Sigstore project) and the Rekor signature log as a more agile way to manage signing and attestation of signatures or verification of signatures. It will also be interesting to see if Sigstore is eventually implemented not just in new products, but also within the enterprise itself.

Kyverno and OPA Gatekeeper

Kyverno, which provides Kubernetes-native policy management, is a project to watch because organizations are paying more attention to admission policies, particularly as the Kubernetes community moves toward pod security admission. There are only three profiles associated with Kubernetes-native pod security admission — a model that is simple by design. If you want more complexity, you need to go with something like Gatekeeper and Open Policy Agent (OPA). Some organizations find Kyverno easier to use with Kubernetes. It’s YAML-based, so it doesn’t require learning a new language. However, other organizations have invested in learning Rego, the language used with Open Policy Agent, as OPA is a general-purpose policy engine that can be used to automate policies throughout the stack. Indeed, there are a variety of open source policy engines available right now. The real question is whether the landscape will continue to be dotted with engines that have varying degrees of integration with Kubernetes, or if one will eventually become the de facto standard.

eBPF-Based Projects

Kubernetes and the technologies it works with rely heavily on core Linux capabilities. One of these is Extended Berkeley Packet Filter(eBPF), which is increasingly used in networking, security and auditing, and tracing and monitoring tools. Importantly, when it comes to runtime security, eBPF provides observability at a deep level. You can’t secure what you can’t see, and eBPF provides the level of observability you need for Kubernetes and container platforms in a more consumable fashion. eBPF is being leveraged by many projects, including Falco, a Kubernetes runtime security tool, and Cilium, which provides, secures, and observes network connectivity among container workloads. The biggest indicator of which projects will rise to the top is how nicely they play with Kubernetes. For example, Cilium is interesting because it is written in Go rather than C, which makes it easier to integrate into Kubernetes.

Kubernetes Networking Projects

We’re seeing more and more organizations deploy multiple clusters, with the resulting need for solutions that communicate or interact across clusters. Skupper is interesting because it enables organizations to create a kind of virtual application network from namespaces in one or more Kube clusters. It’s a whole new approach to managing communication between clusters, negating the need for VPNs or special firewall rules. The Gateway API, which comes from the Kube SIG Network, is working to evolve and secure Kubernetes service networking to make it more extensible, with a set of APIs that push it beyond L3 to L4 and L7. Gateway API is an open source project managed by the SIG Network community.

Conclusion

As organizations expand their use of Kubernetes, they must constantly be vigilant about balancing performance gains with security, governance, and compliance.