Customizing Red Hat Trusted Application Pipeline


Red Hat Trusted Application Pipeline 1.2

Learn how to customize default software templates and build pipeline configurations.

Red Hat Trusted Application Pipeline Documentation Team

Abstract

This document provides instructions for cluster administrators on customizing RHTAP's software templates and build pipeline configurations to better align with the unique requirements of on-prem environments. By customizing these elements, administrators can ensure that development workflows are streamlined, security practices are seamlessly integrated, and developers can focus their efforts on innovation rather than the intricacies of security compliance and infrastructure nuances.

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

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.
  • You have already forked and cloned the tssc-sample-jenkins pipeline template.
  • You must ensure your forked version is up to date and in sync with the upstream repository.

Procedure

  1. Clone your forked tssc-sample-templates repository, and then open it in your preferred text editor, such as Visual Studio Code.
  2. 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.

    Expand
    KeyDescription

    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 is github.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 is gitlab.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 is quay.io.

    export DEFAULT_DEPLOYMENT_NAMESPACE_PREFIX

    The namespace prefix for deployments within RHTAP. Default is rhtap-app.

    Note

    Update this if you have modified the default trusted-application-pipeline: namespace during the RHTAP installation process.

    export PIPELINE_REPO_URL

    The URL of the forked pipeline repository. For example, https://github.com/redhat-appstudio/tssc-sample-pipelines.

    export PIPELINE_REPO_BRANCH

    The branch of the forked pipeline repository to which you want to point. For example, main.

    export GITHUB_DEFAULT_ORG

    The name of your GitHub organization that you want to set as default.

    export QUAY_DEFAULT_ORG

    The name of your Quay organization that you want to set as default.

    Figure 1.1. The properties file

  3. Run the generate.sh script in your terminal. This action adjusts the software templates, replacing default host values with your specified inputs.

    ./generate.sh
    Copy to Clipboard Toggle word wrap

    Figure 1.2. The generate.sh script

  4. For Jenkins only: To customize your Jenkins library, navigate to skeleton > ci > jenkins, and open Jenkinsfile. Replace the remote URL with the URL of your forked repository. For example, remote: 'https://github.com/<username>/tssc-sample-jenkins.git'.

    Additionally, if your Jenkins is on a non-local OpenShift instance, and your Rekor and TUF services are on different clusters, you need to update the REKOR_HOST and TUF_MIRROR environment variables in the env.sh file. This ensures that your external Jenkins server can communicate with Rekor and TUF installed with RHTAP. Without this, RHTAP might not sign container images correctly in the Jenkins pipeline, potentially causing this known issue.

    To update the REKOR_HOST and TUF_MIRROR variables:

    1. Open the env.sh file via skeleton > ci > gitops-template > jenkins > rhtap.

      The second env.sh file is located at skeleton > ci > source-repo > jenkins > rhtap. Pick the one that suits your needs or update both.

      In env.sh, review the default values for REKOR_HOST and TUF_MIRROR:

      REKOR_HOST=http://rekor-server.rhtap-tas.svc
      TUF_MIRROR=http://tuf.rhtap-tas.svc
      Copy to Clipboard Toggle word wrap
    2. Replace .svc with your OpenShift cluster URL. The .svc domain refers to the local cluster, and internal services can access other services with .svc in their routes, but an external Jenkins cannot.

      The correct routes of the Rekor and TUF services are printed as part of the installation process of RHTAP. If these data aren’t available to you, run this command in your CLI and select the Rekor and TUF routes in the output:

      $ oc get routes -n rhtap-tas
      Copy to Clipboard Toggle word wrap

      An example of a Rekor server URL:

      http://rekor-server.rhtap-tas.apps.rosa.j6ufg-t3htv-ts6.z797.p3.openshiftapps.com

  5. For RHACS only: To enable RHACS scans, set the export DISABLE_ACS to false in the env.sh file.
  6. 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.

    1. Go to your forked sample template repository on your Git provider.
    2. For a single template, from the templates directory, select select template.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, select all.yaml and copy its URL from the browser address bar. For example, https://github.com/<username>/tssc-sample-templates/blob/main/all.yaml.
    3. Switch back to RHDH platform.
    4. Select Create > Register Existing Component.
    5. In the Select URL field, paste the appropriate URL that you copied in Step 4b.
    6. 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:

  • You must ensure your forked version is up to date and in sync with the upstream repository.

Customizing the sample templates repository to update pac URLs*

Procedure

  1. Access forked sample pipelines repository URL:

    1. Open your forked sample pipelines repository.
    2. Copy the complete URL from the address bar. For example, https://github.com/<username>/tssc-sample-pipelines.
  2. Update pac URLs in the sample templates repository

    1. Navigate to your local cloned sample templates repository using your terminal.
    2. 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
    Copy to Clipboard Toggle word wrap
  3. Review, commit, and push changes:

    1. Review the updated files within your sample templates repository.
    2. Commit the changes with appropriate message.
    3. 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 the gitops-pull-request pipeline, located in the pipelines 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 in gitops-repo, refer Gitops Pipelines.
  • pipelines: This directory houses the implementations of build and validation pipelines that are referenced by the event handlers in both the gitops-repo and source-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 in source-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.





Revised on 2024-09-10 22:05:53 UTC

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
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