Security has long been the biggest challenge for organizations adopting cloud-native technologies like Kubernetes. However, one look at the top CNCF projects shows a lack of security-only ventures. This was especially noticeable in 2019. However, in 2020, the CNCF took measures to include some very useful security-related projects, and the result is interesting. This article covers the top security projects featured on CNCF today and why they are relevant for your cloud-native applications.
1. Falco: Runtime security for K8s
Falco is the most significant of the CNCF security projects. It joined CNCF in October 2019 as a sandbox project, and was the first runtime security project under CNCF. It soon became an incubating project in Jan 2020.
Falco works at the Linux kernel-level, checking events against security rules and sending out alerts whenever a rule is violated. At the core of Falco are the concepts of events and rules. Events can be system calls, arguments, or properties within the system. Some events that Falco can check are containers running in privileged mode, any server process that creates a new child process, reading of a sensitive file, or starting of a new privileged pod. This is just a sample, and by using a combination of events, security professionals can create really complex and comprehensive security monitoring.
Rules are defined in a YAML config file within Falco. There are three types of information within these config files — rules, macros, and lists. Rules are the conditions that Falco needs to check for, and based on which alerts are triggered. Macros are reusable mini-rules that can be used across rules for faster rule creation. Lists are a collection of items such as binaries, which are referenced in macros and rules. Falco makes it easy to create mature and complex rules-based monitoring using macros and lists.
When it comes to Kubernetes, Falco has been adding Kubernetes-specific capabilities in recent releases. For example, the Kubernetes Audit Events feature logs all calls to kube-apiserver. Using this, Falco enables you to track all changes to a Kubernetes cluster since all cluster operations are made as requests to kube-apiserver. Another notable Kubernetes feature is Falco’s ability to turn Kubernetes pod security policies into Falco rules. This makes it a lot easier to get customized alerts for Kubernetes security monitoring.
2. SPIFFE & SPIRE: Secure identities for workloads
The next important security projects under CNCF are SPIFFEE and SPIRE. They’re both very related.
SPIFFE (Secure Production Identity Framework for Everyone) is a specification for secure identification of workloads in a distributed system such as microservices or containerized applications. It defines who has access to what. Traditionally, this was done using IP addresses at the host level. SPIFFE takes it further by securing identities at the workload or process level.
At the heart of SPIFFE are SPIFFE IDs, which are stored in documents. Each ID is unique to a workload. The document this ID is stored in is called an SVID (SPIFFE Verifiable Identity Document). While SPIFFE defines these required components, it does not actually implement any identity verification – this is done by SPIRE (SPIFFE Runtime Environment).
SPIRE handles attestation of workloads using a server and agents. A SPIRE agent sends requests to the SPIRE server for SVIDs for workloads. The server acts as the creator and signing authority for SVIDs. The agent caches the SVIDs temporarily and exposes them to other workloads as required.
SPIRE is different from other secrets management tools like Hashicorp Vault. Those tools store secret information like passwords and tokens within them and encrypt this information at rest. SPIRE does not store any existing passwords. The tokens generated in SPIRE are short-lived. This makes them more secure than traditional password-based authentication. In fact, SPIRE is often used to authenticate Vault so that services can access the passwords stored within it.
Many CNCF tools, particularly the service meshes like Istio, Kuma, Consul, and Envoy Proxy follow the SPIFFE specification for workload identification. SPIFFE and SPIRE are a sign of great progress in network security for cloud-native applications.
3. TUF & Notary: Secure software updates
TUF (The Update Framework) is a graduated CNCF project. It is a specification for managing secure software updates. Thus far, software updates have been handled by package managers, app updaters, and software library managers. They poll for new updates, and if there is an update, they download the install files and install the update, often automatically. Despite the efforts to make this process secure, there are lots of vulnerabilities at every step. Software updates are prone to installation attacks, data attacks, freeze attacks, rollback attacks, and more. TUF lays out a framework to implement an update system that is free from these vulnerabilities.
The key idea behind TUF is not to trust software update sources indefinitely and to not trust all sources equally. In other words, it recommends a way to issue time-based trust certificates or keys to each source that automatically expires. This way, trust needs to be frequently renewed and kept fresh for any source to have the ability to update a system. In a word, it’s all about “freshness” of metadata around an update.
Notary is a complementary project that is an implementation of the TUF framework. It was created by Docker and donated to the CNCF. In line with TUF’s freshness requirements, Notary issues timestamps to every update to ensure old signatures aren’t reused. These timestamps are read every time a new update is ready to be applied, and if the timestamp is outdated, the update is not applied.
There are two parts to the Notary system — a server and a signer. The server is the central part of Notary that stores, updates, and verifies TUF metadata related to any update. The most important piece of metadata it creates is the timestamp, which we discussed above. The Notary server acts as the single source of truth on the validity of updates.
The Notary signer is responsible for signing, storing, encrypting, and decrypting private keys for each update. Notary is aware that these keys can be prime targets for attacks and can be compromised. The database they’re stored in can be compromised. In such a situation, Notary makes it easy to change the keys related to a specific level of the system that’s compromised. Notary includes isolation between different parts of the system so that even if one part is compromised, the entire system isn’t exposed.
An advanced feature of Notary is delegation. It delegates or shares trust across multiple update collaborators. While this may sound risky, it actually reduces risk. You can think of delegation in Notary as RBAC for updates. It limits the authority of certain collaborators involved in an update while still giving them the least required privileges within a restricted perimeter, just enough to make the update successful.
TUF and Notary are a mature implementation of what a software update system should look like for a modern distributed application. As the number and type of components in a modern cloud-native application become increasingly complex, they are becoming a necessary part of DevOps operations.
CNCF security projects: stay tuned for more
The projects listed here aren’t the only security projects under CNCF, but they are the most important and mature ones. Other projects include in-toto, Keylime, Parsec, and cert-manager. We’ll save that for our follow-up article, which will be published tomorrow.
Featured image: Pixabay
