Chapter 4. Deploying application and view security insights Deploy applications using Argo CD in OpenShift GitOps to enable continuos deployment. Argo CD uses your Git repository as a single source of truth for infrastructure configurations. Updates to the repository trigger deployments across development, staging, and production environments. Note The procedures provide an example deployment workflow. Customize it to fit your organization's requirements. 4.1. Promoting a build to a pre-production or production environment Promote a build by updating the GitOps repository through a pull request (PR). In RHDH, select Catalog . From the Kind dropdown list, select Resource , and then select a GitOps repository. Open the Overview tab and select View Source to access the repository. (Optional) Alternatively, select Catalog , open the Overview tab, and select View TechDocs . In the Home > Repository section, select the GitOps repository. Clone your GitOps repository. Note Ensure that the local clone is up-to-date. Create a new branch. Navigate to the component/<app-name>/overlays directory, which contains subdirectories for development , stage , and prod . Follow these steps to promote the application: To move your application Do this From development to stage environment Open th development/deployment-patch.yaml file and copy the container image URL. For example, quay.io/<username>/imageName:imageHash. Open the stage/deployment-patch.yaml file and replace the container image URL with the one you copied. Note To include additional configuration changes (for example, replicas), copy them from the development/deployment-patch.yaml file to the stage/deployment-patch.yaml file. From stage to production environment Open the stage/deployment-patch.yaml file and copy the containers image URL. For example, quay.io/<username>/imageName:imageHash. Open the prod/deployment-patch.yaml file and replace container image URL with the one you copied. Note To include additional configuration changes (for example, replicas), copy them from the stage/deployment-patch.yaml file to the prod/deployment-patch.yaml file. Commit and push your updates. Create a PR to start a promotion pipeline. The pipeline validates the changes against Red Hat Enterprise Contract (Enterprise Contract) policies. Check the pipeline run in the CI tab of RHDH. Merge the PR to trigger Argo CD, which applies the changes and promotes the build to the environment. Verification Use the Topology tab in RHDH to confirm the application distribution across namespace. Use CD tab to view deployment details, including the status, updates, commit message (for example, Promote stage to prod), and container image changes. 4.2. Viewing security insights The promotion pipeline includes several tasks to ensure secure and compliant deployments. The pipeline tasks include: git-clone : Clones the repository into the workspace using the git-clone task. gather-deploy-images : Extracts the container images from deployment YAML files for validation. verify-enterprise-contract : Validates the container images using Enterprise Contract (EC) policies and Sigstore's cosign tool. deploy-images : Deploys validates images to the target environment. download-sbom-from-url-in-attestations : Retrieves SBOMs for images by downloading OCI blobs referenced in image attestations. upload-sbom-to-trustification : Uploads SBOMs to Trustification using the BOMbastic API. 4.2.1. Enterprise contract task The Enterprise Contract (EC) is a suite of tools designed to maintain software supply chain security. It helps maintain the integrity of container images by verifying that they meet defined requirements before being promoted to production. If an image does not comply with the set policies, the EC generates a report identifying the issues that must be resolved. The Red Hat Trusted Application Pipeline build process generates a signed in-toto attestation of the build pipeline. These attestation cryptographically verify the build's integrity. The EC then evaluates the build against defined policies, ensuring it complies with the organizational security standards. Interpreting compliance reports EC compliance reports provide detailed insights into application security and adherence to policies. Here's how to understand these reports: Policy compliance overview: Displays the checks performed, their status, (success, warning, or failure) , and messages explaining warnings or failures. Details provided: Policy reports detail: Successful checks : Lists the policies that passed validation. Warnings and failures : Highlights policies that triggered warnings or failed checks, with explanations. Rule compliance : Shows how the application adheres to individual policy rules, such as source code references or attestation validations. Figure 4.1. The EC report Using compliance insights The insights from EC compliance reports help prioritize security and compliance tasks: Review policy compliance: Ensure your application meets standards such as Supply Chain Levels for Software Artifacts (SLSA). Address any compliance gaps based on the recommendations in the report. Streamline review: Use filters in the reports to focus on critical issues, enabling a faster and more efficient review process. Additional resources For more information on EC policy and configuration, refer Managing compliance with Enterprise Contract . Revised on 2025-02-06 17:58:30 UTC

Commands: