Links

rfstub

Generate a stub image.
The stub image is your original image with additional dependencies necessary for RapidFort to trace the runtime behavior.
When generating a stub image, RapidFort will also scan your original image for packages and vulnerabilities and estimate the risk reduction opportunity if you harden the image.
Your client system will need sufficient free space to export the original image, download the stub image from the RapidFort server, and load the stub image. The stub image size may be larger than the original image size.
In general, make sure that your client system has at least (4 * image size) free space available when generating a stub image.
Stub images cannot be used as base images. If you need to make updates, please build a new original image with the updates and then generate a new stub image.

Basic Usage

To generate a stub image, run:
rfstub <registry>/<repository>:<tag>
For example:
rfstub example.registry.com/my-repository:v1.2.3

Command Line Parameters

Stub Image Tag

By default, rfstub generates a stub image with -rfstub appended to the original image tag.
For example, the following command will generate a stub image called registry.example.com/my-repository:v1.2.3-rfstub.
rfstub registry.example.com/my-repository:v1.2.3
You may specify a different tag for the stub image with -o <stub_image_tag>:
rfstub <registry>/<repository>:<tag> -o <stub_image_tag>
For example, the following command will generate a stub image called registry.example.com/my-repository:my-stub-tag:
rfstub registry.example.com/my-repository:v1.2.3 -o my-stub-tag
If a RapidFort image (stub image or hardened image) with the same name already exists on the client system, then rfstub will automatically rename the existing RapidFort image.
For example, if there is already a stub image on the client system named registry.example.com/my-repository:v1.2.3-rfstub and a new stub image is generated with the same tag, then:
  • The existing stub image will be renamed to registry.example.com/my-repository:v1.2.3-rfstub-<rapidfort_id>
    • For example: registry.example.com/my-repository:v1.2.3-rfstub-a0b1c2d3
  • The new stub image will be named registry.example.com/my-repository:v1.2.3-rfstub
If a non-RapidFort image (original image) with the same name already exists on the client system, then it will be untagged.
For example, if the original image is named registry.example.com/my-repository:v1.2.3 and a stub image is generated with the same tag (-o v1.2.3), then the original image will be untagged and the stub image will be named registry.example.com/my-repository:v1.2.3.

Workload Tags

Workload tags enable reusing and combining hardening profiles.
Specify a workload tag name (maximum 128 characters) with -t <workload_tag>:
rfstub nginx:latest -t "my-workload-tag"
You may optionally specify a workload tag description (maximum 512 characters) with -d <workload_tag_description>:
rfstub nginx:latest -t "my-workload-tag" -d "My workload tag description"
For more information on workload tags, please visit Workload Tags.

Credentials File

By default, rfstub expects the RapidFort credentials file to be located in ~/.rapidfort/credentials. To override this, specify -c <rapidfort_credentials_file>:
rfstub <image> -c /path/to/rapidfort/credentials

Next Steps

Deploy and test your stub image. Add the SYS_PTRACE Linux kernel capability when running your stub image so that RapidFort can trace the runtime behavior.
Note that if you have already generated a hardening profile, then you can harden the stub image using workload tags or RapidFort GUIDs.
To view and download reports, visit the RapidFort dashboard or run:
rfinfo -s <rapidfort_guid>

More Information