Getting Started: Stub and Harden a Docker Image with Bitbucket
Use the RapidFort Command Line Interface (CLI) tools to stub and harden a Docker image with Bitbucket

Prerequisites

You will need the following:
  • RapidFort Server (SaaS or On-Premises)
  • RapidFort Service Account
  • Deployment Environment (for example, Kubernetes, Docker, Docker-Compose, AWS Fargate)
    • The deployment environment must have HTTPS access to the RapidFort server
    • The deployment environment must provide support for adding the SYS_PTRACE Linux kernel capability
  • Container Registry (for example, Amazon Elastic Container Registry, Docker Hub, Microsoft Azure Container Registry, and so forth)
    • In this tutorial, we will use Docker Hub as our container registry
    • You will need a Docker Hub repository, username, and password or access token
You must deploy and test stub images outside of Bitbucket. Currently, Bitbucket does not support adding the SYS_PTRACE Linux kernel capability, even for self-hosted runners.
The SYS_PTRACE Linux kernel capability must be added when deploying stub images so that RapidFort can trace the runtime behavior.

Stub, Deploy and Test, and Harden a Docker Image

In this tutorial, we will stub, deploy and test, and harden a Docker image.
Original Image: The original Docker image available directly from Docker Hub. The original image has not yet been optimized and secured by RapidFort and may have known vulnerabilities.
Stub Image: The original image with additional dependencies necessary for RapidFort to trace the runtime behavior.
Hardened Image: The optimized and secured image generated by RapidFort.
Download the sample .bitbucket-pipelines.yml file.
Add the following Repository Variables:
  • RF_ROOT_URL:
    • For SaaS users, specify https://frontrow.rapidfort.com.
    • For On-Premises users, specify the hostname or IP address of your RapidFort on-premises server (for example, https://rapidfort.example.com).
  • RF_ACCESS_ID: Specify the access id for your RapidFort service account.
  • RF_SECRET_ACCESS_KEY: Specify the secret access key for your RapidFort service account.
  • RF_CLI_UPDATE: Specify "no" to download and install the RapidFort CLI tools only if they are not already installed on the runner or "yes" to always download and install the tools (even if they are already installed).
.bitbucket-pipelines.yml
1
image: python:latest
2
3
pipelines:
4
default:
5
- step:
6
runs-on:
7
- self.hosted
8
- linux
9
name: 'Stub'
10
services:
11
- docker
12
script:
13
- >-
14
if [ -z "$(command -v rflogin)" ] || [ "$RF_CLI_UPDATE" == "yes" ]; then
15
curl -ks "$RF_ROOT_URL"/cli/ | bash
16
fi
17
- echo $DOCKERHUB_TOKEN | docker login -u $DOCKERHUB_USERNAME --password-stdin
18
- docker pull $DOCKER_IMAGE_NAME:$TAG
19
- docker tag $DOCKER_IMAGE_NAME:$TAG $DOCKERHUB_USERNAME/$DOCKER_IMAGE_NAME:$TAG-$BITBUCKET_BUILD_NUMBER
20
- rfstub $DOCKERHUB_USERNAME/$DOCKER_IMAGE_NAME:$TAG-$BITBUCKET_BUILD_NUMBER
21
- docker push $DOCKERHUB_USERNAME/$DOCKER_IMAGE_NAME:$TAG-$BITBUCKET_BUILD_NUMBER-rfstub
22
23
- step:
24
trigger: manual
25
runs-on:
26
- self.hosted
27
- linux
28
name: 'Harden'
29
services:
30
- docker
31
script:
32
- >-
33
if [ -z "$(command -v rflogin)" ] || [ "$RF_CLI_UPDATE" == "yes" ]; then
34
curl -ks "$RF_ROOT_URL"/cli/ | bash
35
fi
36
- echo $DOCKERHUB_TOKEN | docker login -u $DOCKERHUB_USERNAME --password-stdin
37
- docker pull $DOCKERHUB_USERNAME/$DOCKER_IMAGE_NAME:$TAG-$BITBUCKET_BUILD_NUMBER-rfstub
38
- rfharden $DOCKERHUB_USERNAME/$DOCKER_IMAGE_NAME:$TAG-$BITBUCKET_BUILD_NUMBER-rfstub
39
- docker push $DOCKERHUB_USERNAME/$DOCKER_IMAGE_NAME:$TAG-$BITBUCKET_BUILD_NUMBER-rfhardened
Copied!
The base image must have Python 3 and pip3 installed.

Stub

During the build process, run rfstub to generate a stub image and push the stub image to your container registry.
In the sample Bitbucket pipeline template, the Stub step consists of the following actions:
  • Pull the original image from the container registry
  • Run rfstub to generate the stub image
  • Push the stub image to the container registry
When you generate a stub image, RapidFort also scans the original image for packages and known vulnerabilities and computes the estimated risk reduction opportunity if the image is hardened. You may optionally visit the RapidFort dashboard to view the vulnerabilities and packages that were found in the original image.

Deploy and Test

Next, deploy and test the stub image so that RapidFort can trace the runtime behavior of the application and build the runtime profile.
Note that the sample Bitbucket pipeline template does not have a Deploy step.
You must deploy and test stub images outside of Bitbucket. Currently, Bitbucket does not support adding the SYS_PTRACE Linux kernel capability, even for self-hosted runners.
The SYS_PTRACE Linux kernel capability must be added when deploying stub images so that RapidFort can trace the runtime behavior.

Update the Deployment Configuration and Environment

  • Deploy the stub image (instead of the original image)
  • Add the SYS_PTRACE Linux kernel capability
  • For Kubernetes environments, allow privilege escalation and enable read/write access for the root filesystem
    • allowPrivilegeEscalation: true
    • readOnlyRootFilesystem: false
Make sure that your deployment environment allows HTTPS access to the RapidFort server.
Deploy your stub image and test your application to exercise its functionalities.

Verify that Tracing Information is Propagated to the RapidFort Server

Log into the RapidFort dashboard. You should see an image list.
Select the image that you deployed.
In the left column, select Logs. Verify that the Logs table contains tracing information. You should see file accesses, system calls, and so forth. The Logs table contents are updated in real time.
If the Logs table is empty, please verify the following:
  • The stub image (not the original image) was deployed
  • The deployment configuration added the SYS_PTRACE Linux kernel capability
    • For Kubernetes environments, the deployment configuration allows privilege escalation and enable read/write access for the root filesystem
      • allowPrivilegeEscalation: true
      • readOnlyRootFilesystem: false
  • The environment in which the stub image was deployed has HTTPS access to the RapidFort server
If there are any issues, please update your deployment configuration and environment and deploy the stub image again. RapidFort cannot harden an image unless it has a valid runtime profile.

Harden

After you have deployed and tested the stub image and verified that the runtime profile information was propagated to RapidFort, you are ready to harden it.
In the sample Bitbucket pipeline template, the Harden step consists of the following actions:
  • Pull the stub image from the container registry
  • Run rfharden to generate the hardened and optimized image
  • Push the hardened image to your container registry
Note that the Harden step has a manual trigger. You must deploy and test the stub image and verify that the runtime profile was generated successfully before hardening it.