In a containerized environment, the software build process is the stage in the life cycle where application code is integrated with the required runtime libraries. Managing this build process is key to securing the software stack. Adhering to a "build once, deploy everywhere" philosophy ensures that the product of the build process is exactly what is deployed in production.
It is also important to maintain the immutability of your containers; in other words, do not patch running containers, but instead rebuilt and redeploy them.
Using {product-title} as the standard platform for container builds enables you to guarantee the security of the build environment as well.
{product-title} provides a number of capabilities as it relates to build management and security:
-
Source-to-Image (S2I) is an open source framework for combining source code and base images. {product-title} provides a set of builder images that make use of S2I under the covers to make it easy for your development and operations teams to collaborate on a reproducible build environment.
When a developer commits code with Git for an application using build images, {product-title} then:
-
can be triggered, either via webhooks on the code repository or some other automated continuous integration (CI) process, to automatically assemble a new image from available artifacts, the S2I buidler image, and the newly committed code.
-
automatically deploys the newly-built image for testing.
-
if driven by a CI process, can promote the tested image to production where it can be automatically deployed.
-
-
{product-title} includes and can be easily integrated with Jenkins for CI.
-
The included OpenShift Container Registry can be used to manage access to final images, just as you would manage access to the output of any other production build. Both S2I and native build images are automatically pushed to the OpenShift Container Registry.
-
With rich RESTful APIs, you can also integrate your own build / CI environment with {product-title}, as well as use any API-compliant image registry.
-
{product-title} Developer Guide
-
{product-title} Architecture: Source-to-Image (S2I) Build
-
{product-title} Using Images: Other Images → Jenkins
In some scenarios, build operations require credentials to access dependent resources, but it is undesirable for those credentials to be available in the final application image produced by the build. You can define input secrets for this purpose.
-
{product-title} Developer Guide: Input Secrets
Whether you work in a highly regulated industry, or simply want to optimize your team’s efforts, design your container image management and build process to take advantage of container layers to implement separation of control, so that your:
-
Operations team manages base images.
-
Architects manage middleware, runtimes, databases, and other solutions.
-
Developers focus on application layers and just write code.
Knowing that new vulnerabilities are identified daily, you need to proactively check container content over time. One of the best ways to do this is to integrate automated security testing into your build or CI process. For example:
-
SAST / DAST – Static and Dynamic security testing tools.
-
Scanners for real-time checking against known vulnerabilities. Tools like these catalog the open source packages in your container, notify you of any known vulnerabilities, and update you when new vulnerabilities are discovered in previously scanned packages.
Additionally, your CI process should include policies that flag builds with issues discovered by security scans so that your team can take appropriate action to address those issues sooner rather than later.
Red Hat also recommends that you sign your custom built containers so that you can be sure they are not tampered with between build and deployment.
-
Red Hat Enterprise Linux Atomic Host Managing Containers: Signing Container Images