At Red Hat Summit 2023, the engineering team announced two projects that will change the way developers and ops develop and deploy their applications to Red Hat OpenShift. These projects are the Red Hat Trusted Application Pipeline and the Red Hat Developer Hub. They are a little different from the usual Red Hat products in that they directly address critical composite problems in the DevSecOps space that customers are starting to experience issues.
Red Hat has long been acknowledged as the provider of enterprise strength frameworks and platforms, notably Red Hat Enterprise Linux and OpenShift, the enterprise distribution of Kubernetes. Both are incredibly powerful product sets, but to get the most out of them, we have to understand and use them as experts would. Most developers and ops personnel don’t have the time, on top of their day-to-day jobs, to learn every aspect of the underlying technology. The likely result of this missing knowledge is the eventuality of various security issues.
The problem
The key issue with deploying applications nowadays is a combination of a lack of domain knowledge when it comes to using and exploiting all the power of Kubernetes, and an obliviousness of potential risks within the code itself, both the code written by the developer and, more importantly, risks within code that is sourced external to the organization, such as imported libraries.
I come from a developer background, and developers are focused on delivery. We build our pieces of software, we use external libraries when we don’t want to reinvent the wheel, and we want to be creative. Our focus is always on our creativity. Is our code good enough? Have we written it securely? Have we written it to be efficient? We make assumptions about the libraries we import and use because we don’t have time to review every single line of code in them. We’re always busy writing and delivering the code we own.
This became all too evident with the Log4j Log4Shell vulnerability. Java developers had been using Log4j for years without knowing it had a critical vulnerability in it. We just assumed it was fine to use because it’s a library. The more cynical of us would say, “not our problem,” because we don’t have responsibility for that code. We make assumptions about the code of the libraries because they work.
Now that we live in the generation of the container, this problem has gotten a little bit worse. Not only do we now have the capability to import exploits through libraries and external software, we also have the ability to use base images for our containers that might contain hidden exploits. This new concept of inherited flaws falls somewhere between the developer and the ops person. The developer has responsibility not to use any code with known exploits. The ops person has the responsibility not to deploy exploitable components.
There are solutions involving external software, but there will always be an issue with something being potentially exploitable.
The solution: Red Hat Trusted Application Pipeline
Red Hat has built a product specifically to address this risk of unexpected vulnerabilities in a way that makes it easy for developers and ops to deploy applications to OpenShift without the worry of exploit injection during the build process. In fact, we’ve gone one step further. This new service not only handles the build, assembly, and deployment of cloud-native applications to target Kubernetes platforms, but it also wraps the whole process in a highly secure and manageable workflow.
In addition, the nature of container orchestration platforms, Kubernetes in particular, means that this kind of operation, building and deploying applications, can be painfully complicated. Throw in new technologies like Tekton for automating everything as pipelines, and suddenly, both developer and ops must be highly skilled in Kubernetes to deploy their applications. This should never be the case. Tools should assist and ease the operation in a problem space. Kubernetes is complicated by design, but it can and should be simplified in such a way as to abstract deep knowledge to the point that a user can just get on with their jobs rather than having to become an expert.
Red Hat has done this with Red Hat Trusted Application Pipeline, which is set to revolutionize and secure the way you build and deploy applications in today’s container era.
What is Red Hat Trusted Application Pipeline?
Red Hat Trusted Application Pipeline is a hosted and managed service to securely build and assemble next generation cloud-native applications and deploy them to target environments. It is designed from the ground up to be both extensible and rigidly enforced, and to provide maximum secure oversight during the build process, including digital audit assets (software bill of materials, SBOM) to temporally stamp and guarantee build source integrity.
In essence, a user can simply log in to the Trusted Application Pipeline system and in the space of thirty seconds, set up an application that imports preexisting, precoded (e.g., a Git repository) templates provided by Red Hat source and executes a source-specific build to produce container images you can deploy to configurable target environments. In fact, Trusted Application Pipeline provides a static environment to deploy applications as a test if you have no current environments.
The basic approach provides a simple pipeline for application creation. Clone a Git repository, execute a build if necessary to generate the application binary components, assemble an image, and deploy that image as a Kubernetes application. And this works, but the real strength of the product comes in the form of customizable pipelines.
By adding the provided GitHub application from the Trusted Application Pipeline, the service can interact directly with the Git repo and create a definition for the assemble/build pipeline that travels, defined as code, with the repository itself. The default pipeline provided for this does important tasks, including scanning the code itself for exploits (source code analysis), scanning the created image created for exploits (static image analysis), generates an immutable SBOM for the audit of components used to create this composite application so that the user can add additional steps, such as additional code analysis and pretty much anything else you can do with Tekton tasks.
Tekton’s pipelines-as-code is a fantastic and simple-to-use technology that decouples the definition of the pipeline itself from the execution point. This means that a specific pipeline for the user’s build operation is part of the code repository itself, the ultimate config-as-code approach. Pipelines-as-code is available as an Red Hat OpenShift Pipelines component and works perfectly within the Trusted Application Pipeline to allow the pipeline customization to travel with the code itself, rather than being a separate set of Kubernetes objects that have to be maintained apart from the codebase.
The code scanning, image scanning, and SBOM-generation components provide what is known as shift left for DevSecOps, which means being able to automate the scanning of components, code, and image content on each and every pull request. Tying the execution of these critical security processes into the build process, driven by every submitted code change, makes it possible to detect security issues much earlier in the process, which is critical when looking for assurance of the software itself.
Red Hat Trusted Application Pipeline provides out-of-the-box support for the SLSA level 3 (refer to the requirements) that targets tampering during the build process. The Trusted Application Pipeline is a managed and hosted solution, meaning that it can be hardened from a secured-platform perspective. So you as a user do not have to harden or worry about it yourself. Combine this with access to the current set of defined CVEs from Red Hat, and detection of newly discovered and known exploits is as fast as it can be.
On top of this extensive set of security tools, Red Hat Trusted Application Pipeline allows DevOps to get their application build cycle into a completely stand-alone automated process triggered simply by a git push or the acceptance of a pull request. All of this is automated and wrapped by the GitHub application which is easily installed in the user’s Git repo by a single click from within the Red Hat Trusted Application Platform.
The bigger picture
For those who are aware of and adhere to the concepts of the inner and outer loop approach to CI/CD, the Red Hat Trusted Application Pipeline and the newly announced Red Hat Developer Hub (RHDH) provide a completely end-to-end solution for both the inner and outer loops.
RHDH is a fantastic extensible developer portal/application architecting solution that covers the code->build->test->(git push)->repeat cycle of the inner loop.
The Trusted Application Pipeline covers the whole (git repo)->scan code->build->scan image->deploy->repeat cycle of the outer loop.
What makes Red Hat Trusted Application Pipeline so great is not only that it automates, secures, and assures all of the build and deployment process, but it is also offered in an opinionated, easy-to-use, and incredibly innovative set of wizards. Creating an application is as simple as providing a target Git repository. Red Hat Trusted Application Platform will automatically scan the repo and suggest target frameworks. At any point in the process, users can edit and add to the context. For example, adding additional Git information, targeting branches, subdirectories, and so on. All interactions are contextual. The system knows what you are trying to do and will provide useful hints, tips, and help for all operations.
A user can also extend their applications by adding as many additional components as they like. When they do, each and every component has its own build/deploy pipeline that you can customize, meaning that if certain components need additional processing, you can extend their pipelines without compromising or complicating any other component’s pipeline.
Put simply, Red Hat Trusted Application Pipeline provides a much needed and necessary toolset for building, securing, and deploying applications to the next generation of Kubernetes-based platforms, most notably OpenShift, which has close to a decade of experience in managing Kubernetes deployment workloads. Red Hat Trusted Application Pipeline eliminates the complexity and worry of the process of taking source code through to deployed images, allowing developers to focus on writing the actual software they need to produce, while ops can better focus on making sure the infrastructure and platforms to deploy to are secure and ready to host.
OpenShift has Advanced Cluster Security (ACS) for Kubernetes, which operates at the object and image level, providing runtime security of clusters. Red Hat Trusted Application Pipeline preempts any emergent application problems from exploits in the code, the libraries used as part of the build, and the file-layers of the image. Think of the Trusted Application Pipeline as the automated watchman on the build process gates and ACS as the runtime policeman.
Summary
Red Hat Trusted Application Pipeline and RHDH comprise a composite solution that will make it far easier and more secure to create, deploy, and host applications in the container era. Together, they deliver a seamless developer experience that increases their productivity without additional cognitive load or heavy context switching.
Both products take advantage of the concept of Golden Paths, which are defined but configurable guided routes to end states, making it easier for developers and ops to achieve what they need in the quickest and most secure way possible. The combination of these two new products provides a powerful and essential solution to the day-to-day issues facing an organization adopting DevSecOps in a container-centric world.
Want to try it out? Visit Red Hat Trusted Software Supply Chain and sign up for free access.
Last updated: March 26, 2024