End-of-Life (EoL)

CloudBees Core pipeline on Kubernetes

CloudBees Core is the successor to CloudBees Jenkins Platform and CloudBees Jenkins Enterprise. This article explains how to integrate the Prisma Cloud Jenkins plugin with a CloudBees Core build pipeline running in a Kubernetes cluster.

Key concepts

Refer to the article on setting up a Jenkins Pipeline in Kubernetes, as the core concepts are the same. In the case of CloudBees Core on Kubernetes, much of the configuration is already done and the pipeline script is simpler because the JNLP Agent/Slave container is launched automatically. The only tricky bit of configuration is determining the group ID (gid) of the docker group on your Kubernetes hosts, and using it to add some YAML to the default JNLP Agent/Slave pod configuration in CloudBees core. This allows a pod running your pipeline to build and scan images using the mapped Docker socket of the underlying hosts.

Integrating Prisma Cloud

After installing the Prisma Cloud Jenkins plugin, configure the default pod template.
  1. Get the docker group ID (GID) used by the hosts in your Kubernetes cluster.
    1. SSH to a node in the cluster.
    2. Get the docker group GID. Copy it and set it aside for now.
      $ sudo grep docker /etc/group
  2. Log into the CloudBees Core console, and navigate to <CLOUDBEES_CONSOLE>/cjoc/view/All/.
  3. Click on
    kubernetes shared cloud
  4. In the left navigation bar, click on
  5. Scroll down to the
    Kubernetes pod template
    section. You’ll notice a pod template named default-java with a single container named jnlp.
  6. Scroll to the bottom of the section. In
    Raw yaml for the Pod
    , enter the following snippet, replacing <GID> with the docker GID for your environment.
    spec: securityContext: fsGroup: <GID>
  7. Grant all containers in the pod access to the underlying host’s Docker socket (unless you do this manually in the pipeline script).
    1. Scroll up to the
    2. Add a Host Path Volume to the pod template.
    3. In both
      Host path
      Mount path
      , enter
  8. Add a second container to the pod template.
    In addition to the JNLP agent/slave, you’ll also want to spin up a container with the docker binary inside of it. Use the official docker image from DockerHub and name it
    , although you could use any image with the docker client command installed in it. The docker client will use the Docker socket mounted from the underlying host.
    1. Scroll up the
      Container Template
    2. Click
      Add Container
    3. In
      , enter
    4. In
      Docker image
      , enter
    5. In
      Working directory
      , enter
    6. In
      Command to run
      , enter
      /bin/sh -c
    7. In
      Arguments to pass to the command
      , enter
    8. Enable
      Allocate pseudo-TTY
  9. Your CloudBees Core pod template config page should look like the folowing screenshot.

Pipeline template

The following template can be used as a starting point for your own scripted pipeline. This template illustrates how to build a new Docker image and then scan it with the Prisma Cloud scanner. Because the pod template includes a container named 'build' that has the docker client command, you can use it in step (1) to build an image.
{ node { stage ('Build image') { // See 1 container('build') { sh """ mkdir myproj cd myproj echo 'FROM alpine:latest' > Dockerfile docker build -t myalpine:latest . """ } } stage ('Prisma Cloud scan') { // See 2 twistlockScan ca: '', cert: '', compliancePolicy: 'critical', dockerAddress: 'unix:///var/run/docker.sock', gracePeriodDays: 0, ignoreImageBuildTime: true, image: 'myalpine:latest', key: '', logLevel: 'true', policy: 'warn', requirePackageUpdate: false, timeout: 10 } stage ('Prisma Cloud publish') { See 3 twistlockPublish ca: '', cert: '', dockerAddress: 'unix:///var/run/docker.sock', ignoreImageBuildTime: true, image: 'myalpine:latest', key: '', logLevel: 'true', timeout: 10 } } }
This template has the following characteristics:
  • 1
     — The first stage of the pipeline builds a new container image from a one-line Dockerfile inside the 'build' container specified in the pod config. Note that the twistlockScan and twistlockPublish functions cannot be run inside the container('<NAME>') block . They must be run in the default context.
  • 2
     — The second stage runs the Prisma Cloud scanner on our newly built image in the default JNLP Agent/Slave container named 'jnlp'.
  • 3
     — The third stage publishes the scan results to the Prisma Cloud Console.

Recommended For You