Overview of the Hardening/Optimization Process
Optimizing/hardening your containers during development enables an effortless shift-left workflow. Profiling in Production allows edge cases to be accounted for, especially if the test cases used in the lower environment are not comprehensive. Irrespective of where the container is profiled, the process comprises the following 3 steps: Instrumenting (also referred to, in the docs, as generating a “Stub”) & Scanning the container, Profiling the container, and Optimizing/Hardening the container.
Profiling creates an accurate picture of the container components the application requires to function fully and how it interacts with other applications and services. RapidFort’s hardening toolset uses this information from profiling to remove unnecessary components and optimize/harden the container.
RapidFort Touchpoints
RapidFort run-time and build-time tools are applicable in various environments. The diagram below shows a sample set of environments where E0 is the developer machine, E1 is the development environment where build pipelines are accessed, E2 is the QA/Test/Staging environments, and E3 is the production environment:
Securing Container Images in Production
RapidFort run-time tools are used by security teams to automatically lock down unused components at run-time, in production, without incurring work on development teams. In this scenario, RapidFort runtime agent containers are deployed in lower environments to profile the workload behavior, namely in QA / Test and Staging Kubernetes clusters to generate a baseline profile. RapidFort automatically scans and profiles the runtime behavior of applications as they go through testing cycles.
Vulnerabilities are automatically prioritized based on whether they are in the execution path of the workloads, determined by the profiling information from the lower environment, significantly reducing the prioritization burden on security teams. In addition, reports are shared with developers indicating which packages and software components are unused and can be removed from the workload.
Optionally, an optimized, hardened version of the workload can also be automatically generated and pushed to the registry.
A “baseline profile” is created for each application in the lower environments, which defines the expected file and package usage behavior of the application. In production, RapidFort’s monitoring component is used by security teams to “lock down” the package usage behavior of the workloads using these baseline profiles. Access to unused software components in production generates an alert for security teams to act upon. Note that in this scenario, an alert is generated only in two cases:
- QA / Test coverage in lower environments did not exercise the full functionality of the workload. This information helps improve the testing of the applications.
- Workload is accessed abnormally, and investigation for possible intrusion is warranted.
Vulnerability and other critical information about the container are presented via the RapidFort Web dashboard, providing deep insights and tools to act upon them:
