Chapter 3. Container Content
3.1. Security Inside the Container
Applications and infrastructures are composed of readily available components, many of which are open source packages such as, the Linux operating system, JBoss Web Server, PostgreSQL, and Node.js.
Containerized versions of these packages are also available, However, you need to know where the packages originally came from, who built them, and whether there is any malicious code inside them.
Some questions to answer include:
- Will what is inside the containers compromise your infrastructure?
- Are there known vulnerabilities in the application layer?
- Are the runtime and OS layers current?
Further Reading
OpenShift Container Platform Using Images
- Reference documentation on framework, database, and service container images provided by Red Hat for use on OpenShift Container Platform
3.2. Container Content Scanning
Container scanning tools can leverage continuously updated vulnerability databases to ensure that you always have the latest information on known vulnerabilities for your container content. The list of known vulnerabilities constantly evolves; you must check the contents of your container images when you first download them and continue to track vulnerability status over time for all of your approved and deployed images.
RHEL provides a pluggable API to support multiple scanners. You can also use Red Hat CloudForms with OpenSCAP to scan container images for security issues. See the Red Hat Enterprise Linux Security Guide for general information on OpenSCAP in RHEL, and the Red Hat CloudForms Policies and Profiles Guide for specifics on OpenSCAP integration.
OpenShift Container Platform enables you to leverage such scanners with your CI/CD process. For example, you can integrate static code analysis tools that test for security flaws in your source code and software composition analysis tools that identify open source libraries in order to provide metadata on those libraries such as known vulnerabilities. This is covered in more detail in Build Process.
3.3. Integrating External Scanning Tools with OpenShift
OpenShift Container Platform makes use of object annotations to extend functionality. External tools, such as vulnerability scanners, may annotate image objects with metadata to summarize results and control pod execution. This section describes the recognized format of this annotation so it may be reliably used in consoles to display useful data to users.
3.3.1. Image Metadata
There are different types of image quality data, including package vulnerabilities and open source software (OSS) license compliance. Additionally, there may be more than one provider of this metadata. To that end, the following annotation format has been reserved:
quality.images.openshift.io/<qualityType>.<providerId>: {}| Component | Description | Acceptable Values |
|---|---|---|
|
| Metadata type |
|
|
| Provider ID string |
|
3.3.1.1. Example Annotation Keys
quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}The value of the image quality annotation is structured data that must adhere to the following format:
| Field | Required? | Description | Type |
|---|---|---|---|
|
| Yes | Provider display name | String |
|
| Yes | Scan timestamp | String |
|
| No | Short description | String |
|
| Yes | URL of information source and/or more details. Required so user may validate the data. | String |
|
| No | Scanner version | String |
|
| No | Compliance pass/fail | Boolean |
|
| No | Summary of issues found | List (see table below) |
The summary field must adhere to the following format:
| Field | Description | Type |
|---|---|---|
|
| Display label for component (e.g., "critical", "important", "moderate", "low" or "health") | String |
|
| Data for this component (e.g., count of vulnerabilities found or score) | String |
|
|
Component index allowing for ordering and assigning graphical representation. The value is range | Integer |
|
| URL of information source and/or more details. Optional. | String |
3.3.1.2. Example Annotation Values
This example shows an OpenSCAP annotation for an image with vulnerability summary data and a compliance boolean:
OpenSCAP Annotation
{
"name": "OpenSCAP",
"description": "OpenSCAP vulnerability score",
"timestamp": "2016-09-08T05:04:46Z",
"reference": "https://www.open-scap.org/930492",
"compliant": true,
"scannerVersion": "1.2",
"summary": [
{ "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
{ "label": "important", "data": "12", "severityIndex": 2, "reference": null },
{ "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
{ "label": "low", "data": "26", "severityIndex": 0, "reference": null }
]
}
This example shows a Red Hat Container Catalog annotation for an image with health index data with an external URL for additional details:
Red Hat Container Catalog Annotation
{
"name": "Red Hat Container Catalog",
"description": "Container health index",
"timestamp": "2016-09-08T05:04:46Z",
"reference": "https://access.redhat.com/errata/RHBA-2016:1566",
"compliant": null,
"scannerVersion": "1.2",
"summary": [
{ "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
]
}
3.3.2. Annotating Image Objects
While image stream objects are what an end-user of OpenShift Container Platform operates against, image objects are annotated with security metadata. Image objects are cluster-scoped, pointing to a single image that may be referenced by many image streams and tags.
3.3.2.1. Example Annotate CLI Command
Replace <image> with an image digest, for example sha256:fec8a395afe3e804b3db5cb277869142d2b5c561ebb517585566e160ff321988:
$ oc annotate image <image> \
quality.images.openshift.io/vulnerability.redhatcatalog='{ \
"name": "Red Hat Container Catalog", \
"description": "Container health index", \
"timestamp": "2016-09-08T05:04:46Z", \
"compliant": null, \
"scannerVersion": "1.2", \
"reference": "https://access.redhat.com/errata/RHBA-2016:1566", \
"summary": "[ \
{ "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'3.3.3. Controlling Pod Execution
To programmatically control if an image may be run, the images.openshift.io/deny-execution image policy may be used. See Image Policy for more information.
3.3.3.1. Example Annotation
annotations: images.openshift.io/deny-execution: true
3.3.4. Integration Reference
In most cases, external tools such as vulnerability scanners will develop a script or plug-in that watches for image updates, performs scanning and annotate the associated image object with the results. Typically this automation calls the OpenShift Container Platform REST API to write the annotation. See REST API Reference for general information on the REST API and PATCH call to update images.
3.3.4.1. Example REST API Call
This example call using curl will overwrite the value of the annotation. Be sure to replace the values for <token>, <openshift_server>, <image_id>, and <image_annotation>.
Patch API Call
$ curl -X PATCH \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/merge-patch+json" \
https://<openshift_server>:8443/oapi/v1/images/<image_id> \
--data '{ <image_annotation> }'
Below is example PATCH payload data.
Patch Call Data
{
"metadata": {
"annotations": {
"quality.images.openshift.io/vulnerability.redhatcatalog":
"{ 'name': 'Red Hat Container Catalog', 'description': 'Container health index', 'timestamp': '2016-09-08T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2016:1566', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
}
}
}
