1.6. Securing container content
To ensure the security of the content inside your containers you need to start with trusted base images, such as Red Hat Universal Base Images, and add trusted software. To check the ongoing security of your container images, there are both Red Hat and third-party tools for scanning images.
1.6.1. Securing 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, what versions are used, 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 operating system layers current?
By building your containers from Red Hat Universal Base Images (UBI) you are assured of a foundation for your container images that consists of the same RPM-packaged software that is included in Red Hat Enterprise Linux. No subscriptions are required to either use or redistribute UBI images.
To assure ongoing security of the containers themselves, security scanning features, used directly from RHEL or added to OpenShift Container Platform, can alert you when an image you are using has vulnerabilities. OpenSCAP image scanning is available in RHEL and the Container Security Operator can be added to check container images used in OpenShift Container Platform.
1.6.2. Creating redistributable images with UBI
To create containerized applications, you typically start with a trusted base image that offers the components that are usually provided by the operating system. These include the libraries, utilities, and other features the application expects to see in the operating system’s file system.
Red Hat Universal Base Images (UBI) were created to encourage anyone building their own containers to start with one that is made entirely from Red Hat Enterprise Linux rpm packages and other content. These UBI images are updated regularly to keep up with security patches and free to use and redistribute with container images built to include your own software.
Search the Red Hat Ecosystem Catalog to both find and check the health of different UBI images. As someone creating secure container images, you might be interested in these two general types of UBI images:
-
UBI: There are standard UBI images for RHEL 7 and 8 (
ubi7/ubi
andubi8/ubi
), as well as minimal images based on those systems (ubi7/ubi-minimal
andubi8/ubi-mimimal
). All of these images are preconfigured to point to free repositories of RHEL software that you can add to the container images you build, using standardyum
anddnf
commands. Red Hat encourages people to use these images on other distributions, such as Fedora and Ubuntu. -
Red Hat Software Collections: Search the Red Hat Ecosystem Catalog for
rhscl/
to find images created to use as base images for specific types of applications. For example, there are Apache httpd (rhscl/httpd-*
), Python (rhscl/python-*
), Ruby (rhscl/ruby-*
), Node.js (rhscl/nodejs-*
) and Perl (rhscl/perl-*
) rhscl images.
Keep in mind that while UBI images are freely available and redistributable, Red Hat support for these images is only available through Red Hat product subscriptions.
See Using Red Hat Universal Base Images in the Red Hat Enterprise Linux documentation for information on how to use and build on standard, minimal and init UBI images.
1.6.3. Security scanning in RHEL
For Red Hat Enterprise Linux (RHEL) systems, OpenSCAP scanning is available from the openscap-utils
package. In RHEL, you can use the openscap-podman
command to scan images for vulnerabilities. See Scanning containers and container images for vulnerabilities in the Red Hat Enterprise Linux documentation.
OpenShift Container Platform enables you to leverage RHEL 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.
1.6.3.1. Scanning OpenShift images
For the container images that are running in OpenShift Container Platform and are pulled from Red Hat Quay registries, you can use an Operator to list the vulnerabilities of those images. The Container Security Operator can be added to OpenShift Container Platform to provide vulnerability reporting for images added to selected namespaces.
Container image scanning for Red Hat Quay is performed by the Clair security scanner. In Red Hat Quay, Clair can search for and report vulnerabilities in images built from RHEL, CentOS, Oracle, Alpine, Debian, and Ubuntu operating system software.
1.6.4. Integrating external scanning
OpenShift Container Platform makes use of object annotations to extend functionality. External tools, such as vulnerability scanners, can annotate image objects with metadata to summarize results and control pod execution. This section describes the recognized format of this annotation so it can be reliably used in consoles to display useful data to users.
1.6.4.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 |
|
1.6.4.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 or more details. Required so user may validate the data. | String |
| No | Scanner version | String |
| No | Compliance pass or 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 (for example, "critical," "important," "moderate," "low," or "health") | String |
| Data for this component (for example, 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 or more details. Optional. | String |
1.6.4.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 the Container images section of the Red Hat Ecosystem Catalog annotation for an image with health index data with an external URL for additional details:
Red Hat Ecosystem Catalog annotation
{ "name": "Red Hat Ecosystem 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 } ] }
1.6.4.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.
1.6.4.2.1. Example annotate CLI command
Replace <image>
with an image digest, for example sha256:401e359e0f45bfdcf004e258b72e253fd07fba8cc5c6f2ed4f4608fb119ecc2
:
$ oc annotate image <image> \ quality.images.openshift.io/vulnerability.redhatcatalog='{ \ "name": "Red Hat Ecosystem Catalog", \ "description": "Container health index", \ "timestamp": "2020-06-01T05:04:46Z", \ "compliant": null, \ "scannerVersion": "1.2", \ "reference": "https://access.redhat.com/errata/RHBA-2020:2347", \ "summary": "[ \ { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'
1.6.4.3. Controlling pod execution
Use the images.openshift.io/deny-execution
image policy to programmatically control if an image can be run.
1.6.4.3.1. Example annotation
annotations: images.openshift.io/deny-execution: true
1.6.4.4. Integration reference
In most cases, external tools such as vulnerability scanners develop a script or plug-in that watches for image updates, performs scanning, and annotates the associated image object with the results. Typically this automation calls the OpenShift Container Platform 4.5 REST APIs to write the annotation. See OpenShift Container Platform REST APIs for general information on the REST APIs.
1.6.4.4.1. Example REST API call
The following example call using curl
overrides 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> }'
The following is an example of PATCH
payload data:
Patch call data
{ "metadata": { "annotations": { "quality.images.openshift.io/vulnerability.redhatcatalog": "{ 'name': 'Red Hat Ecosystem Catalog', 'description': 'Container health index', 'timestamp': '2020-06-01T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2020:2347', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }" } } }
Additional resources