Once the instrumenter service is up and running in your environment, you can instrument your images.
Note that only images that have been scanned by a registry scan job (registry sensor) will have the Instrument option.
To find the images you can instrument, go to Assets > Images and perform a search for images with REGISTRY as source.
Search query:
source: REGISTRY
You can add additional search fields to help narrow down the list further. Then, in the search results, identify the image you want to instrument and pick Instrument from the Quick Actions menu.
On the Instrument Image page, choose the source registry. You’ll notice that the destination registry has the same value as the source registry. Click the Instrument button.
The instrumenter service will pull the image down, add in our solution and push the image back to the destination registry.
Take note of the destination tag(s) assigned to the instrumented image. We take the source tag and append -layered to create the destination tag. For example, in the example above, you’ll see that the source tag is java01 and the destination tag is java01-layered. You’ll be able to search for instrumented images by the destination tag.
Before you spawn up containers from an instrumented image, make sure you've completed these steps:
Apply policy to instrumented image
Configure instrumentation to select log mode
When ready, you can spawn a container from the instrumented image using the following command:
docker run -itd -e LI_MQURL=https://<cmsqagpublic VIP>/crs/v1.2 -e LI_MQSKIPVERIFYTLS=true <your registry/repo:tag>
The policy applied to the instrumented image gets enforced on the container and activities are logged as per the selected log mode.
Go to Assets > Containers and perform a search using the following query.
Search query:
isInstrumented:true
Then choose View Details from the Quick Actions menu for any container listed as a result of your search.
The Runtime Profile tab shows the resources that are tracked to gather trace information. It shows the files that are being read on the container, programs being run, ports accessed, and IP address information.
The Events tab shows runtime events, and whether the access was allowed, denied or monitored depending on the applied policy. Use the filter option to view standard logs or behavior logs. Standard logs show policy hits. Behavior logs show system calls. The system call number is shown in the CALL column.
Tip - Use the details you find here to create new runtime policies using the API.
