In this blog post we are going to cover how to perform Docker image scanning on Atlassian’s Bamboo CI/CD platform using the new Inline Scanning Image with Sysdig Secure. Container images with security vulnerabilities, or those non-compliant with the security policies that you define within Sysdig Secure, will be stopped, breaking the build pipeline before being pushed to your Docker registry.
What is the Atlassian Bamboo CI/CD platform?
Atlassian Bamboo is a continuous integration and delivery server integrated with Atlassian software development and collaboration platform. Some of the features that distinguish Bamboo from similar CI/CD tools are its native integration with other Atlassian products (like Jira project management and issue tracker), improved support for Git workflows (branching and merging), and flexible scalability of worker nodes using ephemeral Amazon EC2 virtual machines. Inline image scanning builds #container #security into your #CICD pipeline while keeping images private. Learn how, with Sysdig secure and @Atlassian Bamboo. Click to tweet
Bamboo organizes the build pipeline with a hierarchy of Projects, Plans, Stages, Jobs and Tasks.
A project is a “namespace” containing different plans. The plan is composed of multiple stages that will be executed sequentially. Each stage is in turn composed of several jobs that can run in parallel; these jobs are the basic unit of work scheduled in the worker nodes. Finally, each job is composed of a series of tasks that will be executed sequentially in the scheduled worker node.
To summarize:
- The plan is the high level sequence of actions (stages) that you want to execute.
- The job is the basic schedulable unit of work that gets assigned to a worker. N jobs get executed in N workers and thus, can be parallelized.
- A job itself is a sequence of tasks, like executing a script or running a Docker container.
Container security in your CI/CD pipeline: shift left your security and fail fast
Like most things in IT, the earlier you detect container security issues, the easier they are to fix without further consequences.
Embedding container security in your build pipeline is a best practice for several reasons:
- The vulnerabilities will never reach your production clusters, or even worse, a client environment.
- You can adopt a secure-by-default approach when you know any image available in your Docker container registry has already passed all the security policies you have defined for your organization, as opposed to manually checking container and Kubernetes compliance after-the-fact.
- The original container builder will be (almost) instantly informed, when the developer still has all the context. The issue will be substantially easier to fix this way than if found by any other person months later…
Sysdig Secure offers a full featured container image scanning service, among many other container security features like run-time threat detection, forensics, compliance and auditing. Let’s see how we can make Sysdig Secure image scanning in Kubernetes work together with Atlassian Bamboo.
Bamboo CI/CD pipeline image scanning with Sysdig Secure
Following a practical example, we are going to demonstrate how to integrate these two platforms with a very straightforward process.
But first, why inline scanning? Because the full analysis will be done in the pipeline itself, no information of the contents inside the image nor the image itself will be sent outside. This will guarantee the privacy of the contents and speed-up the scanning process since it can be done in parallel.
Ok, let’s start; first, we will create a new Project containing a Plan, which essentially means naming them, writing the corresponding description, configuring access credentials for users, etc:
Next, we will create an environment for the plan.
First, we need to configure the repository that is going to contain the Dockerfile
together with other build variables and artifacts:
You might configure other environment variables you need from the Variables tab.
From the Global Bamboo settings (top-right gear icon, linked repositories), you can configure any credentials you require to access your source repository, like GitHub and your container image registry, DockerHub, for example.
Next, we will configure this plan to trigger automatically whenever there is a change in the repository:
Configuring the CI/CD pipeline
We are now ready to create a Stage containing the different tasks:
- Source code checkout: Cloning the supporting repository that contains the Dockerfile and other build variables.
- Build Image: We will select Build a Docker image in Command, and we will configure a staging image registry where we can upload the image.
- Pull Image Scan: We will pull the latest version of the
secure-inline-scan
image that will do the scan for us.
- Scan Image: Before we even push the image into the registry, we have to make sure the image won’t compromise the security of our infrastructure.
We will use the previous downloaded image to scan the one we built with the following command:
/bin/inline_scan analyze -k ${bamboo.SYSDIG_SECURE_TOKEN_SECRET} -s ${bamboo.SYSDIG_SECURE_WEBHOOK} sysdiglabs/dummy-vuln-app:latest
Since this image will need to have access to the built image, we will need to give it access to the Docker socket:
Notice that the image won’t be sent to Sysdig Secure, just the report for further analysis. This will ensure the privacy of the contents in your image and Sysdig Secure won’t act as a bottleneck if you scan many images.
If the scanning finds any vulnerabilities in the image (including custom policies that you may have defined, like specific checks on the Dockerfile, for example not running the process as root, or whitelist/blacklist certains packages or libraries like not installing SSH), the entire plan will fail and the last step will never get executed.
- Push image: This is the final step of the pipeline, pushing the image to the registry if everything was correct.
Uh-oh! It seems that Sysdig Secure container image scanner found something wrong:
Within Sysdig Secure you can see the full report, including the policy evaluation and why it failed:
It seems that our image is exposing port 22. It also contains vulnerabilities in the operating system and the python libraries we are using:
We can select Operating System and see the vulnerabilities that affect the base image:
Or select Non-operating System and see the ones that affect the libraries we are using:
Now we know what happened, why the pipeline failed, and how to fix it.
Conclusions
Integrating your security policy early in your CI/CD pipeline will prevent known software vulnerabilities to be deployed in our image registries, or even in production, and you will enforce best security practices within your build pipeline before those containers are ever run.
Thanks to the native Docker compatibility in Atlassian Bamboo and the Sysdig Secure container image scanning API, making them work together is a breeze. Find any software vulnerabilities, check for container security best practices and Dockerfile contents, whitelist or blacklist specific packages or 3rd party libraries installed manually (like Java JAR/WAR files, or package managers like npm, pip or gem) with Sysdig Secure. Fail fast, inform the container author right away to address it quickly, and create a secure-by-default container security policy.