Customizing Red Hat Trusted Application Pipeline
Learn how to customize default software templates and build pipeline configurations.
Abstract
Preface
RHTAP empowers teams with its ready-to-use software templates and build pipeline configurations, designed to seamlessly integrate security practices into your development processes. These tools not only alleviate the burden of security considerations for developers but also enhance focus on innovation.
Cluster administrators play a pivotal role in tailoring these resources to fit the unique requirements of their on-prem environments, including:
- Customizing software templates to meet specific organizational needs
- Modifying build pipeline configurations to align with project goals
- Configuring GitLab Webhooks for automated pipeline triggers
Such customizations streamline development workflows, addressing common concerns around pipelines, vulnerabilities, and policy compliance, thereby letting developers prioritize coding.
Chapter 1. Customizing sample software templates
Learn how to customize ready-to-use software templates for your on-prem environment. Cluster administrators have full control over this process, including modifying metadata and specifications.
Prerequisites
- You have used the forked repository URL from tssc-sample-templates during the RHTAP install process.
Procedure
- Clone your forked repository, and then open it in your preferred text editor, such as Visual Studio Code.
Locate the properties file within your project directory. This file stores the default values that can customize. Open it for editing and update the following key-value pairs according to your environment.
Key Description export GITHUB_DEFAULT_HOST
Set this to your on-prem GitHub host fully qualified domain name. That is, the URL without the
HTTP
protocol and without the.git
extension. For example github-github.apps.cluster-ljg9z.sandbox219.opentlc.com. Default isgithub.com
.export GITLAB_DEFAULT_HOST
Set this to your on-prem GitLab host host fully qualified domain name. That is, the URL without the
HTTP
protocol and without the.git
extension. For example gitlab-gitlab.apps.cluster-ljg9z.sandbox219.opentlc.com. Default isgitlab.com
.export QUAY_DEFAULT_HOST
The default Quay URL correspond to your specific on-prem image registry URL without the
HTTP
protocol. For example, quay-tv2pb.apps.cluster-tv2pb.sandbox1194.opentlc.com. The default quay host isquay.io
.export DEFAULT_DEPLOYMENT_NAMESPACE_PREFIX
The namespace prefix for deployments within RHTAP. Default is
rhtap-app
.NoteUpdate this if you have modified the default
trusted-application-pipeline: namespace
during the RHTAP installation process.Figure 1.1. The properties file
Run the generate.sh script in your terminal. This action adjusts the software templates, replacing default host values with your specified inputs.
./generate.sh
./generate.sh
Copy to Clipboard Copied! Figure 1.2. The generate.sh script
Commit and push the changes to your repository. This automatically updates the template in RHDH. Alternatively, you can import and refresh a single or all customized templates directly in RHDH.
- Go to your forked sample template repository on your Git provider.
-
For a single template, from the
templates
directory, select selecttemplate.yaml
. Copy its URL from the browser address bar. For example, https://github.com/<username>/tssc-sample-templates/blob/main/templates/devfile-sample-code-with-quarkus-dance/template.yaml. Otherwise, for all the templates, selectall.yaml
and copy its URL from the browser address bar. For example, https://github.com/<username>/tssc-sample-templates/blob/main/all.yaml. - Switch back to RHDH platform.
- Select Create > Register Existing Component.
- In the Select URL field, paste the appropriate URL that you copied in Step 4b.
- Select Analyze and then select Import to update the templates in RHDH.
Verification
- Consider creating an application to explore the impact of your template customization.
Chapter 2. Customizing sample pipelines
Learn how to update Pipeline as Code (pac
) URLs within the sample templates repository and to customize the sample pipelines repository to your workflow. By customizing pac
URLs, organizations can leverage specific pipelines tailored to their needs.
Prerequisites
You have already forked and cloned the following templates locally:
Customizing the sample templates repository to update pac
URLs*
Procedure
Access forked sample pipelines repository URL:
- Open your forked sample pipelines repository.
- Copy the complete URL from the address bar. For example, https://github.com/<username>/tssc-sample-pipelines.
Update
pac
URLs in the sample templates repository- Navigate to your local cloned sample templates repository using your terminal.
- Run the following command, replacing {fork_url} with the copied URL from step 1 and {branch_name} with your desired branch name (for example, main):
./scripts/update-tekton-definition {fork_url} {branch_name} # For example, .scripts/update-tekton-definition https://github.com/<username>/tssc-sample-pipelines main
./scripts/update-tekton-definition {fork_url} {branch_name} # For example, .scripts/update-tekton-definition https://github.com/<username>/tssc-sample-pipelines main
Copy to Clipboard Copied! Review, commit, and push changes:
- Review the updated files within your sample templates repository.
- Commit the changes with appropriate message.
- Push the committed changes to your forked repository.
Customizing the sample pipelines repository to your workflow
The sample pipelines repository provides a foundation upon which you can build your organization’s specific CI/CD workflows. The sample pipelines repository includes several key pipeline templates in the pac
directory:
-
gitops-repo
: This directory holds the pipeline definitions for validating pull requests within your GitOps repository. It triggers thegitops-pull-request
pipeline, located in thepipelines
directory, validating that image updates comply with organizational standards. This setup is crucial for promotion workflows, where an application’s deployment state is advanced sequentially through environments, such as from development to staging or from staging to production. For more information about pipeline definitions ingitops-repo
, refer Gitops Pipelines. -
pipelines
: This directory houses the implementations of build and validation pipelines that are referenced by the event handlers in both thegitops-repo
andsource-repo
. By examining the contents of this directory, you can understand the specific actions performed by the pipelines, including how they contribute to the secure promotion and deployment of applications. -
source-repo
: This directory focuses on Dockerfile-based secure supply chain software builds. It includes pipeline definitions for cloning the source, generating and signing artifacts (such as.sig
for image signature,.att
for attestation, and.sbom
for Software Bill of Materials), and pushing these to the user’s image registry. For more information about pipeline definitions insource-repo
, refer Shared Git resolver model for shared pipeline and tasks. -
tasks
: This directory houses a collection of tasks that can be added or modified, aligning with organizational needs. For example, Advanced Cluster Security (ACS) tasks can be substituted with alternative checks, or entirely new tasks can be integrated into the pipeline to enhance its functionality and compliance.
Verification
- Consider creating an application to explore the impact of your template and pipeline customization.
Chapter 3. Configuring GitLab Webhooks for automated pipeline triggers
Learn how to set up webhooks and secrets in GitLab to automatically trigger pipeline run in RHDH upon code updates.
Prerequisites
- You have an existing GitLab project.
- You have administrator privileges on OpenShift web console.
Procedure
Retrieve Webhook URL and Secret Token:
- Log in to the OpenShift web console with Administrator privileges.
-
Navigate to the
rhtap
project, expand Pipelines, and then select PipelineRuns. -
Locate the
rhtap-pe-info-<>
pipeline run, and then select the Logs tab.
NoteThese logs contain the webhook URL and secret token required for GitLab configuration.
Configure Webhook in GitLab:
- Within your GitLab repository, navigate to Settings > Webhooks.
- In the URL field, enter the webhook URL copied from Step 1.
- In the Secret Token field, enter the secret token copied from Step 1.
In the Trigger section:
- Select Push events.
- Select Merge request events.
- Click Add Webhook.
Verification
- Push your code changes to the GitLab repository.
- Navigate to the CI tab in RHDH.
- Verify that a pipeline run is triggered for your code push.
Revised on 2024-07-15 21:00:30 UTC