Container Runtime Security (CRS) is a separately licensed feature in the Container Security (CS) module. It provides runtime behavior visibility & enforcement capabilities for running containers. This allows customers to address various use cases for running containers around security best practice enforcement, file access monitoring, network access control.
CRS requires instrumentation of container images with the Qualys Container Runtime Instrumentation, which injects probes into the container image. Customers can configure instrumented images, containers with granular policies which govern container behavior, visibility. Based on these runtime enforcement policies - runtime events, telemetry can be viewed obtained from the backend via UI, API.
CRS is not activated by default for existing or new customers. Currently CRS is supported only for Linux OS based containers only. If you are interested in this feature, please contact your Qualys Account Manager or Qualys Support.
Refer to the Container Runtime Security User Guide for more information.
CRS is a separately licensed feature of Container Security and must be enabled.
Customers need to have at least one host/sensor license for Container Security Scanning capabilities. In addition to this, customers need to be licensed for an appropriate number of containers for CRS. CRS relies on instrumenting a container image with Qualys instrumentation. This allows for in-container behavior visibility and enforcement.
Protecting containers with Qualys CRS requires instrumentation of a container image with the Qualys Instrumentation. You have 2 options for instrumenting container images - instrument images on your local host using CLI mode, or run our Instrumenter service in the backend to instrument images that have been scanned by a registry scan job.
This approach is used for instrumenting individual images on your local host. You’ll run the instrumenter.sh script with CLI mode enabled (CLI mode is enabled by default) and identify the image to instrument. The image must be present locally where you’re running the CLI command. You can optionally specify the runtime policy to apply to the instrumented image. When you instrument an image using this method, we’ll immediately add in our solution and create the instrumented image (appended with -layered) at the same location. One command will instrument one image only, and then it will exit as soon as instrumentation is done.
This approach is used for instrumenting images that have been scanned by a registry scan job (registry sensor). The Instrumenter service is a lightweight microservice that runs in the customer premise. The Instrumenter service is packaged and distributed to customers as a container image. This instrumenter container is meant to be run on a container host. It requires connectivity back to the Qualys backend. The backend federates instrumentation requests to this microservice. Once an image is submitted for instrumentation (via UI, API), the instrumenter inspects the image, injects the Qualys instrumentation, and provides as output a new “instrumented” version of the image. This new image is then uploaded back to the destination container registry with “-layered” appended to the tag. This workflow is coupled tightly with a registry.
Here’s a look at the deployment workflow for Container Runtime Security.
You have 2 options for instrumenting images - you can instrument any image on your local host using CLI mode (see 1a), or you can run our Instrumenter service in the backend to instrument images that have been scanned by a registry scan job (see 1b). Choose the approach you want to take and follow the steps.
Instrument an image on your local host. We’ll immediately add in our runtime security solution and create the instrumented image (appended with -layered) at the same location. One command will instrument one image only, and then it will exit as soon as the instrumentation is done. Tip - If you have a runtime policy ready to go, you can immediately apply the policy to the instrumented image when running the CLI command.
Instrument images using CLI mode
To use the Instrumenter microservice, you’ll need to complete the following steps:
Build image, Push image to registry, and Scan with registry sensor
You’ll build the image and push it to the registry. Then scan each image you want to instrument with the registry sensor. This is required for using the Instrumenter service.
Deploy the Instrumenter service in your environment
The Instrumenter service will be used to pull down the unprotected image, package our solution into it, and then push it back to the registry as a protected image.
Deploy the Instrumenter Service
Instrument container image from the UI
When using the Instrumenter service, you’ll kick off instrumentation from the UI. Identify the image you want to instrument on the Images list, and choose the Instrument option. The UI sends an instrumentation job to the deployed Instrumenter. We’ll package in our solution, and push the protected image back to the registry. Once you have the protected image, you can run the image in your runtime environment as a running container.
Instrument images from the UI
Create policies, and assign a policy to an instrumented image. You’ll also want to set the policy enforcement level (determines whether policy rules are enforced) and select the log mode (determines which policy hits get logged).
Set policy enforcement
Apply policy to instrumented image
Configure instrumentation to select the log mode
When ready, you can spawn containers from the instrumented image. The policy applied to the instrumented image gets enforced on the container and activities are logged as per the selected log mode.
Run container from instrumented image
Runtime events will be listed on the Events tab. Here you can search events and drill-down into event details.
View your events
View event details on dashboard