Chapter 5. Deploy application and view security insights Organizations leverage a structured approach for application deployment, typically involving development, pre-production, and production stages. This process is often automated and governed by defined rules and triggers. This guide outlines deploying applications through ArgoCD in OpenShift GitOps, enabling continuous deployment across all stages. ArgoCD facilitates a GitOps-based deployment strategy, treading your Git repository as a single source of truth for your infrastructure configurations. Updates to this repository trigger deployments across environments. Note This guide shows an example deployment approach; organizations may adopt any method that suits their workflow. 5.1. Promoting a build to a pre-production or production environment Promoting a build from one environment to another (like from development to stage or production) involves updating the GitOps repository through a pull request (PR). On RHDH platform, select Catalog . From the Kind dropdown list, select Resource , and then select an appropriate GitOps repository. On the Overview tab, select View Source . (Optional) Alternatively, select Catalog , and then on the Overview tab, select View TechDocs In the Home > Repository section, select the GitOps repository. Clone your GitOps repository, and go to the component/<app-name> directory. Note Ensure that the local clone is up-to-date. Checkout a new branch. Within the repository, locate the component/<app-name>/overlays directory, where you'll find the development , stage , and prod subdirectories, each correspond to an environment. Manually move an application from development environment to the stage or production environment. To move your application Do this From development to stage environment Expand development directory and select deployment-patch.yaml . Copy the containers image URL. For example, quay.io/<username>/<app-name>/imageurl. Go to stage directory, select deployment-patch.yaml , and replace the existing container image URL with the one copied. Note If you want to promote other configuration changes (for example, replicas) in addition to the container image from the development to the stage environment, copy the changes from the deployment-patch.yaml file located in the development directory and paste them into the deployment-patch.yaml file in the stage directory. From stage to production environment Expand stage directory and select deployment-patch.yaml . Copy the containers image URL. For example, quay.io/<username>/<app-name>/imageurl. Go to prod directory, select deployment-patch.yaml , and replace the existing container image URL with the one copied. Note If you want to promote other configuration changes (for example, replicas) in addition to the container image from the stage to the production environment, copy the changes from the deployment-patch.yaml file located in the stage directory and paste them into the deployment-patch.yaml file in the prod directory. Commit and push your updates. Create a pull request (PR). This action initiates a promotion pipeline run that validates the updated container images against Red Hat Enterprise Contract (Enterprise Contract) policies. The pipeline run visually represents all tasks, with a green status signifying successful completion. Review the promotion pipeline in the CI tab within RHDH. Review and merge the PR. Merging the PR triggers ArgoCD, which then automatically applies the necessary changes to promote the build to the environment. Review the latest deployment updates in the CD tab within RHDH. It displays updates on the application's current status, deployment details, the author of the pipeline run, the commit message (for example, Promote stage to prod), and the container image advanced to production. Verification To assess the successful promotion of your application, navigate to the Topology tab. Here, you can review the application's distribution across the designated namespaces. 5.2. View security insights The promotion pipeline run offers a visual representation of all the tasks in a pipeline. A green status indicates successful completion, streamlining your workflow without extensive oversight. The promotion pipeline tasks comprise: clone-repository : Clones the specified repository into the workspace, readying it for action with the git-clone Task. gather-deploy-images : Detects container images to scan based on the changes in the PR. verify-enterprise-contract : Validates the changed container images. This task ensures images originate from a corporate standard or approved build system. It leverages the Enterprise Contract (EC) policies, working alongside Sigstore's cosign tool, to assess the integrity of image signatures and attestations. Note You can click on any tasks within the pipeline run to access logs and additional details related to that task. 5.2.1. Enterprise contract task The Enterprise Contract is a suite of tools designed to maintain software supply chain security. It allows for defining and enforcing policies related to how container images are built and tested. The Enterprise Contract ensures container images produced by Red Hat Trusted Application Pipeline meet clearly defined requirements before releasing them to production. Should an image fail to meet these criteria, the EC generates a report outlining the specific issues that need to be addressed. The Red Hat Trusted Application Pipeline build process utilizes Tekton Chains to create a signed in-toto attestation of the build pipeline. The EC then leverages this signed attestation to cryptographically verify the build's integrity and assess it against a set of policies. These policies ensure that the build process adheres to prescribed best practices and any organization-specific security guidelines. Interpreting compliance reports The detailed reports generated by Enterprise Contract (EC) scans are instrumental in providing security insights crucial for maintaining a robust security posture. Here's how to interpret these reports: Policy Compliance Overview: EC scans assess the application's compliance with the Supply Chain Levels for Software Artifacts (SLSA) security framework. The reports list the checks conducted, the status (success, warning, failure) of each check, and provide messages for any warnings or failures observed. Details Provided: Policy reports detail: Successful Checks : Counts and specifics of policy rules met. Warnings and Failures : Any policy rules that resulted in warnings or failures, with messages explaining the reason. Rule Compliance : Specifics on how well the application adheres to individual policy rules, such as source code reference and attestation checks. Figure 5.1. The EC report Utilizing the insights from compliance reports The insights gleaned EC scan reports are critical for prioritizing security and compliance efforts: Review Policy Compliance: Ensure your application's integrity by closely reviewing compliance with SLSA and other relevant standards. Address any compliance gaps as per the EC scan recommendations. Streamline Report Review: Employ provided filters within the reports to focus on significant areas, facilitating a more efficient review process and allowing for quick identification of critical issues and compliance gaps. Additional resources For more information on EC policy and configuration, refer Managing compliance with Enterprise Contract . Revised on 2024-07-15 21:03:20 UTC

Commands: