Organizations are increasingly turning to agile development models and DevOps. This approach enables development organizations to deliver more enhancements and bug fixes in a timely manner, which provides more value to their users.
While DevOps can include security earlier in the software lifecycle, this has not always been the case in practice. DevSecOps explicitly calls on organizations to pay attention to security best practices and to automate them or "shift left" as much as possible.
[ How to explain DevOps in plain English ]
DevSecOps means baking in application and infrastructure security from the start. To be successful, organizations must look upstream, where their dependencies come from, and also at how components integrate in the production environment. It also means automating security gates to keep the DevOps workflow from slowing down. As you learn from experience, you codify that into the automation process.
DevSecOps supply chain best practices
A successful DevSecOps-based supply chain must consider four areas of concern:
- Security of developer dependencies
- Security of code development
- Security of deployment of resources into a secure environment
- Software bills of materials (SBOM)
Within each of these areas, there are many best practices to apply, especially in cloud-native development using container technology:
- Scanning new development code for potential vulnerabilities
- Scanning dependent images that new code will be layered upon
- Attesting to the veracity of images using image signing
- Scanning images for known CVEs
- Scanning the environment for potential networking vulnerabilities
- Scanning for misconfigurations of images and other assets
- Ensuring consistent automated deployment of secure configuration using GitOps
- Continuous upgrading of security policies from both trusted third parties and your experience
[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]
Multicluster DevSecOps validated pattern
Validated patterns are detailed deployments created by Red Hat for various use cases. These predefined configurations combine products from the Red Hat portfolio and technology ecosystem to help stand up architectures faster.
This pattern deploys the following Red Hat products:
- Red Hat OpenShift Container Platform (OCP), a Kubernetes platform
- Red Hat OpenShift GitOps based on ArgoCD
- Red Hat Advanced Cluster Management (ACM) based on Open Cluster Management
- Red Hat OpenShift Pipelines based on Tekton
- Red Hat Quay, an Open Container Initiative (OCI) image registry with security features enabled
- Red Hat Open Data Foundation for highly available storage
- Red Hat Advanced Cluster Security (ACS) for scanning and monitoring
All the components in this pattern can be deployed on a single cluster. This makes for a simple demo. This pattern deploys a real-world architecture where central management, development environments, and production are all deployed on different clusters. This ensures that the pattern is structured for real-world deployments, with all the functionality needed to make such an architecture work already built in. This allows pattern consumers to concentrate on what is being delivered, rather than how it's delivered.
The heavy lifting in the pattern includes a great deal of integration between components, especially those spanning across clusters:
- Deployment of Quay Enterprise with OpenShift Data Foundations as a storage backend
- Deployment of a Quay Bridge operator configured to connect with Quay Enterprise on a hub cluster
- Deployment of ACS on managed nodes with integration back to ACS central on the hub
- Deployment of a secure pipeline with scanning and signing tools, including ACS
[ Kubernetes: Everything you need to know ]
DevSecOps and pipelines
In Introducing OpenShift Pipelines, Jaafar Chraibi notes that "OpenShift Pipelines makes CI/CD concepts such as a pipeline, a task, or a step natively instantiatable so it can use the scalability, security, and ease of deployment capabilities of Kubernetes." The pattern consumes many of the OpenShift Pipelines' out-of-the-box tasks but also defines new tasks for scanning and signing. It also includes them in enhanced DevSecOps pipelines.
While these pipelines are included in the pattern, the pattern also implements the use of a pipelines-as-code feature where the pipeline can be part of the application code repository. "This allows developers to ship their CI/CD pipelines within the same Git repository as their application, making it easier to keep both of them in sync in terms of release updates."
CI pipeline to support software supply chain security
This pattern includes some other technologies in the development continuous integration (CI) pipeline, including Cosign, a Sigstore project, implemented with Tekton Chains. Cosign supports container signing, verification, and storage in an OCI registry. It enables consumers to sign their pipeline resources, images, and share the attestation files. This provides downstream consumers assurances that they are consuming a trusted artifact.
This design also implements open source tools SonarQube for static code analysis, Nexus for securely storing build artifacts in-cluster, and an open source reports application to upload and present the reports from the security pipeline.
It's not a problem if you're not using these tools in your environment. The pattern framework is flexible. Organizations using different services can swap out what's in the pattern with their software of choice to fit their environment.
This pattern provides a complete deployment solution for multicluster DevSecOps that can be used as part of a supply chain deployment pattern across different industries.
The documentation provides detailed instructions for how to install the pattern and more technical details about the different components in the pattern.
This originally appeared on Hybrid Cloud Patterns and is republished with permission.