5 Things to Know About Secure Cloud Native Development
Cloud native development — the shift away from monolithic applications toward nimble containerized apps that can run on public, private, or hybrid clouds — is a huge disruptive wave that many enterprises are riding in their digital transformation efforts.
According to the Cloud Native Computing Foundation (CNCF), there are now 6.5 million cloud native developers around the world, 1.8 million more than in mid-2019 and representing 44% of backend developers. A majority uses open-source Kubernetes, which has become the de facto choice for container orchestration.
However, while cloud native architectures make it easier for organizations to bring new digital solutions to market faster, those applications obviously need to be secure.
Recognizing this reality, Kubernetes committers beefed up security capabilities in version 1.22, released in August. A seccomp-by-default security layer was added on top of existing seccomp support — seccomp (short for secure computing mode) being a Linux kernel feature that can be used to restrict unauthorized actions within a container.
This new feature should be a powerful tool to help reduce the surface for intrusions such as sandbox escape attacks, which allow malicious code to be executed from a sandbox outside the container’s environment.
But cloud native development security is a complex topic, and there are plenty of other important security considerations that developers should be aware of and take into account. Here are five:
1. Pick Your Dependencies Carefully
There is an abundance of resources that cloud native developers use to compose their applications. Knowing which resources to use or not to use is also an unprecedented security challenge. A recent Unit 42 study showed that 96% of third-party container images deployed on cloud infrastructure contain known vulnerabilities.
Whether it’s for OCI (Open Container Images) images on Docker Hub and elsewhere, Python packages on PyPI, Node.js packages on NPM, etc., it’s critical to continually consider what content can developers rely on and for how long. Is it of good quality? Does it contain security exposures or, worse, malicious malware code? Is it actively maintained and timely patched?
Now more than ever before, developers must exercise extreme caution and pick dependencies deliberately. Enterprises can help their developers by providing “sane defaults” for choosing software to underpin and support their applications.
2. Choose Secure and Stable Base Images
Software in container images comes in large part from the choice of a base image. Base images provide the necessary foundation for the applications to run, including shared libraries like SSL and libc, and enable developers to focus on their applications rather than the entire container.
Often, base images also tend to contain a lot more software than the applications added on top of it. And with more softwarecomes more security liability. Enterprises should approach the task of picking a secure and stable base image very carefully. Specifically:
- Is the base image regularly updated? The software it contains, is it regularly vetted for security vulnerabilities or is it composed of seldom-used libraries? After all, “with enough eyes, every bug is shallow.”
- Does the base image come with a large software ecosystem so that you can build on top of it easily by means of equally secure software? Or will you need to add to the base image from less-trusted sources?
- Is the base image developer-friendly or does it make developers’ lives harder? Hard-to-use software will often lead to developers not using it properly or cutting security corners in the name of getting stuff done, and so creating even worse security liabilities.
3. Check out Cloud Native Buildpacks.
The Cloud Native Buildpacks project was initiated by Pivotal and Heroku in January 2018 and joined the CNCF that October. Borrowing from the best Platform as a Service (PaaS) offerings of the previous generation, cloud native buildpacks enable developers to effortlessly create hardened, optimized, safe containers for code.
Kubernetes is the de facto cloud native container orchestration, but leaves a lot of important aspects of running complex applications to its users, such as handling certificates or selecting and setting up ingresses. What end users want is a comprehensive, easy-to-use, reliable PaaS with good support for components of different sizes. Buildpacks provide that.
4. Patch Early, Patch Often
Software that goes into production without known vulnerabilities might have some discovered down the road. All running software must be kept up to date to prevent breaches. Updates need to come in a timely fashion, and rolling them out must be as easy and unobtrusive as possible. This is well understood with regard to operating systems and is every bit as true for containers.
Therefore, enterprises should always make sure containers are refreshed with the latest security patches. The same applies to the runtimes and the underpinning hosts under the containers: Hard-to-move software parts such as the kernel must be updated using technologies like live patching that reduce unplanned downtime and roll out seamlessly in production-critical security updates without disruption.
5. Embrace Automation
The harder it is to patch software, the less frequent that happens. And when a vulnerability is identified, the fix needs to be rolled out quickly, reliably, and everywhere, which requires thorough automation of the rollout process. Over the last decades, as an industry we have made great strides in automating the way we build software, the continuous integration (CI) part of CI/CD. Yet the continuous delivery (CD) is not always as continuous, due to gaps in automation, which has an impact on the time it takes to roll out security fixes to our applications.
As more organizations move to cloud native development, minimizing security issues becomes ever more important. Following these five steps can go a long way in helping enterprises meet the challenge.