Workload Tags
In general, hardening a workload requires deploying and testing the stubbed workload at least once so that RapidFort can trace the runtime behavior and generate an accurate profile.
In some situations, running comprehensive tests to exercise all workload functionalities may not be feasible or necessary.
For example, suppose that after generating a stub image and running your comprehensive test suite, you discover that a configuration file needs to be updated or a small bug fix needs to be included prior to release. Therefore, you build a new image and generate a new stub image.
With workload tags, you do not need to rerun your comprehensive test suite on the new stub image before hardening it. Instead, you can run sanity tests on the new stub image to validate the updates and then harden it using the workload tag from the previous stub image that was fully tested.
Similarly, if your workload composition (packages and files) does not change significantly from build to build, you can create a workload tag and harden stub images for subsequent builds using the workload tag. When there are impactful changes, deploy and test the stub image to ensure that the new functionality is exercised and new dependencies are added to the runtime profile before you harden it.
Workload tags can be used to harden images using results from multiple independent test runs. Instead of having to change your software testing process to run all test suites on the same stub image, you can do the following:
- 1.For each test phase, generate a stub image with a workload tag (for example,
unit_test,qa_test,coverage_test). You can also generate stub images that share the same workload tag (for example,build_12345). - 2.Test each stub image independently
- 3.Generate and harden another stub image using the workload tags
Install the RapidFort CLI tools and dependencies (including Docker, Python, and pip).
Pull the
redis:6.2.5 Docker image from Docker Hub:docker pull docker.io/redis:6.2.5
Generate a stub image with a workload tag called
redis:rfstub docker.io/redis:6.2.5 -t redis
Deploy and test your stub image so that RapidFort can trace the runtime behavior and build the runtime profile.
For the purposes of this tutorial, you can simply start a new stub container (remember to add the
SYS_PTRACE capability) and then stop the container:docker run --rm -it --cap-add=SYS_PTRACE -p9999:6379 --name redis-test docker.io/redis:6.2.5-rfstub
docker stop redis-test -t 10
Harden the stub image:
rfharden docker.io/redis:6.2.5-rfstub
Since RapidFort has a runtime profile for this image, hardening the image succeeded.
Pull the
redis:6.2.6 Docker image from Docker Hub:docker pull docker.io/redis:6.2.6
Generate a new stub image:
rfstub docker.io/redis:6.2.6 -t redis
Try to harden the new stub image:
$ rfharden docker.io/redis:6.2.6-rfstub
Hardening docker.io/redis:6.2.6-rfstub
Harden image: docker.io/redis:6.2.6-rfstub
General Error: Error: No stub instances have run yet...
This error is expected since you have not yet deployed and tested the stub image, so no runtime profile is available. Without a runtime profile, RapidFort cannot generate a hardened image.
Now harden the new stub image using workload tag
redis:rfharden docker.io/redis:6.2.6-rfstub -t redis
This time, your new stub image should be successfully hardened. The runtime profile from the
redis:6.2.5 image was added when hardening with a workload tag. Since at least one runtime profile was available, hardening succeeded.Hardening docker.io/redis:6.2.6-rfstub
Adding profile of image "docker.io/redis:6.2.5"
Note that no testing was required to harden the new stub image. Instead, the image was hardened using the runtime profile information that is associated with the
redis workload tag.In this tutorial, we will generate multiple stub images with workload tags, test each stub image independently, and then generate and harden another stub image using the workload tags.
Install the RapidFort CLI tools and dependencies (including Docker, Python, and pip).
Pull the NGINX Docker image:
docker pull nginx:latest
Generate a stub image with a workload tag called
unit_test:rfstub nginx:latest -t unit_test
Test your stub image. For the purposes of this tutorial, you can simply start a new container and then stop the container:
docker run --rm -it --cap-add=SYS_PTRACE -p9999:80 nginx:latest-rfstub
Generate another stub image with a workload tag called
coverage_test:rfstub nginx:latest -t coverage_test
If a stub image with the same name and tag already exists, RapidFort will automatically generate a new tag for the previous stub image and retag it.
Test your stub image. For the purposes of this tutorial, you can simply start a new container and then stop the container:
docker run --rm -it --cap-add=SYS_PTRACE -p9999:80 nginx:latest-rfstub
Generate another stub image, this time without specifying a workload tag:
rfstub nginx:latest
Harden the new stub image using the
unit_test and coverage_test workload tags:rfharden nginx:latest-rfstub -t unit_test -t coverage_test
Note that no testing was required to harden the new stub image. Instead, the image was hardened using the profiles from
unit_test and coverage_test.In this tutorial, we generated 2 stub images with workload tags, tested the stub images independently, and then generated and hardened another stub image using the workload tags.
Workload tags are specified when generating stub images. However, if you did not specify a workload tag when generating a stub image or if you would like to use the profile from a specific stub image, you can harden an image using one or more RapidFort GUIDs.
rfharden <stub_image> -t <rapidfort_guid0> -t <rapidfort_guid1> ...
You can harden an image using any combination of workload tags and RapidFort GUIDs.
rfharden <stub_image> -t <workload_tag0> -t <rapidfort_guid0> -t <workload_tag1> ...
Multiple stub images can share the same workload tag. If you would like to harden an image using a workload tag but would also like to exclude the profile information for one or more RapidFort GUIDs that are associated with the workload tag, you can do so by specifying
-x <rapidfort_guid_to_exclude>.rfharden <stub_image> -t <workload_tag> -x <rapidfort_guid_to_exclude>