mirror of https://github.com/docker/docs.git
DVP draft
This commit is contained in:
parent
db02cfa0b5
commit
890ccc1734
|
@ -24,3 +24,5 @@ Swarm Mode
|
|||
[Mm]oby
|
||||
dockerd
|
||||
dockerignore
|
||||
Docker Hub Vulnerability Scanning
|
||||
Basic vulnerability scanning
|
|
@ -20,7 +20,7 @@ redirect_from:
|
|||
---
|
||||
|
||||
The Verified Publisher Program provides several features and benefits to Docker
|
||||
Hub publishers. The following perks are granted based on participation tier:
|
||||
Hub publishers. The program grants the following perks based on participation tier:
|
||||
|
||||
- Verified publisher badge
|
||||
- Insights and analytics
|
||||
|
@ -32,8 +32,8 @@ Hub publishers. The following perks are granted based on participation tier:
|
|||
## Verified publisher badge
|
||||
|
||||
The verified publisher badge signals high quality, and trust, to developers.
|
||||
Images with this badge are verified as high quality, and the content can be
|
||||
trusted.
|
||||
|
||||
Images from publishers with this badge are verified as high quality, and that users can trust the content.
|
||||
|
||||

|
||||
|
||||
|
@ -46,17 +46,18 @@ behavior.
|
|||
|
||||

|
||||
|
||||
Select the time span you want to view analytics data, and export the data in
|
||||
either a summary or raw format. The summary format shows you image pulls per
|
||||
tag, and the raw format lists information about every image pull for the
|
||||
selected time span. Data points include tag, type of pull, user geolocation,
|
||||
client tool (user agent), and more.
|
||||
You can use the view to select the time span you want to view analytics data and export the data in
|
||||
either a summary or raw format.
|
||||
|
||||
The summary format shows image pulls per tag, and the raw format lists information about every image pull for the
|
||||
selected time span. Data points include tag, type of pull, user geolocation, client tool (user agent), and more.
|
||||
|
||||
## Vulnerability scanning
|
||||
|
||||
Automatic vulnerability scanning using Snyk for images published to Docker Hub.
|
||||
Scanning images ensures that the published content is secure, and underlines to
|
||||
developers that it can be trusted. Scanning can be enabled on a per-repository
|
||||
<!-- TODO: Clar -->
|
||||
[Docker Scout](/scout/){:
|
||||
target="blank" rel="noopener" class=""} provides automatic vulnerability scanning for images published to Docker Hub.
|
||||
Scanning images ensures that the published content is secure, and preoves to
|
||||
developers that they can trust the image. You can enable scanning on a per-repository
|
||||
basis, refer to [vulnerability scanning](/docker-hub/vulnerability-scanning/){:
|
||||
target="blank" rel="noopener" class=""} for more information about how to use
|
||||
it.
|
||||
|
|
|
@ -14,19 +14,17 @@ to learn more about the benefits of becoming a verified publisher.
|
|||
|
||||
## View the analytics data
|
||||
|
||||
Analytics data for your repositories is available on the **Insights and
|
||||
You can find analytics data for your repositories on the **Insights and
|
||||
analytics** dashboard at the following URL:
|
||||
`https://hub.docker.com/orgs/{namespace}/insights`. The dashboard contains a
|
||||
chart visualization of the usage data, as well as a table where you can download
|
||||
visualization of the usage data and a table where you can download
|
||||
the data as CSV files.
|
||||
|
||||
To view data in the chart:
|
||||
|
||||
- Select the data granularity: weekly or monthly
|
||||
- Select the time interval: 3, 6, or 12 months
|
||||
- Select one or more repositories in the list.
|
||||
|
||||
You can filter the list by repository name.
|
||||
- Select one or more repositories in the list
|
||||
|
||||

|
||||
|
||||
|
@ -37,18 +35,17 @@ To view data in the chart:
|
|||
> for points in time.
|
||||
{: .tip }
|
||||
|
||||
### Share
|
||||
### Share analytics data
|
||||
|
||||
You can share the visualization chart with others using the share icon located
|
||||
just above the chart:
|
||||
You can share the visualization with others using the share icon above the chart.
|
||||
This is a convenient way to share statistics with others in your organization.
|
||||
|
||||

|
||||
|
||||
Selecting the icon generates a link that gets copied to your clipboard. The link
|
||||
preserves the display selections you've made. When someone uses the link, the
|
||||
preserves the display selections you made. When someone uses the link, the
|
||||
**Insights and analytics** page opens and displays the chart with the same
|
||||
configuration as you had set up when creating the link. This is a convenient way
|
||||
to quickly share statistics with others in your organization.
|
||||
configuration as you had set up when creating the link.
|
||||
|
||||
## Exporting analytics data
|
||||
|
||||
|
@ -63,8 +60,7 @@ can analyze it manually as a spreadsheet.
|
|||
|
||||
### Export data using the website
|
||||
|
||||
Here's how to export usage data for your organization's images using the Docker
|
||||
Hub website.
|
||||
Export usage data for your organization's images using the Docker Hub website by following these steps:
|
||||
|
||||
1. Sign in to [Docker Hub](https://hub.docker.com/){: target="_blank"
|
||||
rel="noopener" class="_"} and select **Organizations**.
|
||||
|
@ -103,7 +99,7 @@ represents an image pull.
|
|||
| Data point | Description | Date added |
|
||||
| ----------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------- |
|
||||
| Action | Request type, see [Action classification rules][1]. One of `pull_by_tag`, `pull_by_digest`, `version_check`. | January 1, 2022 |
|
||||
| Action day | The date part of the timestamp: `YYYY-MM-DD` | January 1, 2022 |
|
||||
| Action day | The date part of the timestamp: `YYYY-MM-DD`. | January 1, 2022 |
|
||||
| Country | Request origin country. | January 1, 2022 |
|
||||
| Digest | Image digest. | January 1, 2022 |
|
||||
| HTTP method | HTTP method used in the request, see [registry API documentation][2] for details. | January 1, 2022 |
|
||||
|
@ -112,8 +108,8 @@ represents an image pull.
|
|||
| Reference | Image digest or tag used in the request. | January 1, 2022 |
|
||||
| Repository | Docker [repository][4] (image name). | January 1, 2022 |
|
||||
| Tag (included when available) | Tag name that's only available if the request referred to a tag. | January 1, 2022 |
|
||||
| Timestamp | Date and time of the request: `YYYY-MM-DD 00:00:00` | January 1, 2022 |
|
||||
| Type | The industry from which the event originates. One of `business`, `isp`, `hosting`, `education`, `null` | January 1, 2022 |
|
||||
| Timestamp | Date and time of the request: `YYYY-MM-DD 00:00:00`. | January 1, 2022 |
|
||||
| Type | The industry from which the event originates. One of `business`, `isp`, `hosting`, `education`, `null`. | January 1, 2022 |
|
||||
| User agent tool | The application a user used to pull an image (for example, `docker` or `containerd`). | January 1, 2022 |
|
||||
| User agent version | The version of the application used to pull an image. | January 1, 2022 |
|
||||
| Domain | Request origin domain, see [Privacy](#privacy). | October 11, 2022 |
|
||||
|
@ -161,20 +157,20 @@ The following table describes the rules applied for determining intent behind
|
|||
pulls. To provide feedback or ask questions about these rules,
|
||||
[fill out the Google Form](https://forms.gle/nb7beTUQz9wzXy1b6){:
|
||||
target="_blank" rel="noopener" class="_"}.
|
||||
|
||||
<!-- TODO: What do the first columns mean? -->
|
||||
| Starting event | Reference | Followed by | Resulting action | Use case(s) | Notes |
|
||||
| :------------- | :-------- | :-------------------------------------------------------------- | :--------------- | :------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| HEAD | tag | N/A | Version check | User already has all layers existing on local machine | This is similar to the use case of a pull by tag when the user already has all the image layers existing locally, however, we are able to differentiate the user intent and classify accordingly. |
|
||||
| GET | tag | N/A | Pull by tag | User already has all layers existing on local machine and/or the image is single-arch |
|
||||
| GET | tag | Get by different digest | Pull by tag | Image is multi-arch | Second GET by digests must be different from the first |
|
||||
| HEAD | tag | GET by same digest | Pull by tag | Image is multi-arch but some or all image layers already exist on the local machine. | The HEAD by tag will send the most current digest, the following GET must be by that same digest. There may occur an additional GET, if the image is multi-arch (see the next row in this table). If the user doesn't want the most recent digest, then the user would perform HEAD by digest. |
|
||||
| HEAD | tag | GET by the same digest, then a second GET by a different digest | Pull by tag | Image is multi-arch | The HEAD by tag will send the most recent digest, the following GET must be by that same digest. Since the image is multi-arch, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user would perform HEAD by digest. |
|
||||
| HEAD | tag | GET by same digest, then a second GET by different digest | Pull by tag | Image is multi-arch | The HEAD by tag will send the most current digest, the following GET must be by that same digest. Since the image is multi-arch, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user would perform HEAD by digest. |
|
||||
| GET | digest | N/A | Pull by digest | User already has all layers existing on local machine and/or the image is single-arch |
|
||||
| HEAD | digest | N/A | Pull by digest | User already has all layers existing on their local machine. |
|
||||
| GET | digest | GET by different digest | Pull by digest | Image is multi-arch | The second GET by digest must be different from the first |
|
||||
| HEAD | digest | GET by same digest | Pull by digest | Image is single arch and/or image is multi-arch but some part of the image already exists on the local machine |
|
||||
| HEAD | digest | GET by same digest, then a second GET by different digest | Pull by Digest | Image is multi-arch |
|
||||
| HEAD | tag | N/A | Version check | User already has all layers existing on local machine | This is similar to the use case of a pull by tag when the user already has all the image layers existing locally, however, it differentiates the user intent and classifies accordingly. |
|
||||
| GET | tag | N/A | Pull by tag | User already has all layers existing on local machine and/or the image is single-architecture |
|
||||
| GET | tag | Get by different digest | Pull by tag | Image is multi-architecture | Second GET by digest must be different from the first. |
|
||||
| HEAD | tag | GET by same digest | Pull by tag | Image is multi-architecture but some or all image layers already exist on the local machine | The HEAD by tag sends the most current digest, the following GET must be by that same digest. There may occur an additional GET, if the image is multi-architecture (see the next row in this table). If the user doesn't want the most recent digest, then the user performs HEAD by digest. |
|
||||
| HEAD | tag | GET by the same digest, then a second GET by a different digest | Pull by tag | Image is multi-architecture | The HEAD by tag sends the most recent digest, the following GET must be by that same digest. Since the image is multi-architecture, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. |
|
||||
| HEAD | tag | GET by same digest, then a second GET by different digest | Pull by tag | Image is multi-architecture | The HEAD by tag sends the most current digest, the following GET must be by that same digest. Since the image is multi-architecture, there is a second GET by a different digest. If the user doesn't want the most recent digest, then the user performs HEAD by digest. |
|
||||
| GET | digest | N/A | Pull by digest | User already has all layers existing on local machine and/or the image is single-architecture |
|
||||
| HEAD | digest | N/A | Pull by digest | User already has all layers existing on their local machine |
|
||||
| GET | digest | GET by different digest | Pull by digest | Image is multi-architecture | The second GET by digest must be different from the first. |
|
||||
| HEAD | digest | GET by same digest | Pull by digest | Image is single-architecture and/or image is multi-architecture but some part of the image already exists on the local machine |
|
||||
| HEAD | digest | GET by same digest, then a second GET by different digest | Pull by Digest | Image is multi-architecture |
|
||||
|
||||
## Changes in data over time
|
||||
|
||||
|
@ -200,11 +196,11 @@ consumers of content on Docker Hub remain completely anonymous.
|
|||
> analytics data.
|
||||
{: .important }
|
||||
|
||||
The summary dataset includes Unique IP address count. This data point only
|
||||
The summary dataset includes unique IP address count. This data point only
|
||||
includes the number of distinct unique IP addresses that request an image.
|
||||
Individual IP addresses are never shared.
|
||||
|
||||
The raw dataset includes user IP domains as a data point. That's the domain name
|
||||
The raw dataset includes user IP domains as a data point. This is the domain name
|
||||
associated with the IP address used to pull an image. If the IP type is
|
||||
`business`, the domain represents the company or organization associated with
|
||||
that IP address (for example, `docker.com`). For any other IP type that's not
|
||||
|
|
|
@ -22,7 +22,7 @@ Scan results include:
|
|||
|
||||
- The source of the vulnerability, such as Operating System (OS) packages and
|
||||
libraries
|
||||
- The version in which it was introduced
|
||||
- The version which introduced the vulnerability
|
||||
- A recommended fixed version (if available) to remediate the vulnerabilities
|
||||
discovered.
|
||||
|
||||
|
@ -51,14 +51,14 @@ improving your security posture.
|
|||
## Scan images with Basic vulnerability scanning
|
||||
|
||||
Repository owners and administrators of a Docker Pro, Team, or a Business tier
|
||||
enable and disable Basic vulnerability scanning. When scanning is active on a
|
||||
can toggle Basic vulnerability scanning. When scanning is active on a
|
||||
repository, anyone with push access can trigger a scan by pushing an image to
|
||||
Docker Hub.
|
||||
|
||||
Additionally, repository owners in a Docker Pro subscription and team members in
|
||||
a Team, or a Business subscription can view the detailed scan reports.
|
||||
|
||||
> **Note**
|
||||
> **Image types supported**
|
||||
>
|
||||
> Basic vulnerability scanning supports scanning images which are of AMD64
|
||||
> architecture, Linux OS, and are less than 10 GB in size.
|
||||
|
@ -67,24 +67,24 @@ a Team, or a Business subscription can view the detailed scan reports.
|
|||
|
||||
Repository owners and administrators can enable Basic vulnerability scanning on
|
||||
a repository. If you are a member of a Team or a Business subscription, ensure
|
||||
the repository you would like to enable scanning on is part of the Team or a
|
||||
the repository you want to enable scanning on is part of the Team or a
|
||||
Business tier.
|
||||
|
||||
To enable Basic vulnerability scanning:
|
||||
|
||||
1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank"
|
||||
rel="noopener" class="_"} account.
|
||||
2. Click **Repositories** from the main menu and select a repository from the
|
||||
2. Select **Repositories** from the main menu and select a repository from the
|
||||
list.
|
||||
3. Go to the **Settings** tab.
|
||||
3. Select the **Settings** tab.
|
||||
4. Under **Image insight settings**, select **Basic Hub vulnerability
|
||||
scanning**.
|
||||
5. Select **Save**.
|
||||
|
||||
### Scan an image
|
||||
|
||||
To scan an image for vulnerabilities, push the image to Docker Hub, to the
|
||||
repository for which you have turned on scanning:
|
||||
To scan an image for vulnerabilities, push to the
|
||||
repository for the image to Docker Hub which you have turned on scanning:
|
||||
|
||||
1. Ensure you have installed Docker locally. See [Get Docker](../get-docker.md)
|
||||
to download and install Docker on your local machine.
|
||||
|
@ -117,14 +117,13 @@ To view the vulnerability report:
|
|||
|
||||
{:width="700px"}
|
||||
|
||||
2. Click on the **Tags** tab > **Digest** > **Vulnerabilities** to view the
|
||||
2. Select the **Tags** tab > **Digest** > **Vulnerabilities** to view the
|
||||
detailed scan report.
|
||||
|
||||
The scan report displays vulnerabilities identified by the scan, sorting them
|
||||
The scan report displays the vulnerabilities identified, sorting them
|
||||
according to their severity, with highest severity listed at the top. It
|
||||
displays information about the package that contains the vulnerability, the
|
||||
version in which it was introduced, and whether the vulnerability is fixed in
|
||||
a later version.
|
||||
version that introduced it, and whether a later version fixes the vulnerability.
|
||||
|
||||
{:width="700px"}
|
||||
|
||||
|
@ -133,18 +132,18 @@ For more information on this view, see
|
|||
|
||||
### Inspect vulnerabilities
|
||||
|
||||
The vulnerability report sorts vulnerabilities based on their severity. It
|
||||
The scan report displays the vulnerabilities identified, sorting them
|
||||
according to their severity, with highest severity listed at the top. It
|
||||
displays information about the package that contains the vulnerability, the
|
||||
version in which it was introduced, and whether the vulnerability has been fixed
|
||||
in a later version.
|
||||
version that introduced it, and whether a later version fixes the vulnerability.
|
||||
|
||||
The vulnerability scan report also allows development teams and security leads
|
||||
The vulnerability scan report helps development teams and security leads
|
||||
to compare the vulnerability counts across tags to see whether the
|
||||
vulnerabilities are decreasing or increasing over time.
|
||||
|
||||
### Fix vulnerabilities
|
||||
|
||||
Once a list of vulnerabilities have been identified, there are a couple of
|
||||
Once you have identified a list of vulnerabilities, there are a couple of
|
||||
actions you can take to remediate the vulnerabilities. For example, you can:
|
||||
|
||||
1. Specify an updated base image in the Dockerfile, check your application-level
|
||||
|
@ -167,8 +166,8 @@ a repository. To disable scanning:
|
|||
|
||||
1. Log into your [Docker Hub](https://hub.docker.com){: target="_blank"
|
||||
rel="noopener" class="_"} account.
|
||||
2. Go to **Repositories** from the main menu and select a repository from the
|
||||
2. Select **Repositories** from the main menu and select a repository from the
|
||||
list.
|
||||
3. Go to the **Settings** tab.
|
||||
3. Select the **Settings** tab.
|
||||
4. Under **Image insight settings**, select **None**.
|
||||
5. Select **Save**.
|
||||
|
|
Loading…
Reference in New Issue