2.9.0¶
(2021-04-12)
Enhancements¶
Added support for hosting Helm charts using Helm v2 and v3 (ENGDTR-1750).
Includes support for standard Helm charts, as well as OCI-based Helm charts (an experimental feature in Helm v3).
Chart and optional provenance file can be stored in the repository.
Includes the ability to lint Helm charts against a set of best practices and generate a linting report.
The MSR API now includes the following endpoints for supporting Helm charts in MSR:
Description
Endpoint
Retrieve repository index file
GET /charts/<namespace>/<reponame>/index.yaml
Retrieve chart or provenance file from repository
GET /charts/<namespace>/<reponame>/<chartname>/<filename>
Upload chart (and, optionally, provenance file) to repository
POST /charts/api/<namespace>/<reponame>/charts
Upload provenance file to repository
POST /charts/<namespace>/<reponame>/prov
Delete chart (and provenance file, if present) from repository
DELETE /charts/<namespace>/<reponame>/charts/ \ <chartname>/<chartversion>
Get metadata for all charts in repository:
GET /charts/<namespace>/<reponame>/charts
Get metadata for all versions of a chart in the repository
GET /charts/<namespace>/<reponame>/charts/<chartname>
Get metadata for chart version in repository
GET /charts/<namespace>/<reponame>/charts/ \ <chartname>/<chartversion>
Get default values for chart version in repository
GET /charts/<namespace>/<reponame>/charts/<chartname>/ \ <chartversion>/values
Template a chart version in repository
GET /charts/<namespace>/<reponame>/charts/<chartname>/ \ <chartversion>/template
Lint a particular chart version
POST /charts/api/<namespace>/<reponame>/charts/ \ <chartname>/<chartversion>/lint
Lint every version of all available charts
POST /charts/api/lint
Get linting results (as a JSON file) for a particular chart version in a particular repository
GET /charts/api/<namespace>/<reponame>/charts/ \ <chartname>/<chartversion>/lintsummary
Export linting results (as a CSV file) for a particular chart version in a particular repository
GET /charts/api/<namespace>/<reponame>/charts/ \ <chartname>/<chartversion>/lintsummary/export
Retrieve all available linting rules (each rule includes a name, description, remediation, template, and parameters)
GET /charts/api/lintingrules
Learn more
Added running image enforcement policy support to MSR, which allows users to block clients from pulling images based on specified criteria.
Users can configure policies scoped either globally or at the repository level.
MSR logs all enforcement events to the activity log in the MSR web UI. (MSR tracks enforcement events triggered by global enforcement policies as
GLOBAL
event types.)The MSR API now includes the following endpoints for supporting running image enforcement in MSR:
Description
Endpoint
Get all repository enforcement policies
GET /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies
Create repository enforcement policy
POST /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies
Delete all repository enforcement policies
DELETE /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies
Retrieve specific repository enforcement policy
GET /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies/<enforcementpolicyid>
Delete specific repository enforcement policy
DELETE /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies/<enforcementpolicyid>
Patch specific repository enforcement policy
PATCH /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies/<enforcementpolicyid>
Add rules to specific repository enforcement policy
POST /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies/<enforcementpolicyid>/rules
Delete specific rule from repository enforcement policy
DELETE /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies/<enforcementpolicyid>/rules/<ruleid>
Patch specific rule within repository enforcement policy
PATCH /api/v0/repositories/<namespace>/<reponame>/ \ enforcementPolicies/<enforcementpolicyid>/rules/<ruleid>
Modify global enforcement policy
POST /api/v0/meta/settings/globalEnforcementPolicy/rules
Delete and disable global enforcement policy
DELETE /api/v0/meta/settings/globalEnforcementPolicy
Update specific rule within global enforcement policy
PUT /api/v0/meta/settings/globalEnforcementPolicy/rules/<ruleid>
Delete a specific rule within global enforcement policy
DELETE /api/v0/meta/settings/globalEnforcementPolicy/ \ rules/<ruleid>
Added the capability to download scanner reports and optionally bundle them with the following information (which you can then send to Mirantis, as required):
Missing vulnerabilities
False positives
Incorrect component versions
Additional information
(ENGDTR-2332)
Learn more
Starting with this release, you no longer need to indicate that storage has migrated when modifying backend storage configuration. MSR now assumes that the new storage backend is not empty and that its contents match those of the old backend. Thus, we have removed the --storage-migrated flag and web UI storage migration checkbox from MSR.
If the backend is empty or if the new backend content does not match the the old backend content, MSR produces
unknown blob
errors during pushes and pulls.If you deploy a brand new storage backend and the data inside does not match the old backend, you must first reinitialize the storage with the new --reinitialize-storage flag within reconfigure. Note that this action erases all tag metadata (FIELD-2571).
All analytics reports for instances of MSR with a Mirantis-issued license key now include the license ID (even when the
anonymize analytics
setting is enabled). The license subject reads License ID in the web UI (ENGDTR-2327).Intermittent failures no longer occur during metadata garbage collection when using Google Cloud Storage as the backend (ENGDTR-2376).
Pulling images from a repository using
crictl
no longer returns a 500 error (FIELD-3331).Lengthy tag names no longer overlap with adjacent text in the repository tag list (FIELD-1631).
Security information¶
MSR is not vulnerable to CVE-2019-15562, despite its detection in
dtr-notary-signer
anddtr-notary-server
vulnerability scans, as the SQL backend is not used in Notary deployment (ENGDTR-2319).Vulnerability scans of the
dtr-jobrunner
can give false positives for CVE-2020-29363, CVE-2020-29361, and CVE-2020-29362 in the p11-kit component. The container’s version of p11-kit is not vulnerable to these CVEs. (ENGDTR-2319).Resolved CVE-2019-20907 (ENGDTR-2259).