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.

Promote a build by updating the GitOps repository through a pull request (PR).

  1. In RHDH, select Catalog.
  2. From the Kind dropdown list, select Resource, and then select a GitOps repository.
  3. Open the Overview tab and select View Source to access the repository.
  4. (Optional) Alternatively, select Catalog, open the Overview tab, and select View TechDocs.

    1. In the Home > Repository section, select the GitOps repository.
  5. Clone your GitOps repository.

    Note

    Ensure that the local clone is up-to-date.

  6. Create a new branch.
  7. Navigate to the component/<app-name>/overlays directory, which contains subdirectories for development, stage, and prod.
  8. Follow these steps to promote the application:

    Expand
    To move your applicationDo this

    From development to stage environment

    1. Open th development/deployment-patch.yaml file and copy the container image URL. For example, quay.io/<username>/imageName:imageHash.
    2. 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

    1. Open the stage/deployment-patch.yaml file and copy the containers image URL. For example, quay.io/<username>/imageName:imageHash.
    2. 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.

  9. Commit and push your updates.
  10. Create a PR to start a promotion pipeline. The pipeline validates the changes against Red Hat Enterprise Contract (Enterprise Contract) policies.

    1. Check the pipeline run in the CI tab of RHDH.
  11. Merge the PR to trigger Argo CD, which applies the changes and promotes the build to the next 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.





Revised on 2025-02-06 17:58:30 UTC

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat