Welcome to part 2 of a two-part series on security for cloud-native applications. In part 1, we highlighted three CNCF security projects — Falco, SPIRE, and Notary, which are CNCF incubating projects. In this article, we look at four other CNCF incubating projects. Together, they make a formidable list of security tools every DevOps team should have in their IT arsenal.
1. cert-manager: Certificates as a service
cert-manager is one of the most widely used security tools in CNCF. It has become a staple for many DevOps teams, especially ones that want to implement mTLS as part of a service mesh. cert-manager was created by Jetstack, a startup that was recently acquired by Venafi. cert-manager was, unsurprisingly, the key reason behind the ideal. Venafi is a certificate-issuing service and is one of the top three certificate issuers supported by cert-manager. This being the case, Venafi found an attractive target acquisition in Jetstack.
cert-manager is a service for managing x509 certificates. These have become the de facto certificate type in Kubernetes. cert-manager elevates certificates to first-class status within Kubernetes, giving it all the privileges of native Kubernetes elements. It makes it possible to run a certificates-as-a-service even if you’re a small organization with a small Ops team. It does this by building in smart defaults and simplifying an otherwise complex certificate management process.
Apart from Venafi cert-manager also integrates with Let’s Encrypt and HashiCorp Vault. Let’s Encrypt is the most commonly used certificate issuer along with cert-manager. cert-manager is capable of working with multiple certificate issuers simultaneously. Its primary job is to ensure certificates are valid, up-to-date, and renewed when required. It does this using strong metadata around certificates. The metadata is defined in files and includes parameters like duration of the certificate, its usage, and the key it’s associated with.
cert-manager leverages Kubernetes webhooks functionality, which is a benefit of it being a Kubernetes-native extension. The prominent k8s webhooks it uses are ValidatingAdmissionWebhook, and MutatingAdmissionWebhook. It uses webhooks to implement dynamic access control over certificates.
As microservices and cloud-native architectures reach mainstream adoption in DevOps teams, security is a top concern. How services communicate with each other and process requests is vital to ensuring this security. The way this is done is with x509 certificates. cert-manager (along with Let’s Encrypt) has become the gold standard for certificate validation within Kubernetes. It is one project to keep track of as it evolves.
2. in-toto: Secure CI/CD pipelines
in-toto delivers security for software supply chains. They call a supply chain the process of writing, testing, packaging, and distributing software. This process is fraught with potential vulnerabilities at every step of the way. As code makes its way from Dev to QA to Ops teams, it passes through many tools, data stores, many hands internally and sometimes externally, and is very different at the end from what it was at the start.
in-toto aims to bring transparency to this process by showing details like who made a change, what change they made, and each step of the change. This helps to easily spot bad actors and unintended or harmful changes before a piece of code is deployed into production.
There is a caveat, though. in-toto trusts the project owner to create and define the process and, to some extent, the developers and other internal parties that handle the software. In other words, if a project owner sets up a process with no testing or allows code to be stored on unsecured servers, in-toto will not make a judgment on this process but will only highlight any changes to the process setup. Thus, in-toto is powerful and will be used by a project manager who knows their entire process end-to-end and is committed to setting it up and maintaining it to be secure. It’s for those who have a mature CI/CD process already set up and want better visibility into each step of the process. in-toto trusts only known parties along the software supply chain. This enables it to easily spot a bad actor even internally as it can be used to catch suspicious behavior or privilege escalation by bad actors internally.
The most important part of using in-toto is to create a “layout.” This layout defines the entire CI/CD process end-to-end. Further, in-toto allows sub-layouts created by Dev and QA teams to define specific sub-steps within parts of the process that they own.
in-toto is most powerful when used in combination with other CNCF security tooling projects like SPIRE and Notary, which we discussed in part 1 of this series. While it is not a silver bullet to make a CI/CD process completely secure, it is very useful for those who want deeper visibility into their CI/CD process and the ability to audit and ensure compliance at every step of the process. As CI/CD processes become more complex, a tool like in-toto is invaluable to DevOps teams ready to take their CI/CD to the next level.
3. Parsec: Abstracted hardware security
Parsec (Platform Abstraction for Security) brings security that is decoupled from the underlying hardware, and which is tied to the applications and services being secured. This hardware ranges from data centers to cloud servers, to edge infrastructure, to IoT devices. Parsec is far-reaching in this regard. Parsec implements security via software rather than hardware.
In the past, applications often ran on hardware that was dedicated to just them. This meant security for these applications could be configured via the hardware they ran on. They need only be written in a single programming language, the one used by the team building the app. This hardware-centric security configuration couldn’t be ported across different hardware.
Today, applications run on shared hardware that is virtualized via containers and VMs. Different services of a single application can span many types of hardware. They are built by teams using multiple programming languages (polyglot). These apps demand a modern security solution tied not to hardware but to the operating systems they run on. That’s what Parsec introduces.
Parsec is a collection of libraries for the major programming languages that makes it easy to configure security that is hardware-agnostic and yet works across any hardware. It handles key-based security and cryptography in a mature way customized to suit each specific application. Parsec is the kind of security that works not just for cloud-native, but for the fast-growing world of edge computing.
4. Keylime: TPM-based hardware security
The final project that we have time to only touch upon is Keylime. It improves security at the edge and for IoT. Keylime does remote boot attestation. It enables you to monitor remote nodes by performing trusted boot checks and runtime integrity monitoring. Keylime is based on the Trusted Platform Module (TPM), a chip-based approach to hardware encryption. It provides confidence when verifying that devices are tamper-proof. Developed by MIT, Keylime has been recently adopted as a CNCF sandbox project.
CNCF security projects: A must for DevOps
The CNCF is doing much to bolster the security of applications from the cloud to the edge. Apart from these four CNCF security projects, there are additional monitoring tools that help with security monitoring. They are Thanos, Cortex, and Prometheus. The CNCF is at the heart of the cloud-native revolution, and these security tools should be part of every DevOps team.
Featured image: Pixabay