IBM Cloud Code Engine: Continuously Secure and Run Your Containers

Stop worrying about CVEs and get back to coding.

The use of containers is growing quickly as more and more companies are transitioning to the cloud. And with more and more critical workloads being containerized, security remains one of the biggest challenges. While containers are great, they come with their own set of security issues. In particular, making sure that your container images contain no vulnerabilities is a difficult issue, and one that is easily overlooked.

Developers love writing code, but are often not very interested or motivated when it comes to creating truly secure container images, which can be complicated and time-consuming. In this article, we’ll explain how to use IBM’s latest serverless container platform, IBM Cloud Code Engine, to solve this issue.

IBM Cloud Code Engine

IBM Cloud Code Engine is a fully managed, serverless platform that can host all of your cloud native workloads. The user experience is developer-centric and designed so that you focus on writing code instead of dealing with the underlying infrastructure and its security.

Let’s look at your options to run applications on IBM Code Engine:

You have a prebuilt image in a container registry (e.g., IBM Cloud Container Registry or dockerhub) and want to deploy it.
You have source code in a repository (e.g., GitHub) and a Dockerfile that contains the build instructions.
You have your source code in a repository (e.g., GitHub) . . . and nothing else.

All of these options come with different security and maintenance trade-offs, as outlined in the table above. Options 1 and 2 give you the biggest flexibility in terms of what can be deployed, but come at a cost. You need a build system to generate the container image, and you have the responsibility for all of its contents (e.g., for the application framework, dependencies, and base OS image layers). While some container registries (like the IBM Cloud Container Registry) help with scanning the image and then alerting you about potential vulnerabilities, the responsibility of continuously addressing these security issues is still yours.

In contrast, let’s consider option 3 in the table above and use a Java application as an example. You provide the source code and its direct dependencies and let Code Engine do the rest. All the underlying layers (operating systems, JRE, etc.) are now provided and secured by IBM. This significantly lowers your cost of maintenance and strengthens your security posture. The fewer layers you provide yourself, the fewer responsibilities you will have.

Currently, IBM Code Engine supports two build strategies, addressing options 2 and 3 above:

“Dockerfile build” (which uses the Kaniko builder tool)
“C loud Native Buildpack” (which uses the Paketo builder tool)

To use the “Dockerfile build”, you provide the application source code and a Dockerfile with your build instructions. Compared to option 1, this shifts more of the security burden to IBM (the builds will be run in a rootless and Docker deamonless approach). However, the responsibility for the application framework, dependencies, and base OS image is still yours, and you will need to continuously monitor for any new vulnerabilities and then remediate them effectively and quickly.

If you chose the “Cloud Native Buildpacks” option, all you need to provide is your source code. The Cloud Native Buildpack will detect your application language, pick a specific builder, and build an image on a base OS. IBM provides all layers underneath your source code and, therefore, takes the responsibility to maintain their security (e.g., providing an updated JRE in case of a vulnerability).

The resulting image is stored in your container registry, and if a new vulnerability occurs, it will be flagged. All you need to do is click “rebuild” to re-deploy your code on an updated and secured image (which might even be fully automated through a new option in the future).

Summary

IBM Cloud Code Engine provides three choices to run your containerized workload. If you already have an image in a registry, just run it on Code Engine “as is”. But we’d like to encourage you to use the build option and have Code Engine run container image builds for you. This will free you from the responsibility to continuously find and fix container image vulnerability issues yourself.

You can get back to what you love and focus on writing code. In a future blog post, we’ll go into more details and take a look at how IBM Cloud Code Engine actually executes the builds.