Out of the Box Supply Chain with Testing and Scanning for Supply Chain Choreographer

This topic provides an overview of Out of the Box Supply Chain with Testing and Scanning for Supply Chain Choreographer.

This package contains Cartographer Supply Chains that tie together a series of Kubernetes resources that drive a developer-provided workload from source code to a Kubernetes configuration ready to be deployed to a cluster. It contains supply chains that pass the source code through testing and vulnerability scanning, and also the container image.

This package includes all the capabilities of the Out of the Box Supply Chain With Testing, but adds source and image scanning using Grype.

Workloads that use source code or prebuilt images perform the following:

Building from source code:
1. Watching a Git Repository or local directory for changes
2. Running tests from a developer-provided Tekton pipeline
3. Scanning the source code for known vulnerabilities using Grype
4. Building a container image out of the source code with Buildpacks
5. Scanning the image for known vulnerabilities
6. Applying operator-defined conventions to the container definition
7. Deploying the application to the same cluster
8. Alternatively, outputting a Carvel Package containing the application to a Git repository. See Carvel Package Supply Chains.
Using a prebuilt application image:
1. Scanning the image for known vulnerabilities
2. Applying operator-defined conventions to the container definition
3. Creating a deliverable object for deploying the application to a cluster
4. Alternatively, outputting a Carvel package containing the application to a Git repository. See Carvel Package Supply Chains.

Prerequisites

To use this supply chain, verify that:

Out of the Box Templates is installed.
Out of the Box Supply Chain With Testing is NOT installed.
Out of the Box Supply Chain With Testing and Scanning is installed.
The developer namespace is configured with the objects according to Out of the Box Supply Chain With Testing guidance. This supply chain exists in addition to the Supply Chain with testing.
(Optional) Out of the Box Delivery Basic is installed if you want to deploy the application to the same cluster as the workload and supply chains.

Verify that you have the supply chains with scanning, not with testing, installed by running:

tanzu apps cluster-supply-chain list

NAME                      LABEL SELECTOR
source-test-scan-to-url   apps.tanzu.vmware.com/has-tests=true,apps.tanzu.vmware.com/workload-type=web
source-to-url             apps.tanzu.vmware.com/workload-type=web

If you see source-test-to-url in the list, the setup is wrong. You must not have the source-test-to-url installed at the same time as source-test-scan-to-url.

Developer namespace

This example builds on the previous Out of the Box Supply Chain examples, so only additions are included here.

To ensure that you configured the namespace correctly, it is important that the namespace has the objects that you configured in the other supply chain setups:

registries secrets: Kubernetes secrets of type kubernetes.io/dockerconfigjson that contain credentials for pushing and pulling the container images built by the supply chain and the installation of Tanzu Application Platform.
service account: The identity to be used for any interaction with the Kubernetes API made by the supply chain.
rolebinding: Grant to the identity the necessary roles for creating the resources prescribed by the supply chain.

For more information about the preceding objects, see Out of the Box Supply Chain Basic.
Tekton pipeline: A pipeline runs whenever the supply chain hits the stage of testing the source code.

For more information, see Out of the Box Supply Chain Testing.

Allow multiple Tekton pipelines in a namespace

You can configure your developer namespace to include more than one pipeline using either of the following methods:

Use a single pipeline running on a container image that includes testing tools and runs a common script to execute tests. This allows you to accommodate multiple workloads based in different languages in the same namespace that use a common make test script, as shown in the following example:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: developer-defined-tekton-pipeline
  labels:
    apps.tanzu.vmware.com/pipeline: test
spec:
  #...
        steps:
          - name: test
            image: <image_that_has_JDK_and_Go>
            script: |-
              cd `mktemp -d`
              wget -qO- $(params.source-url) | tar xvz -m
              make test

Update the pipeline resources to include labels that differentiate between the pipelines. For example, differentiate between Java and Go pipelines by adding labels for Java and Go:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: java-tests
  labels:
    apps.tanzu.vmware.com/pipeline: test
    apps.tanzu.vmware.com/language: java
spec:
  #...
        steps:
          - name: test
            image: gradle
            script: |-
              # ...
              ./mvnw test
---
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: go-tests
  labels:
    apps.tanzu.vmware.com/pipeline: test
    apps.tanzu.vmware.com/language: go
spec:
  #...
        steps:
          - name: test
            image: golang
            script: |-
              # ...
              go test -v ./...

To match the correct pipeline, you add a testing_pipeline_matching_labels parameter to the workload. For example, if you want to match to the Java pipeline, you have the following workload.yaml:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: sample-java-app
  labels:
    apps.tanzu.vmware.com/has-tests: true
    apps.tanzu.vmware.com/workload-type: web
    app.kubernetes.io/part-of: sample-java-app
spec:
  params:
    - name: testing_pipeline_matching_labels
      value:
        apps.tanzu.vmware.com/pipeline: test
        apps.tanzu.vmware.com/language: java
  ...

This matches the workload to the pipeline with the apps.tanzu.vmware.com/language: java label.

Developer workload

With the ScanPolicy and ScanTemplate objects, with the required names set, submitted to the same namespace where the workload is submitted, you are ready to submit your workload.

Regardless of the workflow being targeted, such as local development or GitOps, the workload configuration details are the same as in Out of the Box Supply Chain Basic, except that you mark the workload as having tests enabled.

For example:

tanzu apps workload create tanzu-java-web-app \
  --git-branch main \
  --git-repo https://github.com/vmware-tanzu/application-accelerator-samples \
  --sub-path tanzu-java-web-app \
  --label apps.tanzu.vmware.com/has-tests=true \
  --label app.kubernetes.io/part-of=tanzu-java-web-app \
  --type web

Create workload:
      1 + |---
      2 + |apiVersion: carto.run/v1alpha1
      3 + |kind: Workload
      4 + |metadata:
      5 + |  labels:
      6 + |    apps.tanzu.vmware.com/workload-type: web
      7 + |    apps.tanzu.vmware.com/has-tests: "true"
      8 + |    app.kubernetes.io/part-of: tanzu-java-web-app
      9 + |  name: tanzu-java-web-app
     10 + |  namespace: default
     11 + |spec:
     12 + |  source:
     13 + |    git:
     14 + |      ref:
     15 + |        branch: main
     16 + |      url: https://github.com/vmware-tanzu/application-accelerator-samples
     17 + |    subPath: tanzu-java-web-app

Scan images using SCST - Scan 1.0

By default, the Out of the Box Testing and Scanning supply chain provides scanning with Aqua Trivy scanner as part of SCST - Scan 2.0. For backwards compatibility, you can use SCST - Scan 1.0 by doing the following:

Add the following to your tap-values.yaml file:

  ootb_supply_chain_testing_scanning:
    image_scanner_template_name: image-scanner-template

To further customize the scan component, you can add the following to your tap-values.yaml file:
```
ootb_supply_chain_testing_scanning:
  image_scanner_template_name: image-scanner-template
  scanning:
    image:
      policy: SCAN-POLICY
      template: SCAN-TEMPLATE
```
Where SCAN-POLICY and SCAN-TEMPLATE are the names of the ScanPolicy and ScanTemplate.
To set workload parameters related to ScanPolicy and ScanTemplate through the CLI, run these commands:
```
tanzu apps workload apply WORKLOAD --param "scanning_image_policy=SCAN-POLICY" -n DEV-NAMESPACE
tanzu apps workload apply WORKLOAD --param "scanning_image_template=SCAN-TEMPLATE" -n DEV-NAMESPACE
```
Where:
- WORKLOAD is the name of the workload.
- SCAN-POLICY and SCAN-TEMPLATE are the names of the ScanPolicy and ScanTemplate.
- DEV-NAMESPACE is the developer namespace.

For more information, see: