Home
Products
Red Hat Quay
3.18
About Quay IO
Chapter 11. Clair security scanner

Chapter 11. Clair security scanner

Clair is a vulnerability scanner that analyzes container image layers and reports security issues from upstream CVE databases in Red Hat Quay. You can use these reports to identify vulnerabilities that affect image content.

Clair v4 (Clair) leverages static code analyses for parsing image content and reporting vulnerabilities affecting the content. Quay.io includes Clair, enables it automatically, and the Red Hat Quay development team manages it.

For Quay.io users, images are automatically indexed after they are pushed to your repository. Reports are then fetched from Clair, which matches images against its CVE database to report security information. This process happens automatically on Quay.io, and manual rescans are not required.

11.1. About Clair
Copy link

Clair scans container images for known vulnerabilities in Red Hat Quay. You can use National Vulnerability Database (NVD) enrichment, including CVSS severity scores, to prioritize remediation.

The NVD is a United States government repository of security-related information, including known vulnerabilities and security issues in various software components and systems. NVD scores provide the following benefits:

Data synchronization. Clair can periodically synchronize its vulnerability database with the NVD. This ensures that it has the latest vulnerability data.
Matching and enrichment. Clair compares the metadata and identifiers of vulnerabilities it discovers in container images with the data from the NVD. This process involves matching the unique identifiers, such as Common Vulnerabilities and Exposures (CVE) IDs, to the entries in the NVD. When a match is found, Clair can enrich its vulnerability information with additional details from NVD, such as severity scores, descriptions, and references.
Severity scores. The NVD assigns severity scores to vulnerabilities, such as the Common Vulnerability Scoring System (CVSS) score, to indicate the potential impact and risk associated with each vulnerability. By incorporating NVD severity scores, Clair can provide more context on the seriousness of the vulnerabilities it detects.

If Clair finds vulnerabilities from NVD, a detailed and standardized assessment of the severity and potential impact of vulnerabilities detected within container images is reported to users on the UI. CVSS enrichment data provides the following benefits:

Vulnerability prioritization. By using CVSS scores, you can prioritize vulnerabilities based on their severity and address the most critical issues first.
Assess risk. CVSS scores can help you understand the potential risk a vulnerability poses to your containerized applications.
Communicate severity. CVSS scores provide a standardized way to communicate the severity of vulnerabilities across teams and organizations.
Inform remediation strategies. CVSS enrichment data can guide Quay.io users in developing appropriate remediation strategies.
Compliance and reporting. Integrating CVSS data into reports generated by Clair can help organizations demonstrate their commitment to addressing security vulnerabilities and complying with industry standards and regulations.

11.2. Viewing Clair security scans by using the UI
Copy link

Additional resources

To review the results of a Clair security scan, you can open the Security Scanner page for a tag in the Red Hat Quay UI. You can inspect detected CVEs and check available remediation options.

Procedure

Navigate to a repository and click Tags in the navigation pane. This page shows the results of the security scan.
To reveal more information about multi-architecture images, click See Child Manifests to see the list of manifests in extended view.
Click a relevant link under See Child Manifests, for example, 1 Unknown to be redirected to the Security Scanner page.
The Security Scanner page provides information for the tag, such as which CVEs the image is susceptible to, and what remediation options you might have available.
Note
Image scanning only lists vulnerabilities found by Clair security scanner. What users do about the vulnerabilities are uncovered is up to said user.

11.3. Clair severity mapping
Copy link

Clair maps severity strings from multiple security databases to a common set of values in Red Hat Quay. You can use the mapped severities to assess vulnerabilities consistently.

11.3.1. Clair severity strings
Copy link

Clair alerts users with the following severity strings:

Unknown
Negligible
Low
Medium
High
Critical

These severity strings are similar to the strings found within the relevant security database.

The Alpine SecDB database does not provide severity information. All vulnerability severities are Unknown.

Alpine Severity	Clair Severity
*	Unknown

The AWS UpdateInfo database provides severity information.

AWS Severity	Clair Severity
low	Low
medium	Medium
important	High
critical	Critical

The Debian Oval database provides severity information.

Debian Severity	Clair Severity
*	Unknown
Unimportant	Low
Low	Medium
Medium	High
High	Critical

The Oracle Oval database provides severity information.

Oracle Severity	Clair Severity
N/A	Unknown
LOW	Low
MODERATE	Medium
IMPORTANT	High
CRITICAL	Critical

The RHEL Oval database provides severity information.

RHEL Severity	Clair Severity
None	Unknown
Low	Low
Moderate	Medium
Important	High
Critical	Critical

The SUSE Oval database provides severity information.

Severity	Clair Severity
None	Unknown
Low	Low
Moderate	Medium
Important	High
Critical	Critical

The Ubuntu Oval database provides severity information.

Severity	Clair Severity
Untriaged	Unknown
Negligible	Negligible
Low	Low
Medium	Medium
High	High
Critical	Critical

The following table shows how CVSSv3 base scores map to Clair severities:

Base Score	Clair Severity
0.0	Negligible
0.1-3.9	Low
4.0-6.9	Medium
7.0-8.9	High
9.0-10.0	Critical

The following table shows how CVSSv2 base scores map to Clair severities:

Base Score	Clair Severity
0.0-3.9	Low
4.0-6.9	Medium
7.0-10	High

11.4. Building container images
Copy link

The Red Hat Quay builds feature supports building Docker and Podman container images from Dockerfiles. You can create containerized applications by defining build contexts and using base images from public repositories.

Note

Because blueprints rely on images from other public repositories, they might be subject to rate limiting. Consequently, your build could fail.

Quay.io supports the ability to build Docker and Podman container images. This functionality is valuable for developers and organizations who rely on container and container orchestration.

On Quay.io, this feature works the same across both free, and paid, tier plans.

Note

Quay.io limits the number of simultaneous builds that a single user can submit at one time.

11.4.1. Build contexts
Copy link

When building an image with Docker or Podman, a directory is specified to become the build context. This is true for both manual Builds and Build triggers, because the Build that is created by Quay.io is not different than running docker build or podman build on your local machine.

Quay.io Build contexts are always specified in the subdirectory from the Build setup, and fallback to the root of the Build source if a directory is not specified.

When a build is triggered, Quay.io Build workers clone the Git repository to the worker machine, and then enter the Build context before conducting a Build.

For Builds based on .tar archives, Build workers extract the archive and enter the Build context. For example:

Extracted Build archive

example
├── .git
├── Dockerfile
├── file
└── subdir
    └── Dockerfile

Imagine that the Extracted Build archive is the directory structure got a Github repository called example. If no subdirectory is specified in the Build trigger setup, or when manually starting the Build, the Build operates in the example directory.

If a subdirectory is specified in the Build trigger setup, for example, subdir, only the Dockerfile within it is visible to the Build. This means that you cannot use the ADD command in the Dockerfile to add file, because it is outside of the Build context.

Unlike Docker Hub, the Dockerfile is part of the Build context on Quay.io. As a result, it must not appear in the .dockerignore file.

11.4.2. Tag naming for build triggers
Copy link

Tag naming for build triggers in Red Hat Quay lets you create custom tags using templates that include commit information such as SHA, branch name, author, and date. You can use these templates to automatically tag your built images with meaningful identifiers based on the Git commit that triggered the build.

One option is to include any string of characters assigned as a tag for each built image. Alternatively, you can use the following tag templates on the Configure Tagging section of the build trigger to tag images with information from each commit:

Configure Tagging

${commit}: Full SHA of the issued commit
${parsed_ref.branch}: Branch information (if available)
${parsed_ref.tag}: Tag information (if available)
${parsed_ref.remote}: The remote name
${commit_info.date}: Date when the commit was issued
${commit_info.author.username}: Username of the author of the commit
${commit_info.short_sha}: First 7 characters of the commit SHA
${committer.properties.username}: Username of the committer

This list is not complete, but does contain the most useful options for tagging purposes. You can find the complete tag template schema in the Red Hat Quay source repository.

11.4.3. Skipping a source control-triggered build
Copy link

You can skip source control-triggered builds in Red Hat Quay by adding [skip build] or [build skip] to your commit message. This prevents the build system from automatically building images for commits that do not require new builds.

11.4.4. Starting a new build
Copy link

Starting a build creates a container image from a Dockerfile in Red Hat Quay. You can start builds manually by uploading a Dockerfile or automatically by using build triggers.

Prerequisites

You have navigated to the Builds page of your repository.

Procedure

On the Builds page, click Start New Build.
When prompted, click Upload Dockerfile to upload a Dockerfile or an archive that contains a Dockerfile at the root directory.
Click Start Build.
Note
- Currently, users cannot specify the Docker build context when manually starting a build.
- Currently, BitBucket is unsupported on the Red Hat Quay v2 UI.
You are redirected to the build, which can be viewed in real-time. Wait for the Dockerfile build to be completed and pushed.
Optional. you can click Download Logs to download the logs, or Copy Logs to copy the logs.
Click the back button to return to the Repository Builds page, where you can view the build history.

11.4.5. Build triggers
Copy link

Build triggers in Red Hat Quay start container image builds automatically when you push changes to a connected Git repository. You can use GitHub, GitLab, or custom Git triggers to integrate source control events into your build workflow.

11.4.5.1. Creating a build trigger
Copy link

To automate container image builds from your Git repositories, you can create a custom Git build trigger in Red Hat Quay. Build triggers automatically build and push images when you push code to your Git repository.

Quay.io cannot automatically detect the proper Robot Account to use with the trigger. This must be done manually during the creation process.

The following steps can be replicated to create a build trigger using Github, Gitlab, or Bitbucket, however, you must configure the credentials for these services in your config.yaml file.

Note

If you want to use Github to create a build trigger, you must configure Github to be used with Red Hat Quay by creating an OAuth application. For more information, see "Creating an OAuth application Github".

Procedure

Log in to your Red Hat Quay registry.
In the navigation pane, click Repositories.
Click Create Repository.
Click the Builds tab.
On the Builds page, click Create Build Trigger.
Select the desired platform, for example, Github, Bitbucket, Gitlab, or use a custom Git repository. For this example, click Custom Git Repository Push.
Enter a custom Git repository name, for example, git@github.com:<username>/<repo>.git. Then, click Next.
When prompted, configure the tagging options by selecting one of, or both of, the following options:
- Tag manifest with the branch or tag name. When selecting this option, the built manifest the name of the branch or tag for the git commit are tagged.
- Add latest tag if on default branch. When selecting this option, the built manifest with latest if the build occurred on the default branch for the repository are tagged.
  Optionally, you can add a custom tagging template. There are multiple tag templates that you can enter here, including using short SHA IDs, timestamps, author names, committer, and branch names from the commit as tags. For more information, see "Tag naming for build triggers".
  After you have configured tagging, click Next.
When prompted, select the location of the Dockerfile to be built when the trigger is invoked. If the Dockerfile is located at the root of the git repository and named Dockerfile, enter /Dockerfile as the Dockerfile path. Then, click Next.
When prompted, select the context for the Docker build. If the Dockerfile is located at the root of the Git repository, enter / as the build context directory. Then, click Next.
Optional. Choose an optional robot account. This allows you to pull a private base image during the build process. If you know that a private base image is not used, you can skip this step.
Click Next. Check for any verification warnings. If necessary, fix the issues before clicking Finish.
You are alerted that the trigger has been successfully activated. Note that using this trigger requires the following actions:
- You must give the following public key read access to the git repository.
- You must set your repository to POST to the following URL to trigger a build.
  Save the SSH Public Key, then click Return to <organization_name>/<repository_name>. You are redirected to the Builds page of your repository.
On the Builds page, you now have a build trigger. For example:

After you have created a custom Git trigger, additional steps are required. Continue on to "Setting up a custom Git trigger".
If you are setting up a build trigger for Github, Gitlab, or Bitbucket, continue on to "Manually triggering a build".

11.4.5.2. Manually triggering a build
Copy link

Manual build triggering in Red Hat Quay lets you start builds on demand without waiting for automatic triggers from source control. You can manually trigger builds from the Builds page by selecting a build trigger and specifying a commit ID.

Procedure

On the Builds page, Start new build.
When prompted, select Invoke Build Trigger.
Click Run Trigger Now to manually start the process.
Enter a commit ID from which to initiate the build, for example, 1c002dd.
After the build starts, you can see the build ID on the Repository Builds page.

11.4.6. Setting up a custom Git trigger
Copy link

To complete the setup of your custom Git build trigger in Red Hat Quay, you must provide read access to the SSH public key and configure a webhook endpoint. These steps enable your Git repository to automatically trigger builds when you push code.

These steps are only required if you are using a custom Git trigger.

11.5. Notifications overview
Copy link

Notifications in Red Hat Quay alert you about repository events such as pushes, builds, and image expiry. You can configure delivery methods for users, teams, or organizations.

11.5.1. Notification actions
Copy link

Notification actions in Red Hat Quay define how event alerts are delivered. You can send notices by email, webhook, Flowdock, HipChat, or Slack.

Notifications are added to the Events and Notifications section of the Repository Settings page. They are also added to the Notifications window, which can be found by clicking the bell icon in the navigation pane of Quay.io.

Quay.io notifications can be setup to be sent to a User, Team, or the entire organization.

Notifications can be delivered by one of the following methods.

11.5.1.1. E-mail notifications
Copy link

E-mails are sent to specified addresses that describe the specified event. E-mail addresses must be verified on a per-repository basis.

11.5.1.2. Webhook POST notifications
Copy link

An HTTP POST call is made to the specified URL with the event’s data. For more information about event data, see "Repository events description".

When the URL is HTTPS, the call has an SSL client certificate set from Quay.io. Verification of this certificate proves that the call originated from Quay.io. Responses with the status code in the 2xx range are considered successful. Responses with any other status code are considered failures and result in a retry of the webhook notification.

11.5.1.3. Flowdock notifications
Copy link

Posts a message to Flowdock.

11.5.1.4. Hipchat notifications
Copy link

Posts a message to HipChat.

11.5.1.5. Slack notifications
Copy link

Posts a message to Slack.

11.5.2. Creating notifications by using the UI
Copy link

To alert users to repository events such as pushes or build failures, you can create a notification from the Settings page in the Red Hat Quay v2 UI. You select an event trigger and a delivery method, such as email or Slack.

Prerequisites

You have created a repository.
You have administrative privileges for the repository.

Procedure

Navigate to a repository on Quay.io.
In the navigation pane, click Settings.
In the Events and Notifications category, click Create Notification to add a new notification for a repository event. The Create notification popup box appears.
On the Create repository popup box, click the When this event occurs box to select an event. You can select a notification for the following types of events:
- Push to Repository
- Image build failed
- Image build queued
- Image build started
- Image build success
- Image build cancelled
- Image expiry trigger
After you have selected the event type, select the notification method. The following methods are supported:
- Quay Notification
- E-mail Notification
- Webhook POST
- Flowdock Team Notification
- HipChat Room Notification
- Slack Notification
  Depending on the method that you choose, you must include additional information. For example, if you select E-mail, you are required to include an e-mail address and an optional notification title.
After selecting an event and notification method, click Create Notification.

11.5.2.1. Creating an image expiration notification
Copy link

To create an image expiration notification in Red Hat Quay, you can use the v2 UI or the API. You set how many days before expiry to send the alert.

Triggers can work in conjunction with the auto-pruning feature. You can also create this notification by using the createRepoNotification API endpoint.

Prerequisites

FEATURE_GARBAGE_COLLECTION: true is set in your config.yaml file.
Optional. FEATURE_AUTO_PRUNE: true is set in your config.yaml file.

Procedure

On the Red Hat Quay v2 UI, click Repositories.
Select the name of a repository.
Click Settings Events and notifications.
Click Create notification. The Create notification popup box appears.
Click the Select event… box, then click Image expiry trigger.
In the When the image is due to expiry in days box, enter the number of days before the image’s expiration when you want to receive an alert. For example, use 1 for 1 day.
In the Select method… box, click one of the following:
- E-mail
- Webhook POST
- Flowdock Team Notification
- HipChat Room Notification
- Slack Notification
Depending on which method you chose, include the necessary data. For example, if you chose Webhook POST, include the Webhook URL.
Optional. Provide a POST JSON body template.
Optional. Provide a Title for your notification.
Click Submit. You are returned to the Events and notifications page, and the notification now appears.
Optional. You can set the NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES variable in your config.yaml file. with this field set, if there are any expiring images notifications will be sent automatically. By default, this is set to 300, or 5 hours, however it can be adjusted as warranted.
```
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300
```
where:
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES
Specifies that by default, this field is set to 300, or 5 hours.

Verification

Click the menu kebab Test Notification. The following message is returned:

Test Notification Queued
A test version of this notification has been queued and should appear shortly

Depending on which method you chose, check your e-mail, webhook address, Slack channel, and so on. The information sent should look similar to the following example:

{
  "repository": "sample_org/busybox",
  "namespace": "sample_org",
  "name": "busybox",
  "docker_url": "quay-server.example.com/sample_org/busybox",
  "homepage": "http://quay-server.example.com/repository/sample_org/busybox",
  "tags": [
    "latest",
    "v1"
  ],
  "expiring_in": "1 days"
}

11.5.3. Creating notifications by using the API
Copy link

To create, test, reset, or delete repository notifications in Red Hat Quay, you can use the repository notification API endpoints.

Prerequisites

You have created a repository.
You have administrative privileges for the repository.
You have created an OAuth access token.

Procedure

Enter the following POST /api/v1/repository/{repository}/notification command to create a notification on your repository:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  -H "Content-Type: application/json" \
  --data '{
    "event": "<event>",
    "method": "<method>",
    "config": {
      "<config_key>": "<config_value>"
    },
    "eventConfig": {
      "<eventConfig_key>": "<eventConfig_value>"
    }
  }' \
  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification/

This command does not return output in the CLI. Instead, you can enter the following GET /api/v1/repository/{repository}/notification/{uuid} command to obtain information about the repository notification:

{"uuid": "240662ea-597b-499d-98bb-2b57e73408d6", "title": null, "event": "repo_push", "method": "quay_notification", "config": {"target": {"name": "quayadmin", "kind": "user", "is_robot": false, "avatar": {"name": "quayadmin", "hash": "b28d563a6dc76b4431fc7b0524bbff6b810387dac86d9303874871839859c7cc", "color": "#17becf", "kind": "user"}}}, "event_config": {}, "number_of_failures": 0}

You can test your repository notification by entering the following POST /api/v1/repository/{repository}/notification/{uuid}/test command:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  https://<quay-server.example.com>/api/v1/repository/<repository>/notification/<uuid>/test

Example output

{}

You can reset repository notification failures to 0 by entering the following POST /api/v1/repository/{repository}/notification/{uuid} command:

$ curl -X POST \
  -H "Authorization: Bearer <bearer_token>" \
  https://<quay-server.example.com>/api/v1/repository/<repository>/notification/<uuid>

Enter the following DELETE /api/v1/repository/{repository}/notification/{uuid} command to delete a repository notification:

$ curl -X DELETE \
  -H "Authorization: Bearer <bearer_token>" \
  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification/<uuid>

This command does not return output in the CLI. Instead, you can enter the following GET /api/v1/repository/{repository}/notification/ command to retrieve a list of all notifications:

$ curl -X GET  -H "Authorization: Bearer <bearer_token>"   -H "Accept: application/json"  https://<quay-server.example.com>/api/v1/repository/<namespace>/<repository_name>/notification

Example output

{"notifications": []}

11.5.4. Repository events description
Copy link

Repository events in Red Hat Quay describe the triggers that can generate notifications. You can use these event types when you configure alerts.

11.5.4.1. Repository Push
Copy link

A successful push of one or more images was made to the repository:

{
  "name": "repository",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "homepage": "https://quay.io/repository/dgangaia/repository",
  "updated_tags": [
    "latest"
  ]
}

11.5.4.2. Dockerfile Build Queued
Copy link

The following example is a response from a Dockerfile Build that has been queued into the Build system.

Note

Responses can differ based on the use of optional attributes.

{
  "build_id": "296ec063-5f86-4706-a469-f0a400bf9df2",
  "trigger_kind": "github",                                                       //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                           //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "repo": "test",
  "trigger_metadata": {
    "default_branch": "master",
    "commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735",
    "ref": "refs/heads/master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                             //Optional
      "url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735",
      "date": "2019-03-06T12:48:24+11:00",
      "message": "adding 5",
      "author": {                                                                //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                    //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"    //Optional
      },
      "committer": {
        "username": "web-flow",
        "url": "https://github.com/web-flow",
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"
      }
    }
  },
  "is_manual": false,
  "manual_user": null,
  "homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2"
}

11.5.4.3. Dockerfile Build started
Copy link

The following example is a response from a Dockerfile Build that has been queued into the Build system.

Note

Responses can differ based on the use of optional attributes.

{
  "build_id": "a8cc247a-a662-4fee-8dcb-7d7e822b71ba",
  "trigger_kind": "github",                                                     //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                         //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "50bc599",
  "trigger_metadata": {                                                         //Optional
    "commit": "50bc5996d4587fd4b2d8edc4af652d4cec293c42",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                            //Optional
      "url": "https://github.com/dgangaia/test/commit/50bc5996d4587fd4b2d8edc4af652d4cec293c42",
      "date": "2019-03-06T14:10:14+11:00",
      "message": "test build",
      "committer": {                                                            //Optional
        "username": "web-flow",
        "url": "https://github.com/web-flow",                                   //Optional
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"   //Optional
      },
      "author": {                                                               //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                   //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"   //Optional
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/a8cc247a-a662-4fee-8dcb-7d7e822b71ba"
}

11.5.4.4. Dockerfile Build successfully completed
Copy link

The following example is a response from a Dockerfile Build that has been successfully completed by the Build system.

Note

This event occurs simultaneously with a Repository Push event for the built image or images.

{
  "build_id": "296ec063-5f86-4706-a469-f0a400bf9df2",
  "trigger_kind": "github",                                                       //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                           //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "b7f7d2b",
  "image_id": "sha256:0339f178f26ae24930e9ad32751d6839015109eabdf1c25b3b0f2abf8934f6cb",
  "trigger_metadata": {
    "commit": "b7f7d2b948aacbe844ee465122a85a9368b2b735",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                              //Optional
      "url": "https://github.com/dgangaia/test/commit/b7f7d2b948aacbe844ee465122a85a9368b2b735",
      "date": "2019-03-06T12:48:24+11:00",
      "message": "adding 5",
      "committer": {                                                              //Optional
        "username": "web-flow",
        "url": "https://github.com/web-flow",                                     //Optional
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"                                                        //Optional
      },
      "author": {                                                                 //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                     //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"     //Optional
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/296ec063-5f86-4706-a469-f0a400bf9df2",
  "manifest_digests": [
    "quay.io/dgangaia/test@sha256:2a7af5265344cc3704d5d47c4604b1efcbd227a7a6a6ff73d6e4e08a27fd7d99",
    "quay.io/dgangaia/test@sha256:569e7db1a867069835e8e97d50c96eccafde65f08ea3e0d5debaf16e2545d9d1"
  ]
}

11.5.4.5. Dockerfile Build failed
Copy link

The following example is a response from a Dockerfile Build that has failed.

{
  "build_id": "5346a21d-3434-4764-85be-5be1296f293c",
  "trigger_kind": "github",                                                       //Optional
  "name": "test",
  "repository": "dgangaia/test",
  "docker_url": "quay.io/dgangaia/test",
  "error_message": "Could not find or parse Dockerfile: unknown instruction: GIT",
  "namespace": "dgangaia",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",                           //Optional
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "6ae9a86",
  "trigger_metadata": {                                                           //Optional
    "commit": "6ae9a86930fc73dd07b02e4c5bf63ee60be180ad",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {                                                              //Optional
      "url": "https://github.com/dgangaia/test/commit/6ae9a86930fc73dd07b02e4c5bf63ee60be180ad",
      "date": "2019-03-06T14:18:16+11:00",
      "message": "failed build test",
      "committer": {                                                              //Optional
        "username": "web-flow",
        "url": "https://github.com/web-flow",                                     //Optional
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"     //Optional
      },
      "author": {                                                                 //Optional
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",                                     //Optional
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"     //Optional
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/5346a21d-3434-4764-85be-5be1296f293c"
}

11.5.4.6. Dockerfile Build cancelled
Copy link

The following example is a response from a Dockerfile Build that has been cancelled.

{
  "build_id": "cbd534c5-f1c0-4816-b4e3-55446b851e70",
  "trigger_kind": "github",
  "name": "test",
  "repository": "dgangaia/test",
  "namespace": "dgangaia",
  "docker_url": "quay.io/dgangaia/test",
  "trigger_id": "38b6e180-9521-4ff7-9844-acf371340b9e",
  "docker_tags": [
    "master",
    "latest"
  ],
  "build_name": "cbce83c",
  "trigger_metadata": {
    "commit": "cbce83c04bfb59734fc42a83aab738704ba7ec41",
    "ref": "refs/heads/master",
    "default_branch": "master",
    "git_url": "git@github.com:dgangaia/test.git",
    "commit_info": {
      "url": "https://github.com/dgangaia/test/commit/cbce83c04bfb59734fc42a83aab738704ba7ec41",
      "date": "2019-03-06T14:27:53+11:00",
      "message": "testing cancel build",
      "committer": {
        "username": "web-flow",
        "url": "https://github.com/web-flow",
        "avatar_url": "https://avatars3.githubusercontent.com/u/19864447?v=4"
      },
      "author": {
        "username": "dgangaia",
        "url": "https://github.com/dgangaia",
        "avatar_url": "https://avatars1.githubusercontent.com/u/43594254?v=4"
      }
    }
  },
  "homepage": "https://quay.io/repository/dgangaia/test/build/cbd534c5-f1c0-4816-b4e3-55446b851e70"
}

11.6. Open Container Initiative support
Copy link

Red Hat Quay supports Open Container Initiative image and distribution formats beyond Docker manifests. You can store Helm charts and other OCI media types in the registry.

In addition to container images, a variety of artifacts have emerged that support not just individual applications, but also the Kubernetes platform as a whole. These range from Open Policy Agent (OPA) policies for security and governance to Helm charts and Operators that aid in application deployment.

Quay.io is a private container registry that not only stores container images, but also supports an entire ecosystem of tooling to aid in the management of containers. Quay.io strives to be as compatible as possible with the OCI 1.1 Image and Distribution specifications, and supports common media types like Helm charts (as long as they pushed with a version of Helm that supports OCI) and a variety of arbitrary media types within the manifest or layer components of container images. Support for OCI media types differs from previous iterations of Quay.io, when the registry was more strict about accepted media types. Because Quay.io now works with a wider array of media types, including those that were previously outside the scope of its support, it is now more versatile accommodating not only standard container image formats but also emerging or unconventional types.

In addition to its expanded support for novel media types, Quay.io ensures compatibility with Docker images, including V2_2 and V2_1 formats. This compatibility with Docker V2_2 and V2_1 images demonstrates Quay.io’s commitment to providing a seamless experience for Docker users. Moreover, Quay.io continues to extend its support for Docker V1 pulls, catering to users who might still rely on this earlier version of Docker images.

Support for OCI artifacts are enabled by default. The following examples show you how to use some media types, which can be used as examples for using other OCI media types.

11.6.1. Helm and OCI prerequisites
Copy link

Before you use Helm charts with Red Hat Quay, you can install a supported Helm client and trust registry certificates. OCI chart support requires a compatible Helm version.

Helm simplifies how applications are packaged and deployed. Helm uses a packaging format called Charts which contain the Kubernetes resources representing an application. Quay.io supports Helm charts so long as they are a version supported by OCI.

You can download the most recent version of Helm from the Helm releases page.

11.6.2. Using Helm charts
Copy link

To use Helm charts with Red Hat Quay, you can push and pull OCI chart artifacts in the registry. You manage charts like other supported OCI media types.

Use the following example to download and push an etherpad chart from the Red Hat Community of Practice (CoP) repository.

Prerequisites

You have logged into Quay.io.

Procedure

Add a chart repository by entering the following command:

$ helm repo add redhat-cop https://redhat-cop.github.io/helm-charts

Enter the following command to update the information of available charts locally from the chart repository:
```
$ helm repo update
```
Enter the following command to pull a chart from a repository:
```
$ helm pull redhat-cop/etherpad --version=0.0.4 --untar
```

Enter the following command to package the chart into a chart archive:

$ helm package ./etherpad

Example output

Successfully packaged chart and saved it to: /home/user/linux-amd64/etherpad-0.0.4.tgz

Push the chart to your repository using the helm push command:

helm push etherpad-0.0.4.tgz oci://quay.io/<organization_name>/helm

Example output:

Pushed: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4
Digest: sha256:a6667ff2a0e2bd7aa4813db9ac854b5124ff1c458d170b70c2d2375325f2451b

Ensure that the push worked by deleting the local copy, and then pulling the chart from the repository:

$ rm -rf etherpad-0.0.4.tgz

$ helm pull oci://quay.io/<organization_name>/helm/etherpad --version 0.0.4

Example output:

Pulled: quay370.apps.quayperf370.perfscale.devcluster.openshift.com/etherpad:0.0.4
Digest: sha256:4f627399685880daf30cf77b6026dc129034d68c7676c7e07020b70cf7130902

11.6.3. Cosign OCI support
Copy link

To sign and verify container images with Cosign in Red Hat Quay, you can install Cosign and authenticate to the registry. Cosign uses ECDSA-P256 signatures and Simple Signing payloads.

Cosign is a tool that can be used to sign and verify container images. It uses the ECDSA-P256 signature algorithm and Red Hat’s Simple Signing payload format to create public keys that are stored in PKIX files. Private keys are stored as encrypted PEM files.

Cosign currently supports the following:

Hardware and KMS Signing
Bring-your-own PKI
OIDC PKI
Built-in binary transparency and timestamping service

Use the following procedure to directly install Cosign.

Prerequisites

You have installed Go version 1.16 or later.

Procedure

Enter the following go command to directly install Cosign:

$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0

Example output

go: downloading github.com/sigstore/cosign v1.0.0
go: downloading github.com/peterbourgon/ff/v3 v3.1.0

Generate a key-value pair for Cosign by entering the following command:

$ cosign generate-key-pair

Example output

Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

Sign the key-value pair by entering the following command:

$ cosign sign -key cosign.key quay.io/user1/busybox:test

Example output

Enter password for private key:
Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig

If you experience an UNAUTHORIZED: access to the requested resource is not authorized error when signing, which occurs because Cosign relies on ~./docker/config.json for authorization, you might need to execute the following command:

$ podman login --authfile ~/.docker/config.json quay.io

Example output

Username:
Password:
Login Succeeded!

Enter the following command to see the updated authorization configuration:

$ cat ~/.docker/config.json
{
	"auths": {
		"quay-server.example.com": {
			"auth": "cXVheWFkbWluOnBhc3N3b3Jk"
		}
	}

11.6.4. Installing and using Cosign
Copy link

To install Cosign and sign images in Red Hat Quay, you can generate a key pair, sign a tag, and verify the signature. You authenticate to the registry with your existing credentials.

Prerequisites

You have installed Go version 1.16 or later.
You have set FEATURE_GENERAL_OCI_SUPPORT to True in your config.yaml file.

Procedure

Enter the following go command to directly install Cosign:

$ go install github.com/sigstore/cosign/cmd/cosign@v1.0.0

Example output

go: downloading github.com/sigstore/cosign v1.0.0
go: downloading github.com/peterbourgon/ff/v3 v3.1.0

Generate a key-value pair for Cosign by entering the following command:

$ cosign generate-key-pair

Example output

Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

Sign the key-value pair by entering the following command:

$ cosign sign -key cosign.key quay.io/user1/busybox:test

Example output

Enter password for private key:
Pushing signature to: quay-server.example.com/user1/busybox:sha256-ff13b8f6f289b92ec2913fa57c5dd0a874c3a7f8f149aabee50e3d01546473e3.sig

$ podman login --authfile ~/.docker/config.json quay.io

Example output

Username:
Password:
Login Succeeded!

Enter the following command to see the updated authorization configuration:

$ cat ~/.docker/config.json
{
	"auths": {
		"quay-server.example.com": {
			"auth": "cXVheWFkbWluOnBhc3N3b3Jk"
		}
	}

Chapter 11. Clair security scanner

11.1. About ClairCopy linkLink copied to clipboard!

11.3. Clair severity mappingCopy linkLink copied to clipboard!

11.3.1. Clair severity stringsCopy linkLink copied to clipboard!

11.4. Building container imagesCopy linkLink copied to clipboard!

11.4.1. Build contextsCopy linkLink copied to clipboard!

11.4.2. Tag naming for build triggersCopy linkLink copied to clipboard!

11.4.3. Skipping a source control-triggered buildCopy linkLink copied to clipboard!

11.4.4. Starting a new buildCopy linkLink copied to clipboard!

11.4.5. Build triggersCopy linkLink copied to clipboard!

11.4.5.1. Creating a build triggerCopy linkLink copied to clipboard!

11.4.5.2. Manually triggering a buildCopy linkLink copied to clipboard!

11.4.6. Setting up a custom Git triggerCopy linkLink copied to clipboard!

11.5. Notifications overviewCopy linkLink copied to clipboard!

11.5.1. Notification actionsCopy linkLink copied to clipboard!

11.5.1.1. E-mail notificationsCopy linkLink copied to clipboard!

11.5.1.2. Webhook POST notificationsCopy linkLink copied to clipboard!

11.5.1.3. Flowdock notificationsCopy linkLink copied to clipboard!

11.5.1.4. Hipchat notificationsCopy linkLink copied to clipboard!

11.5.1.5. Slack notificationsCopy linkLink copied to clipboard!

11.5.2. Creating notifications by using the UICopy linkLink copied to clipboard!

11.5.2.1. Creating an image expiration notificationCopy linkLink copied to clipboard!

11.5.3. Creating notifications by using the APICopy linkLink copied to clipboard!

11.5.4. Repository events descriptionCopy linkLink copied to clipboard!

11.5.4.1. Repository PushCopy linkLink copied to clipboard!

11.5.4.2. Dockerfile Build QueuedCopy linkLink copied to clipboard!

11.5.4.3. Dockerfile Build startedCopy linkLink copied to clipboard!

11.5.4.4. Dockerfile Build successfully completedCopy linkLink copied to clipboard!

11.5.4.5. Dockerfile Build failedCopy linkLink copied to clipboard!

11.5.4.6. Dockerfile Build cancelledCopy linkLink copied to clipboard!

11.6. Open Container Initiative supportCopy linkLink copied to clipboard!

11.6.1. Helm and OCI prerequisitesCopy linkLink copied to clipboard!

11.6.2. Using Helm chartsCopy linkLink copied to clipboard!

11.6.3. Cosign OCI supportCopy linkLink copied to clipboard!

11.6.4. Installing and using CosignCopy linkLink copied to clipboard!

Learn

Try, buy, & sell

Communities

About Red Hat

Making open source more inclusive

About Red Hat Documentation

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

11.1. About Clair
Copy link

11.3. Clair severity mapping
Copy link

11.3.1. Clair severity strings
Copy link

11.4. Building container images
Copy link

11.4.1. Build contexts
Copy link

11.4.2. Tag naming for build triggers
Copy link

11.4.3. Skipping a source control-triggered build
Copy link

11.4.4. Starting a new build
Copy link

11.4.5. Build triggers
Copy link

11.4.5.1. Creating a build trigger
Copy link

11.4.5.2. Manually triggering a build
Copy link

11.4.6. Setting up a custom Git trigger
Copy link

11.5. Notifications overview
Copy link

11.5.1. Notification actions
Copy link

11.5.1.1. E-mail notifications
Copy link

11.5.1.2. Webhook POST notifications
Copy link

11.5.1.3. Flowdock notifications
Copy link

11.5.1.4. Hipchat notifications
Copy link

11.5.1.5. Slack notifications
Copy link

11.5.2. Creating notifications by using the UI
Copy link

11.5.2.1. Creating an image expiration notification
Copy link

11.5.3. Creating notifications by using the API
Copy link

11.5.4. Repository events description
Copy link

11.5.4.1. Repository Push
Copy link

11.5.4.2. Dockerfile Build Queued
Copy link

11.5.4.3. Dockerfile Build started
Copy link

11.5.4.4. Dockerfile Build successfully completed
Copy link

11.5.4.5. Dockerfile Build failed
Copy link

11.5.4.6. Dockerfile Build cancelled
Copy link

11.6. Open Container Initiative support
Copy link

11.6.1. Helm and OCI prerequisites
Copy link

11.6.2. Using Helm charts
Copy link

11.6.3. Cosign OCI support
Copy link

11.6.4. Installing and using Cosign
Copy link