Red Hat SummitChapter 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.
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.NoteEnsure that the local clone is up-to-date.
- Checkout a new branch.
-
Within the repository, locate the
component/<app-name>/overlaysdirectory, where you’ll find thedevelopment,stage, andprodsubdirectories, 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
developmentdirectory and selectdeployment-patch.yaml. - Copy the containers image URL. For example, quay.io/<username>/<app-name>/imageurl.
-
Go to
stagedirectory, selectdeployment-patch.yaml, and replace the existing container image URL with the one copied.
NoteIf 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.yamlfile located in thedevelopmentdirectory and paste them into thedeployment-patch.yamlfile in thestagedirectory.From stage to production environment
-
Expand
stagedirectory and selectdeployment-patch.yaml. - Copy the containers image URL. For example, quay.io/<username>/<app-name>/imageurl.
-
Go to
proddirectory, selectdeployment-patch.yaml, and replace the existing container image URL with the one copied.
NoteIf 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.yamlfile located in thestagedirectory and paste them into thedeployment-patch.yamlfile in theproddirectory.-
Expand
- 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 next 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.
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
