Editors note: This blog was contributed by guest writers from Twistlock : Jeremy Adams , Principal Solutions Architect, Partners and James Jones , Principal Solutions Architect
A major part of modern DevSecOps is ensuring that you are tracking and mitigating security issues throughout the full lifecycle of application development. As such, integrating Twistlock into your CI pipeline can ensure you prevent vulnerable container images from even making it into your registries when they violate vulnerability and compliance thresholds.
Keeping this vulnerability and compliance information front and center where your development teams are tracking their image builds helps ensure a tight feedback loop so security issues can be quickly mitigated. Your developers have a deep understanding of their application code and its required dependencies. Now integrating security into that process allows them to keep security top of mind as they continue planning out their future updates.
CloudBees Core and K8s
CloudBees Core ™ is the successor to CloudBees Jenkins Platform™ and CloudBees Jenkins Enterprise™. CloudBees Core works by having a controller node and several worker nodes that handle running jobs. In a Kubernetes cluster this can all be done by scheduling Kubernetes pods on demand by specifying pod templates. These pod templates use JNLP to help facilitate the connection between the controller and the worker nodes and can have other containers launched within the same pod that can allow you to carry out other functions required for your pipeline to carry out its tasks. In this case, those tasks will include building, tagging, scanning, and pushing Docker images.
Configuring CloudBees Core and Twistlock to scan images
There are two steps that are typically done to set up Jenkins Integration. Some of this would have been seen in our previous blog post on our Jenkins plugin . In the case of CloudBees Core on Kubernetes, much of the configuration is already done and as such the pipeline script is simpler because the JNLP Agent/agent container will be launched automatically. We can ensure we define the remaining parts of a pod template that we need such as Docker for building and scanning our containers and can proceed from there.
Defining the pod template
In to the CloudBees Core console, we navigate to <cloudbees console name>/cjoc/view/All/ and click on 'kubernetes shared cloud'.
Afterwards we click on 'Configure' on the left navigation and scroll down to the default Kubernetes pod template: default-java. You’ll notice the default Container Template for 'jnlp.' The Scroll to the bottom and in the box labeled 'Raw yaml for the Pod' paste in the contents of the example below with your own docker group gid in place of the 412 in the example. The process will vary from platform to platform, but after connecting to the underlying host over SSH you can determine the GID from /etc/group.
Substitute your hosts' docker group gid for 412 below:
The second part of the pod template will be a docker container containing docker (DIND) to be able to run our docker build commands to build the actual container. This can also be defined in your Jenkinsfile, but for ease of setup, we will define the template in the GUI:
In addition to the Docker container specified in this image, I also make sure to mount a host path volume for docker with the path /var/run/docker.sock being available to both containers. This ensures we have access to Docker for our Twistlock container scans.
See it in action
Now that everything is configured, let’s navigate back to the main page. We can click on create new jobs to be able to start our new docker image build pipeline. We’ll give our new pipeline a name, select pipeline as the job type, and click OK.
Pipeline script example
At the bottom of the next page, you should see an area where you can paste in a pipeline script. The following template can be used as a starting point for your own scripted pipeline. This template illustrates how you can build a new Docker image and then scan it with Twistlock. Because we included a container image named 'build' with the docker command in the pod template, we can use it in stage (1) below to build our image.
Click on OK, then click on the button for build now. New pods should now be scheduled by CloudBees Core on your Kubernetes cluster and your job should soon start showing output on console output. Some example output is below (abridged):
Scan results are also shown within Twistlock Console. In the gif below, Twistlock surfaces the latest build with Vulnerabilities, Risk Factors, and Pass/Fail Status. Clicking on the build will allow you to dive deeper into each vulnerability, including remediation guidance.
Conclusion
We hope this demo helps guide you through setting up CloudBees Core to integrate with Twistlock to provide in-depth scans for all of your Docker images. Twistlock is proud to be an official partner with CloudBees to improve your ability to find and fix flaws as part of the SDLC.
To learn more about how you can work to operationalize DevSecOps, check out this infographic .
Check out the upcoming CloudBees and Twistlock events .
Additional resources
Take the steps needed for DevSecOps success
Learn six concepts for DevSecOps implementation
Watch a webinar on creating a DevSecOps playbook