This documentation is for a release that is no longer maintained
See documentation for the latest supported version.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.
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 Copy linkLink copied to clipboard!
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.
NoteEnsure that the local clone is up-to-date.
- Create a new branch.
-
Navigate to the
component/<app-name>/overlaysdirectory, which contains subdirectories fordevelopment,stage, andprod. Follow these steps to promote the application:
Expand To move your application Do this From development to stage environment
-
Open th
development/deployment-patch.yamlfile and copy the container image URL. For example, quay.io/<username>/imageName:imageHash. -
Open the
stage/deployment-patch.yamlfile and replace the container image URL with the one you copied.
NoteTo include additional configuration changes (for example, replicas), copy them from the
development/deployment-patch.yamlfile to thestage/deployment-patch.yamlfile.From stage to production environment
-
Open the
stage/deployment-patch.yamlfile and copy the containers image URL. For example, quay.io/<username>/imageName:imageHash. -
Open the
prod/deployment-patch.yamlfile and replace container image URL with the one you copied.
NoteTo include additional configuration changes (for example, replicas), copy them from the
stage/deployment-patch.yamlfile to theprod/deployment-patch.yamlfile.-
Open th
- 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 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 Copy linkLink copied to clipboard!
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 thegit-clonetask. -
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 Copy linkLink copied to clipboard!
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