diff --git a/1-intro/index.html b/1-intro/index.html index c633611..ed7fdaa 100644 --- a/1-intro/index.html +++ b/1-intro/index.html @@ -9,25 +9,25 @@ - The DevSecOps Workshop :: DevSecOps Workshop + The DevSecOps Workshop :: DevSecOps Workshop 2021 - - - - - - - - - - + + + + + + + + + + - + - + - @@ -505,161 +448,39 @@

Intro

-

This is the storyline you are going to follow:

+

This workshop is meant to introduce you to the application development cycle leveraging OpenShift’s tooling & features with a special focus on securing your environment using Advanced Cluster Security for Kubernetes (ACS). And all in a fun way.

+

This is the storyline you’ll follow today:

What to Expect

+

We try to balance guided workshop steps and challenging you to use your knowledge to learn new skills. This means you’ll get detailed step-by-step instructions for every new chapter/task, later on the guide will become less verbose and we’ll weave in some challenges.

-

This workshop is for intermediate OpenShift users. A good understanding of how OpenShift works along with hands-on experience is expected. For example we will not tell you how to log in with oc to your cluster or tell you what it is… ;)

+

A good understanding of how OpenShift works together with hands-on experience is expected. For example we will not tell you how to log in oc to your cluster or tell you what it is… ;)

-

We try to balance guided workshop steps and challenge you to use your knowledge to learn new skills. This means you’ll get detailed step-by-step instructions for every new chapter/task, later on the guide will become less verbose and we’ll weave in some challenges.

Workshop Environment

-

As Part of a Red Hat Workshop

-

For Attendees

-

As part of the workshop you will be provided with freshly installed OpenShift 4.10 clusters. Depending on attendee numbers we might ask you to gather in teams. Some workshop tasks must be done only once for the cluster (e.g. installing Operators), others like deploying and securing the application can be done by every team member separately in their own Project. This will be mentioned in the guide.

-

You’ll get all access details for your lab cluster from the facilitators. This includes the URL to the OpenShift console and information about how to SSH into your bastion host to run oc if asked to.

-

For Facilitators

-

The easiest way to provide this environment is through the Red Hat Demo System. Provision catalog item Red Hat OpenShift Container Platform 4 Demo for the the attendees.

-

Self Hosted

-

While the workshop is designed to be run on Red Hat Demo System (RHDS) and the environment AWS with OpenShift Open Environment, you should be able to run the workshop on a 4.14 cluster of your own.

-

Just make sure :

- -

This workshop was tested with these versions :

- +

You will be provided with freshly installed OpenShift 4 clusters running in AWS. Depending on attendee numbers we might ask you to gather in teams. Some workshop tasks must be done only once for the cluster (e.g. installing Operators), others like deploying and securing the application can be done by every team member separately in her/his own Project. This will be mentioned in the guide.

Workshop Flow

-

We’ll tackle the topics at hand step by step with an introduction covering the things worked on before each section.

-

And finally a sprinkle of JavaScript magic

-

You’ll notice placeholders for cluster access details, mainly the part of the domain that is specific to your cluster. There are two options:

- -

URL Generator for Custom Lab Guide

-

Enter your OpenShift url after the apps part (e.g. cluster-t50z9.t50z9.sandbox4711.opentlc.com ) and click the button to generate a link that will customize your lab guide.

-

Click the generated link once to apply it the the current guide.

- - - - - - - - - -

Current Domain replacement

-

Check to see if replacement is active -> <DOMAIN>

+

We’ll tackle the topics at hand step by step with an introduction covering the things worked on before every section.

@@ -863,38 +684,6 @@

Current Domain replacement

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -919,7 +708,7 @@

Current Domain replacement

- +
@@ -929,19 +718,19 @@

Current Domain replacement

- - - - - - + + + + + + - - - + + + - + + - @@ -507,21 +453,18 @@

-

During the workshop you went through the OpenShift developer experience starting from software development using Quarkus and odo, moving on to automating build and deployment using Tekton pipelines and finally using GitOps for production deployments.

-

Now it’s time to add another extremely important piece to the setup: enhancing application security in a containerized world. Using Red Hat Advanced Cluster Security for Kubernetes, of course!

+

During the workshop you went through the OpenShift developer experience starting from software development using Quarkus and odo, moving on to automating build and deployment using Tekton pipelines and finally using GitOps for production deployments.

+

Now it’s time to add another extremely important piece to the setup; enhancing application security in a conainerized world. Using the most recent addition to the OpenShift portfolio: Red Hat Advanced Cluster Security for Kubernetes!

Install RHACS

-

RHCAS Operator

-

Install the Advanced Cluster Security for Kubernetes operator from the OperatorHub:

+

Install the Operator

-

Red Hat recommends installing the Red Hat Advanced Cluster Security for Kubernetes Operator in the rhacs-operator namespace. This will happen by default..

+

Red Hat recommends installing the Red Hat Advanced Cluster Security for Kubernetes Operator in the rhacs-operators namespace. This will happen by default..

-

Installing the main component Central

+

Install the main component Central

You must install the ACS Central instance in its own project and not in the rhacs-operator and openshift-operator projects, or in any project in which you have installed the ACS Operator!

@@ -529,103 +472,36 @@

Installing the main component
  • Navigate to Operators → Installed Operators
  • Select the ACS operator
    • -
  • You should now be in the rhacs-operator project the Operator created, create a new OpenShift Project for the Central instance: +
  • You should now be in the rhacs-operator project the Operator created, create a new Project for the Central instance:
      -
    • Create a new project called stackrox (Red Hat recommends using stackrox as the project name.) by selecting Projects: Create project
      • +
    • Select Project: rhacs-operator → Create project
      • +
    • Create a new project stackrox (Red Hat recommends using stackrox as the project name.)
    • -
  • In the Operator view under Provided APIs on the tile Central click Create Instance
    • -
  • Switch to the YAML View.
    • -
  • Replace the YAML content with the following:
    • - -
    apiVersion: platform.stackrox.io/v1alpha1
-kind: Central
-metadata:
-  name: stackrox-central-services
-  namespace: stackrox
-spec:
-  monitoring:
-    openshift:
-      enabled: true
-  central:
-    notifierSecretsEncryption:
-      enabled: false
-    exposure:
-      loadBalancer:
-        enabled: false
-        port: 443
-      nodePort:
-        enabled: false
-      route:
-        enabled: true
-    telemetry:
-      enabled: true
-    db:
-      isEnabled: Default
-      persistence:
-        persistentVolumeClaim:
-          claimName: central-db
-      resources:
-        limits:
-          cpu: 2
-          memory: 6Gi
-        requests:
-          cpu: 500m
-          memory: 1Gi
-    persistence:
-      persistentVolumeClaim:
-        claimName: stackrox-db
-  egress:
-    connectivityPolicy: Online
-  scannerV4:
-    db:
-      persistence:
-        persistentVolumeClaim:
-          claimName: scanner-v4-db
-    indexer:
-      scaling:
-        autoScaling: Disabled
-        maxReplicas: 2
-        minReplicas: 1
-        replicas: 1
-    matcher:
-      scaling:
-        autoScaling: Disabled
-        maxReplicas: 2
-        minReplicas: 1
-        replicas: 1
-    scannerComponent: Default
-  scanner:
-    analyzer:
-      scaling:
-        autoScaling: Disabled
-        maxReplicas: 2
-        minReplicas: 1
-        replicas: 1
-
      +
    • Select Provided APIs → Central → Create Central
      • +
    • Accept the name to stackrox-central-services and accept the default values
    • Click Create
    -

    After the deployment has finished (Status Conditions: Deployed, Initialized in the Operator view on the Central tab), it can take some time until the application is completely up and running. One easy way to check the state, is to switch to the Developer console view on the upper left. Then make sure you are in the stackrox project and open the Topology map. You’ll see the three deployments of the Central instance:

    +

    After deployment has finished ("Status Conditions: Deployed, Initialized”) it can take some time until the application is completely up and running. One easy way to check the state is to switch to the Developer console view at the upper left. Then make sure you are in the rhacs-operator project and open the Topology map. You’ll see the three deployments of an Central instance:

      -
    • scanner
    • scanner-db
      • -
    • central
      • -
    • central-db
      • +
    • scanner
      • +
    • centrals

    Wait until all Pods have been scaled up properly.

    Verify the Installation

    -

    Switch to the Administrator console view again. Now to check the installation of your Central instance, access the ACS Portal:

    +

    Switch to the Administrator console view again. Now to check the installation of your Central instance, access the RHACS Portal:

    • Look up the central-htpasswd secret that was created to get the password
    -

    If you access the details of your Central instance in the Operator page you’ll find the complete commandline using oc to retrieve the password from the secret under Admin Credentials Info. Just sayin… ;)

    +

    If you access the details of your Central instance you’ll find the complete commandline using oc to retrieve the password from the secret under Admin Credentials Info. Just sayin… ;)

      -
    • Look up and access the route central which was also generated automatically.
      • +
    • Look up and access the route central which was also generated automatically.
    -

    This will get you to the ACS Portal, accept the self-signed certificate and login as user admin with the password from the secret.

    +

    This will get you to the RHACS portal, accept the self-signed certificate and login as user admin with the password from the secret.

    Now you have a Central instance that provides the following services in an RHACS setup:

      @@ -633,98 +509,94 @@

      Installing the main component The application management interface and services. It handles data persistence, API interactions, and user interface access. You can use the same Central instance to secure multiple OpenShift or Kubernetes clusters.

    • -

      Scanner, which is a vulnerability scanner for scanning container images. It analyzes all image layers for known vulnerabilities from the Common Vulnerabilities and Exposures (CVEs) list. Scanner also identifies vulnerabilities in packages installed by package managers and in dependencies for multiple programming languages.

      +

      Scanner, which is a vulnerability scanner for scanning container images. It analyzes all image layers to check known vulnerabilities from the Common Vulnerabilities and Exposures (CVEs) list. Scanner also identifies vulnerabilities in packages installed by package managers and in dependencies for multiple programming languages.

    -

    To actually do and see anything you need to add a SecuredCluster (be it the same or another OpenShift cluster). For effect go to the ACS Portal, the Dashboard should by pretty empty, click on either of the Compliance link in the menu to the left, lots of zero’s and empty panels, too.

    +

    To actually do and see anything you need to add a SecuredCluster (be it the same or another OpenShift cluster). For effect go to the RHACS Portal, the Dashboard should by pretty empty, click on the Compliance link in the menu to the left, lots of zero’s and empty panels, too.

    This is because you don’t have a monitored and secured OpenShift cluster yet.

    Prepare to add Secured Clusters

    -

    Now we’ll add your OpenShift cluster as Secured Cluster to ACS.

    -

    First, you have to generate an init bundle which contains certificates and is used to authenticate a SecuredCluster to the Central instance, regardless if it’s the same cluster as the Central instance or a remote/other cluster.

    -

    We are using the API to create the init bundle in this workshop, because if we use the Web Terminal we can’t upload and downloaded file to it. For the steps to create the init bundle in the ACS Portal see the appendix.

    -

    Let’s create the init bundle using the ACS API on the commandline:

    -

    Go to your Web Terminal (if it timed out just start it again), then paste, edit and execute the following lines:

    +

    First you have to generate an init bundle which contains certificates and is used to authenticate a SecuredCluster to the Central instance, again regardless if it’s the same cluster as the Central instance or a remote/other cluster.

    +

    In the RHACS Portal:

      -
    • Set the ACS API endpoint, replace <central_url> with the base URL of your ACS portal (without ‘https://’ e.g. central-stackrox.apps.cluster-cqtsh.cqtsh.example.com)
      • +
    • Navigate to Platform Configuration → Integrations.
      • +
    • Under the Authentication Tokens section, click on Cluster Init Bundle.
      • +
    • Click Generate bundle
      • +
    • Enter a name for the cluster init bundle and click Generate.
      • +
    • Click Download Kubernetes Secret File to download the generated bundle.
    -
    export ROX_ENDPOINT=<central_url>:443
-
      -
    • Set the admin password (same as for the portal, look up the secrets again)
      • -
    -
    export PASSWORD=<password>
-
      -
    • Give the init bundle a name
      • -
    -
    export DATA={\"name\":\"my-init-bundle\"}
-
      -
    • Finally run the curl command against the API to create the init bundle using the variables set above
      • -
    -
    curl -k -o bundle.json -X POST -u "admin:$PASSWORD" -H "Content-Type: application/json" --data $DATA https://${ROX_ENDPOINT}/v1/cluster-init/init-bundles
-
      -
    • Convert it to the needed format
      • -
    -
    cat bundle.json | jq -r '.kubectlBundle' > bundle64
-
    base64 -d bundle64 > kube-secrets.bundle
-

    You should now have these two files in your Web Terminal session: bundle.json and kube-secrets.bundle.

    -

    The init bundle needs to be applied to all OpenShift clusters you want to secure and monitor.

    - -

    As said, you can create an init bundle in the ACS Portal, download it and apply it from any terminal where you can run oc against your cluster. We used the API method to show you how to use it and to enable you to use the Web Terminal.

    -
    - +

    The init bundle needs to be applied on all OpenShift clusters you want to secure & monitor.

    Prepare the Secured Cluster

    For this workshop we run Central and SecuredCluster on one OpenShift cluster. E.g. we monitor and secure the same cluster the central services live on.

    Apply the init bundle

    -

    Again in the web terminal:

      -
    • Run oc create -f kube-secrets.bundle -n stackrox pointing to the init bundle you downloaded from the Central instance or created via the API as above.
      • -
    • This will create a number of secrets, the output should be:
      • +
    • Use the oc command to log in to the OpenShift cluster as cluster-admin. +
        +
      • The easiest way might be to use the Copy login command link from the UI
        • +
      +
      • +
    • Switch to the Project you installed ACS Central in, it should be stackrox.
      • +
    • Run oc create -f <init_bundle>.yaml -n stackrox pointing to the init bundle you downloaded from the Central instance and the Project you created.
      • +
    • This will create a number of secrets:
    secret/collector-tls created
 secret/sensor-tls created
 secret/admission-control-tls created

    Add the Cluster as SecuredCluster to ACS Central

    -

    You are ready to install the SecuredClusters instance, this will deploy the secured cluster services:

    +

    Now you are ready to install the SecuredClusters instance, this will deploy the secured cluster services:

      -
    • In the OpenShift Web Console go to the ACS Operator in Operators->Installed Operators
      • +
    • Go to the ACS Operator in Operators->Installed Operators
    • Using the Operator create an instance of the Secured Cluster type in the Project you created (should be stackrox)
      • -
    • If you are in the YAML view switch to the Form view
      • -
    • Change the Cluster Name for the cluster if you want, it’ll appear under this name in the ACS Portal
      • -
    • And most importantly for Central Endpoint enter the address and port number of your Central instance, this is the same as the ACS Portal. +
    • Change the Cluster Name for the cluster if you want, it’ll appear under this name in the RHACS Portal
      • +
    • And most importantly for Central Endpoint enter the address and port number of your Central instance, this is the same as the RACS Portal.
        -
      • If your ACS Portal is available at https://central-stackrox.apps.<DOMAIN> the endpoint is central-stackrox.apps.<DOMAIN>:443.
        • +
      • If the RHACS Portal is available at https://central-stackrox.apps.cluster-65h4j.65h4j.sandbox1803.opentlc.com/ the endpoint is central-stackrox.apps.cluster-65h4j.65h4j.sandbox1803.opentlc.com:443.
    • Under Admission Control Settings make sure
        -
      • listenOnCreates, listenOnUpdates and ListenOnEvents is enabled
        • +
      • listenOnCreates, listenOnUpdates and Listen On Events is enabled
      • Set Contact Image Scanners to ScanIfMissing
      -
    • Click Create
    -

    Now go to your ACS Portal again, after a couple of minutes you should see your secured cluster under Platform Configuration->Clusters. Wait until all Cluster Status indicators become green.

    -

    Configure Quay Integrations in ACS

    -

    Create an integration to scan the Quay registry

    -

    To enable scanning of images in your Quay registry, you’ll have to configure an Integration with valid credentials, so this is what you’ll do.

    -

    Now, create a new Integration:

    +

    Now go to your RHACS Portal again, after a couple of minutes you should see you secured cluster under Platform Configuration->Clusters. Wait until all Cluster Status indicators become green.

    +

    Create a serviceaccount to scan the internal registry

    +

    The integrations to the internal registry where created automatically. To enable scanning of images in the internal registry, you’ll have to configure credentials, so this is what you’ll do:

    +
      +
    • add a serviceaccount
      • +
    • assign it the needed privileges
      • +
    • configure the Integrations in ACS with the credentials
      • +
    +

    Create ServiceAccount to read images from Registry

      -
    • Access the RHACS Portal and configure the already existing integrations of type Generic Docker Registry.
      • -
    • Go to Platform Configuration -> Integrations -> Generic Docker Registry.
      • -
    • Click the New integration button
      • -
    • Integration name: Quay local
      • -
    • Endpoint: https://quay-quay-quay.apps.<DOMAIN> (replace domain if required)
      • -
    • Username: quayadmin
      • -
    • Password: quayadmin
      • +
    • Make sure you are in the stackrox Project
      • +
    • User Management -> ServiceAccounts -> Create ServiceAccount
      • +
    • Replace the example name in the YAML with acs-registry-reader and click Create
      • +
    • In the new ServiceAccount, under Secrets click one of the acs-registry-reader-token-... secrets
      • +
    • Under Data copy the Token
      • +
    • Using oc give the ServiceAccount the right to read images from all projects:
      • +
    + +
    oc adm policy add-cluster-role-to-user 'system:image-puller' system:serviceaccount:stackrox:acs-registry-reader -n stackrox
+
    +

    Configure Registry Integrations in ACS

    +

    Access the RHACS Portal and configure the already existing integrations of type Generic Docker Registry. Go to Platform Configuration -> Integrations -> Generic Docker Registry. You should see a number of autogenerated (from existing pull-secrets) entries.

    +

    Change four entries pointing to the internal registry, you can easily recognize them by the placeholder Username serviceaccount.

    +

    For each click Edit integration using the three dots at the right:

    +
      +
    • Put in acs-registry-reader as Username
      • +
    • Paste the token you copied from the secret into the Password field
      • +
    • Select Disable TLS certificate validation
    • Press the Test button to validate the connection and press Save when the test is successful.
    -

    Architecture recap

    -
    -
    -

    Click image to enlarge

    -
    -
    - +

    ACS is now able to scan images in the internal registry!

    @@ -848,22 +720,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - @@ -947,22 +803,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - @@ -997,19 +837,19 @@

    Click image to enlarge

    - - - - - - + + + + + + - - - + + + - + + - - +
    - - + + - +

    @@ -119,36 +118,12 @@ -
  • - - Install Prerequisites - - - - -
    • - - - - - - - - - - - - -
  • - + Prepare Cluster @@ -335,12 +310,12 @@ -
  • - + Securing Runtime Events @@ -359,37 +334,13 @@ -
  • - - Advanced Cluster Management - - - - -
    • - - - - - - - - - - - - -
  • - - Appendix + + Playground @@ -454,7 +405,7 @@

    More

    - > Prepare Cluster + > Playground @@ -467,9 +418,13 @@

    More

    @@ -487,7 +442,7 @@

    More

    - Prepare Cluster + Playground

    @@ -495,75 +450,36 @@

    -

    Prepare Cluster

    -

    Integrate Quay as Registry into OpenShift

    -

    To synchronize the internal default OpenShift Registry with the Quay Registry, the Quay Bridge is used. Now we need to create a new Organization in Quay:

    - -

    We need an OAuth Application in Quay for the integration:

    - -

    Now create a new secret for the Quay Bridge to access Quay. In the OpenShift web console make sure you are in the quay Project. Then:

    - -

    And you are done with the installation and integration of Quay as your registry!
    -Test if the integration works:

    - -

    Architecture recap

    -
    -
    -

    Click image to enlarge

    -
    -
    - +

    +
    + @@ -639,7 +555,6 @@

    Click image to enlarge

    - @@ -656,9 +571,6 @@

    Click image to enlarge

    - - - @@ -771,37 +683,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -823,10 +704,10 @@

    Click image to enlarge

    - + - + @@ -836,19 +717,19 @@

    Click image to enlarge

    - - - - - - + + + + + + - - - + + + - + + - @@ -504,18 +454,12 @@

    ACS Features

    UI Overview

    -
    -
    -

    Click image to enlarge

    -
    -
    - +

    System Policies

    +

    As the foundation of ACS are the system policies, have a good look around:

    +

    Filters

    -

    Most UI pages have a filter section at the top that allows you to narrow the view to matching or non-matching criteria. Almost all of the attributes that ACS gathers can be filtered, try it out:

    +

    Most UI pages have a filters section at the top that allows you to narrow the reporting view to matching or non-matching criteria. Almost all of the attributes that ACS gathers are filterable, try it out:

    -

    System Policies

    -

    As the foundation of ACS are the system policies, have a good look around:

    - - -

    By default only some policies are enforced. If you want to get an overview which ones, you can use the filter view introduced above. Use Enforcement as filter key and FAIL_BUILD_ENFORCEMENT as value.

    -
    - -

    Architecture recap

    -
    -
    -

    Click image to enlarge

    -
    -
    - @@ -747,22 +682,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - @@ -830,22 +749,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - @@ -880,19 +783,19 @@

    Click image to enlarge

    - - - - - - + + + + + + - - - + + + - + + - @@ -497,115 +447,66 @@

    Objective

    -

    You should have one or more pipelines to build your application from the first workshop part, now we want to secure the build and deployment of it. For the sake of this workshop we’ll take a somewhat simplified use case:

    -

    We want to scan our application image for the Red Hat Security Advisory RHSA-2021:4904 concerning openssl-lib.

    -

    If this RHSA is found in an image we don’t want to deploy the application.

    +

    You should by now have one or more pipelines to build your application, now we want to secure the build and deployment of it. For the sake of this workshop we’ll take a somewhat simplified use case:

    +

    We want to scan our application image for the Red Hat Security Advisory RHSA-2020:5566 concerning openssl-lib.

    +

    If this RHSA is found in an image we don’t want to deploy the application using it.

    These are the steps you will go through:

    Create a Custom System Policy

    -

    First create a new policy category and the system policy. In the ACS Portal do the following:

    - -
    -
    -

    Click image to enlarge

    -
    -
    - -

    Currently there is an issue with persisting the group change to the central instance. As a workaround run this in your Web Terminal zu restart the central instance:

    -
    oc delete pod -n stackrox -l app=central
-

    Test the Policy

    +

    Test the Policy

    Start the pipeline with the affected image version:

    - -

    To make it easier spotting the violations for this deployment you can filter the list by entering namespace and then workshop-int in the filter bar.

    -
    - - - -

    There will be other policy violations listed, triggered by default policies, have a look around. Note that none of the policies are enforced (so that the pipeline build would be stopped) yet!

    -
    -

    Now start the pipeline with the fixed image version that doesn’t contain the CVE anymore:

    -

    This shows how ACS is automatically scanning images when they become active against all enabled policies. But we don’t want to just admire a violation after the image has been deployed, we want to disable the deployment during build time! So the next step is to integrate the check into the build pipeline and enforce it (don’t deploy the application).

    -

    Architecture recap

    -
    -
    -

    Click image to enlarge

    -
    -
    - +

    This shows how ACS is automatically scanning images when they become active against all enabled policies. But we don’t want to just see a violation after the image has been deployed, we want to disable the deployment during build time! So the next step is to integrate the check into the build pipeline and enforce it (don’t deploy the application).

    @@ -761,22 +662,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - @@ -828,22 +713,6 @@

    Click image to enlarge

    - - - - - - - - - - - - - - - - @@ -878,19 +747,19 @@

    Click image to enlarge

    - - - - - - + + + + + + - - - + + + - + + - @@ -512,60 +460,40 @@

    Finally: Putting the Sec in DevSec

    There are basically two ways to interface with ACS. The UI, which focuses on the needs of the security team, and a separate “interface” for developers to integrate into their existing toolset (CI/CD pipeline, consoles, ticketing systems etc): The roxctl commandline tool. This way ACS provides a familiar interface to understand and address issues that the security team considers important.

    -

    ACS policies can act during the CI/CD pipeline to identify security risk in container images before they are started.

    +

    ACS policies can act during the CI/CD pipeline to identify security risk in images before they are run as a container.

    Integrate Image Scan into the Pipeline

    -

    You should have created and build a custom policy in ACS and tested it to trigger violations. Now you will integrate it into the build pipeline.

    -

    Our task will use the roxctl cli

    -

    Build-time policies require the use of the roxctl command-line tool which is available for download from the ACS Central UI, in the upper right corner of the dashboard. You don’t need to to download this now as our Tekton task will do this automatically.

    -

    roxctl needs to authenticate to ACS Central to do anything. You can use either username and password or API tokens to authenticate against ACS Central. It’s good practice to use a token so that’s what we’ll do.

    -

    Let’s Go : Create the roxctl token

    -

    In the ACS portal:

    +

    You should have created and build a custom policy in ACS and tested it for triggering violations. Now you will integrate it into the build pipeline.

    +

    Let’s go: Prepare roxctl

    +

    Build-time policies require the use of the roxctl command-line tool which is available for download from the ACS Central UI, in the upper right corner of the dashboard. Roxctl needs to authenticate to ACS Central to do anything. It can use either username and password authentication to Central, or API token based. It’s good practice to use a token so that’s what you’ll do.

    +

    Create the roxctl token

    +

    On the ACS portal:

    Create OCP secret with token

    -

    Change to the OpenShift Web Console and create a secret with the API token in the project your pipeline lives in:

    +

    In your OCP cluster, create a secret with the API token in the project your pipeline lives in:

    - -

    Even if the form says Drag and drop file with your value here… you can just paste the text.

    -
    - -

    Remove ImageStream Change Trigger

    -

    There is one more thing you have to do before integrating the image scanning into your build pipeline:
    -When you created your deployment, a trigger was automatically added that deploys a new version when the image referenced by the ImageStream changes.

    -

    This is not what we want! Because this way a newly build image would be deployed immediately even if the roxctl scan detects a policy violation and terminates the pipeline.

    -

    Have a look for yourself:

    - -

    Remove exactly this lines and click Save:

    -
    image.openshift.io/triggers: >-
-  [{"from":{"kind":"ImageStreamTag","name":"workshop2:latest","namespace":"workshop-int"},"fieldPath":"spec.template.spec.containers[?(@.name==\"workshop2\")].image","pause":"false"
-

    This way we make sure that a new image won’t be deployed automatically right after the build task which also updates the ImageStream.

    Create a Scan Task

    You are now ready to create a new pipeline task that will use roxctl to scan the image build in your pipeline before the deploy step: