Introduction¶

This documentation provides information on how to deploy Mirantis Container Runtime (MCR). The documentation is intended to help operators to understand the core concepts of the product.

The information provided in this documentation set is being constantly improved and amended based on the feedback and kind requests from the consumers of MCR.

Product Overview¶

Mirantis Container Runtime (MCR) enables you to power your business-critical applications with the industry-leading enterprise container engine. You can run containers on any platform with a fully supported and highly secure container runtime. MCR provides the core functionality and security compliance needed to enable your container orchestration solution of choice with certified proven support for both Kubernetes and Swarm. The most common use cases include:

Container orchestration solution: Organisations often have unique container orchestration requirements and may choose to utilise alternative systems to manage their containers. MCR provides freedom to select the best orchestration solution for your needs whilst still ensuring you have a secure, trusted, and supported container runtime to run your mission-critical workloads.
Secure and validated containers: The challenges in ensuring that the software supply chain is secure does not stop at the container orchestration solution. The key part of securing your container solution is ensuring that only validated and trusted containers can be deployed and run. MCR combined with Mirantis Secure Registry (MSR) gives you the ability to validate and sign your container images to ensure that only approved images can be run in your environment.
Secure validated encryption: Regulated industries need to meet federal regulations to ensure that appropriate levels of encryption are enabled. MCR provides FIPS 140-2 Validated cryptography ensuring that you meet the highest standards necessary to comply with the federal requirements.
Multiple operating systems and infrastructures: With the drive towards multi-cloud and hybrid cloud, computing organisations need to support multiple operating systems on multiple platforms. MCR is certified to run on multiple operating systems, including CentOS, RHEL, Ubuntu, and Windows, for consistent runtime regardless of the platform.

Reference Architecture¶

The MCR Reference Architecture is a work in progress, the intent of which is to keep MCR users apprised of the technical details that pertain to the differences between Mirantis Container Runtime and Docker Engine.

Storage driver compatibility¶

overlay2 is the only storage driver supported by MCR 23.0, with the exception of btrfs, which MCR supports on SLES.

Note

A number of unsupported storage driver options that are available in MCR 20.10 are unavailable in MCR 23.0, as Mirantis is moving users away from unsupported configurations.
The vfs storage driver is available in MCR 23.0 for debugging purposes only.

MCR storage driver compatibility¶
Graphdriver	MCR 20.10	MCR 23.0
overlay2	Supported	Supported
btrfs	Supported only on SLES. Unsupported on all other Linux platforms.	Supported only on SLES. Unavailable on all other Linux platforms.
zfs	Unsupported	Unavailable
fuseoverlayfs	Unsupported	Unavailable
aufs	Unsupported	Unavailable
overlay	Unsupported	Unavailable
devicemapper	Unsupported	Unavailable
vfs	Unsupported	Unsupported

Deployment Guide¶

Mirantis Container Runtime (MCR) is a client-server application with these major components:

A server which is a type of long-running program called a daemon process (the dockerd command).
A REST API which specifies interfaces that programs can use to talk to the daemon and instruct it what to do.
A command line interface (CLI) client (the docker command).

MCR can be installed on several Linux distros as well as on Windows.

Note

MCR is derived from the Moby project, an open framework created by Docker Inc. As such, most of the product commands and setup instruction are identical to those for Docker Engine.

Install the license¶

Warning

Users are not authorized to run MCR without a valid license. For more information, refer to Mirantis Agreements and Terms.

For MCR to recognize your license, you must apply your customer license file at runtime.

To make MCR aware of your license and entitlement, perform the following for each node that will host MCR:

Download the license file.

If you purchased a license from the Mirantis Store, the license file is available through a link in your confirmation email. Otherwise, contact Mirantis Sales and Support to gain access to the file.

Apply the license file.

Platform	Applying the license
Linux distributions	Determine the location of the data root directory. This information is available in the `daemon.json` file associated with MCR. Alternatively, you can specify the data root directory using the --data-root flag at MCR start up. Note that the default data-root directory is `/var/lib/docker`. Copy the license file to the data root directory and name it `docker.lic`. It is imperative that the license be readable by the account/user that runs the docker daemon.
Windows servers	Currently, you do not need to apply a license for Windows server systems, as Mirantis Container Runtime can be run using the installation script.

Platform

Applying the license

Linux distributions

Determine the location of the data root directory. This information is available in the daemon.json file associated with MCR. Alternatively, you can specify the data root directory using the --data-root flag at MCR start up. Note that the default data-root directory is /var/lib/docker.
Copy the license file to the data root directory and name it docker.lic. It is imperative that the license be readable by the account/user that runs the docker daemon.

Windows servers

Currently, you do not need to apply a license for Windows server systems, as Mirantis Container Runtime can be run using the installation script.

Start MCR. If MCR is already running, restart it.

Note

MKE, MSR, and Mirantis Container Cloud have implied MCR licenses.

Install MCR on Windows Servers¶

Mirantis Container Runtime (MCR) enables native Docker containers on Windows Server. Windows Server 2019 and later versions are supported. The Mirantis Container Runtime installation package includes everything you need to run Docker on Windows Server. This topic describes pre-install considerations, and how to download and install Mirantis Container Runtime.

System requirements¶

Windows OS CPU and RAM requirements that must be met are specified in the Windows Server Requirements.

Install MCR with an Internet connection¶

Mirantis provides an installation script to ease MCR installation on a Windows Server machine. The script uses default values, thus allowing it to be run without configuration. You can, however, override the default values with script parameters and env variables. Parameter values take precedence over env variables. Both take precedence over inbuilt default values.

The installation script must be executed from an elevated command prompt. If you want to change the default daemon values, ensure that you have the alternative cofigurations and the related collateral in place prior to executing the script. For example, if you want to enable TLS, store the certificates and write the daemon configuration file before invoking the script.

Obtain the installation script for MCR for Windows Server at https://get.mirantis.com/install.ps1.

(Optional): Allow downloaded script files to run in the current session

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process;

Run the installation script.

The installer will issue a prompt, should it require a reboot.

Note

The installation script installs a numerically higher version by default. The latest tag, however, explicitly denotes the binary that was last pushed, which may not be a numerically higher version.

Test your MCR installation by running the hello-world container.

docker run hello-world:nanoserver

The container starts, prints the Hello from Docker! message, and then exits.

Unable to find image 'hello-world:nanoserver' locally
nanoserver: Pulling from library/hello-world
bce2fbc256ea: Pull complete
3ac17e2e6106: Pull complete
8cac44e17f16: Pull complete
5e160e4d8db3: Pull complete
Digest: sha256:25eac12ba40f7591969085ab3fb9772e8a4307553c14ea72d0e6f98b2c8ced9d
Status: Downloaded newer image for hello-world:nanoserver

Hello from Docker!
This message shows that your installation appears to be working correctly.

FIPS 140-2 cryptographic module support¶

Federal Information Processing Standards (FIPS) Publication 140-2 is a United States Federal security requirement for cryptographic modules.

MCR provides FIPS 140-2 support in Windows Server, which includes a FIPS supported cryptographic module. If the Windows implementation already has FIPS support enabled, FIPS is automatically enabled in MCR.

Note

FIPS 140-2 is only supported in MCR. MKE and MSR currently do not support FIPS 140-2.

To enable FIPS 140-2 compliance on a system that is not in FIPS 140-2 mode, run the following command in PowerShell:

[System.Environment]::SetEnvironmentVariable("DOCKER_FIPS", "1", "Machine")

You can also enable FIPS 140-2 mode using the Windows Registry. To update the pertinent registry key, execute the following PowerShell command as an Administrator:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\" -Name "Enabled" -Value "1"

Restart the Docker service.

Stop-Service docker
Start-Service docker

To confirm Docker is running with FIPS-140-2 enabled, run the docker info.

Labels:
 com.docker.security.fips=enabled

Note

FIPS-140-2 compliance can be disabled if the FIPS-140-2 cryptographic module is installed on the operating system. To disable FIPS-140-2 in Docker but not the operating system, set the value "DOCKER_FIPS","0" in [System.Environment].\

Install MCR offline¶

If your hardware is air-gapped you can still install MCR. To do so, download the installer and copy the files to the air-gapped machine (the default installation assumes that the zipped files and script are in the same location).

On any Internet connected system, go to https://get.mirantis.com/install.ps1 to obtain the MCR for Windows Server installation script.

(Optional): Allow the downloaded script files to run in the current session.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process;

Run the installation script with the -DownloadOnly parameter. As per the parameter name, this action only downloads the zip file (no installation is performed).
```
.\<installation-script> -DownloadOnly
```
Copy the installation script and the installation zip file over to the air-gapped machine and run the install with the -Offline parameter.
```
.\<installation-script> -Offline
```
If prompted, reboot the installer.

Install a specific version¶

Use the following three parameters separately or in tandem to install a specific version of MCR for Windows Server.

Caution

MCR does not support using earlier versions of containerd than the version with which it is released. For supported containerd versions, refer to the Major component versions section of the required MCR version in Release Notes.

.\install.ps1 -Channel
.\install.ps1 -ContainerdVersion
.\install.ps1 -DockerVersion

For example, the installation script will always use the latest GA.

For parameter descriptions, refer to Install script usage.

Update MCR¶

To update MCR to the most recent release, download the latest copy of the installation script and rerun the installation steps.

Go to the Mirantis Container Runtime for Windows Server web page to obtain the installation script for MCR for Windows Server.

(Optional): Allow downloaded script files to run in the current session.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process

Run the installation script.

Install script usage¶

The installation script uses the parameters detailed below.

Parameter	Description
.PARAMETER DownloadUrl	[Alternately specified by $Env:DOWNLOAD_URL] Specifies an alternative repository in which to download container runtime packages.
.PARAMETER Channel	[Alternately specified by $Env:CHANNEL] Specifies which channel to use for picking the binaries (examples include `stable` and `test`). Default: `stable`.
.PARAMETER DockerVersion	[Alternately specified by $Env:DOCKER_VERSION] Specifies the version number for the DockerEE binaries to install. The latest version is the default.
.PARAMETER ContainerdVersion	[Alternately specified by $Env:CONTAINERD_VERSION] Specifies the version number for the containerd binaries to install The latest version is the default.
.PARAMETER DryRun	If specified, list different steps to use without actually invoking those steps.
.PARAMETER Uninstall	If specified, uninstalls all packages. This includes unregistering the corresponding services and removing paths for the package from the registry. All other script parameters (except `DryRun` and `DestPath`) are ignored if this switch is specified. Common parameters such as -Verbose are still honored.
.PARAMETER Ver	Print version info for the script and exit.
.PARAMETER NoServiceStarts	If specified, services are not started on successful install. By default, all services installed by the script are left in a running state before exit.
.PARAMETER DestPath	Path to the directory under which binaries will be installed. Default: %PROGRAMDATA%
.PARAMETER OfflinePackagesPath	The folder for airgap/offline scenarios. For use when the offline or `DownloadOnly` parameters are specified. Used to either save the downloaded packages for later offline use or for pointing to previously downloaded packages for offline install.
.PARAMETER Offline	Install packages in offline/airgap mode. By default the current directory is used to locate previously downloaded packages, a setting that can be overridden by using the `OfflinePackagesPath` parameter.
.PARAMETER DownloadOnly	Download and save packages for later offline/airgap install.
.PARAMETER EngineOnly	Skip all steps except those related to MCR.

Install script notes¶

In scenarios where you have existing software installed that has its own copies of OpenSSL libraries, you may encounter the following error:
```
OpenSSL error: error:0F06D065:common libcrypto
routines:FIPS_mode_set:fips mode not supported
```
This is often arises if you have ming/mingw64 as a part of your PATH env variable. As a workaround, ensure that the offending software is not on the PATH and run the script again.
The script supports airgap functionality by providing access to download packages while online, as well as to install those selfsame packages while offline.

For downloads, please ensure that the script has access to the internet. Use the -DownloadOnly parameter. By default the script will use the current directory to store the packages after download, a setting that can be changed by specifying the path explicitly with the -OfflinePackagesPath parameter.

For offline/airgap install, please use the -Offline parameter. By default the script searches for pacakages in the current directory, a setting that can be changed by specifying the -OfflinePackagesPath parameter.

While downloading using -DownloadOnly parameter, confirm that the download path is accessible to the script, especially if you run the script without administrative rights.

The following is required so that the script can be invoked with named parameters (for example, -ContainerdVersion 1.3.4...). If a parameter is used, its type is checked by powershell - we give a higher precedence to the parameters specified in this manner versus the same value specified by env vars.

Parameters received at invocation time. Some of these values are merged with values specified by env vars - see reconcileParams. Others are used as-is.

Disable MCR Telemetry¶

By default, MCR automatically records and transmits data to Mirantis for monitoring and analysis purposes. The data collected provides the Mirantis Customer Success Organization with information that helps Mirantis to better understand the operational use of MCR by our customers. It also provides key feedback in the form of product usage statistics, which enables our product teams to enhance Mirantis products and services.

To disable the telemetry function, set features.telemetry to false in the daemon.json file, which is located in C:\ProgramData\docker\config\.

{"features":{"telemetry": false}}

You can change the setting back to true to re-enable telemetry

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall MCR¶

Use the following commands to remove MCR from a Windows Server.

Leave any active Docker Swarms.
```
docker swarm leave --force
```
Prune container data.
```
docker system prune -all
```
Run the installation script using the uninstall flag to remove MCR from the system.

Use MCR with Kubernetes¶

Customers who use MCR with Kubernetes directly (without MKE) must use a plugin maintained by Kubernetes called dockershim for Kubernetes 1.23 and below or a plugin maintained by Mirantis called cri-docker (included in MCR) for Kubernetes 1.24 and above.

To configure cri-docker:

systemctl enable cri-docker.service

Use MCR with Docker Swarm¶

Mirantis Container Runtime (MCR) supports the use of Docker Swarm.

The following Docker documentation topics offer detailed information that can help you to run MCR in swarm mode:

Security¶

Several Docker resources are available which cover the basics of Mirantis Container Runtime security, including:

Docker Security Documentation describes the fundamentals, such as namespaces and control groups, the attack surface of the Docker daemon, and other kernel security features.
CIS Docker Community Edition Benchmark details the various security-related options in MCR.
Docker Bench Security is a script that audits your configuration of MCR against the CIS Benchmark.

Antivirus and antimalware¶

When antivirus and antimalware software products scan files in use by MCR, these files can lock in a way that causes Docker commands to hang or causes orphaned snapshots to leak disk space. To circumvent these problems, you can add the Docker data directory to the software’s exclusion list, which is by default /var/lib/docker on Linux systems and %ProgramData%\docker on Windows Server systems. As a result of this action, though, viruses or malware in local Docker images, writable layers of containers, or volumes will go undetected.

Note

If you choose to exclude the Docker data directory from background virus scanning, Mirantis recommends that you schedule recurring tasks for stopping MCR, for scanning the data directory, and for restarting MCR. Make sure to stagger these recurring tasks, though, as running them in sync can cause a system outage.

Docker Content Trust¶

When transferring data among networked systems, trust is a central concern. In particular, when communicating over an untrusted medium such as the internet, it is critical to ensure the integrity and the publisher of all the data a system operates on. You use Docker Engine to push and pull images to a public or private registry. Docker Content Trust (DCT) gives you the ability to verify both the integrity and the publisher of all the data received from a registry over any channel.

Docker Content Trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side or runtime verification of the integrity and publisher of specific image tags.

Through DCT, image publishers can sign their images and image consumers can verify the signatures of the images they pull. Publishers could be individuals or organizations manually signing their content or automated software supply chains signing content as part of their release process.

Image tags and DCT¶

An individual image record has the following identifier:

[REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG]

A particular image REPOSITORY can have multiple tags. For example, latest and 3.1.2 are both tags on the mongo image. An image publisher can build an image and tag combination many times changing the image with each build.

DCT is associated with the TAG portion of an image. Each image repository has a set of keys that image publishers use to sign an image tag. Image publishers have discretion on which tags they sign.

An image repository can contain an image with one tag that is signed and another tag that is not. For example, consider the Mongo image repository. The latest tag could be unsigned while the 3.1.6 tag could be signed. It is the responsibility of the image publisher to decide if an image tag is signed or not. In this representation, some image tags are signed, others are not:

Publishers can choose to sign a specific tag or not. As a result, the content of an unsigned tag and that of a signed tag with the same name may not match. For example, a publisher can push a tagged image someimage:latest and sign it. Later, the same publisher can push an unsigned someimage:latest image. This second push replaces the last unsigned tag latest but does not affect the signed latest version. The ability to choose which tags they can sign allows publishers to iterate over the unsigned version of an image before officially signing it.

Image consumers can enable DCT to ensure that images they use are signed. If a consumer enables DCT, they can only pull, run, or build with trusted images. Enabling DCT is a bit like applying a “filter” to your registry. Consumers “see” only signed image tags while the less desirable, unsigned image tags are “invisible” to them.

To the consumer who has not enabled DCT, nothing changes with regard to how they work with Docker images. Every image is visible regardless of whether it is signed or not.

Docker Content Trust Keys¶

Trust for an image tag is managed through the use of signing keys. A key set is created when an operation using DCT is first invoked. A key set consists of the following classes of keys:

an offline key that is the root of DCT for an image tag
repository or tagging keys that sign tags
server-managed keys such as the timestamp key, which provides freshness security guarantees for your repository

The following image depicts the various signing keys and their relationships:

Warning

Once lost, the root key is not recoverable.

You should back up the root key somewhere safe. Given that it is only required to create new repositories, you should store it offline in hardware. For details on securing, and backing up your keys, make sure you read Manage keys for content trust.

Signing Images with Docker Content Trust¶

Within the Docker CLI, you can sign and push a container image with the $ docker trust command syntax. This is built on top of the Notary feature set, more information for which can be found in the Notary Github Repository.

A prerequisite for signing an image is a container image Registry with a Notary server attached, such as a Mirantis Secure Registry or Docker Hub. Instructions for standing up a self-hosted environment can be found in the Docker official documentation, Deploy Notary Server with Compose.

A delegation key pair is required to sign a container image. These keys can be generated locally using $ docker trust key generate or generated by a certificate authority. If you are using Mirantis Kubernetes Engine, the Client Bundle provides adequate keys for a delegation.

To sign images with Docker Content Trust:

Add the delegation private key to the local Docker trust repository, which by default is stored in ~/.docker/trust/.

If you are generating delegation keys with $ docker trust key generate, the private key is automatically added to the local trust store.

If you are importing a separate key, such as one from a MKE Client Bundle, you must use the $ docker trust key load command:

$ docker trust key generate jeff
Generating key for jeff...
Enter passphrase for new jeff key with ID 9deed25:
Repeat passphrase for new jeff key with ID 9deed25:
Successfully generated and loaded private key. Corresponding public key
available: /home/ubuntu/Documents/mytrustdir/jeff.pub

If you have an existing key, run the following command:

$ docker trust key load key.pem --name jeff
Loading key from "key.pem"...
Enter passphrase for new jeff key with ID 8ae710e:
Repeat passphrase for new jeff key with ID 8ae710e:
Successfully imported key from key.pem

Add the delegation public key to the Notary server. Each delegation key in Notary is specific to a particular image repository. If this is the first time you are adding a delegation to that repository, this command will also initiate the repository, using a local Notary canonical root key. To understand more about initiating a repository, and the role of delegations, refer to the official Docker documentation, Delegations for content trust.
```
$ docker trust signer add --key cert.pem jeff msr.example.com/admin/demo
Adding signer "jeff" to msr.example.com/admin/demo...
Enter passphrase for new repository key with ID 10b5e94:
```

Use the delegation private key to sign a particular tag and push the signature up to the registry.

$ docker trust sign msr.example.com/admin/demo:1
Signing and pushing trust data for local image msr.example.com/admin/demo:1, may overwrite remote trust data
The push refers to repository [msr.example.com/admin/demo]
7bff100f35cb: Pushed
1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528
Signing and pushing trust metadata
Enter passphrase for signer key with ID 8ae710e:
Successfully signed msr.example.com/admin/demo:1

Alternatively, once the keys have been imported an image can be pushed with the $ docker push command:

$ export DOCKER_CONTENT_TRUST=1

$ docker push msr.example.com/admin/demo:1
The push refers to repository [msr.example.com/admin/demo:1]
7bff100f35cb: Pushed
1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528
Signing and pushing trust metadata
Enter passphrase for signer key with ID 8ae710e:
Successfully signed msr.example.com/admin/demo:1

To view remote trust data for a tag or repository:

Run the $ docker trust inspect command to view remote trust data for a tag or a repository:

$ docker trust inspect --pretty msr.example.com/admin/demo:1

Signatures for msr.example.com/admin/demo:1

SIGNED TAG          DIGEST                                                             SIGNERS
1                   3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e   jeff

List of signers and their keys for msr.example.com/admin/demo:1

SIGNER              KEYS
jeff                8ae710e3ba82

Administrative keys for msr.example.com/admin/demo:1

  Repository Key:    10b5e94c916a0977471cc08fa56c1a5679819b2005ba6a257aa78ce76d3a1e27
  Root Key:  84ca6e4416416d78c4597e754f38517bea95ab427e5f95871f90d460573071fc

To remove remote trust data for a tag:

Run the $ docker trust revoke command to remove remote trust data for a tag:

$ docker trust revoke msr.example.com/admin/demo:1
Enter passphrase for signer key with ID 8ae710e:
Successfully deleted signature for msr.example.com/admin/demo:1

Runtime Enforcement with Docker Content Trust¶

Note

Runtime enforcement is a feature that is exclusive to MCR. It is not available in Moby or Docker CE.
The implementation is separate from the only run signed images feature of Mirantis Kubernetes Engine.

Docker Content Trust within the Mirantis Container Runtime prevents a user from using a container image from an untrusted source. It will also prevent a user from building a container image from a base layer from an untrusted source. Trusted sources can include Official Docker Images, found on the Docker Hub or User trusted sources, with repositories and tags signed with the commands detailed in Signing Images with Docker Content Trust.

Engine Signature Verification prevents the following:

$ docker container run of an unsigned or altered image.
$ docker pull of an unsigned or altered image.
$ docker build where the FROM image is not signed or is not scratch.

Note

The implicit pulls and runs performed by worker nodes for a Swarm service on $ docker service create and $ docker service update are also verified. Tag resolution of services requires that all nodes in the Swarm including managers have content trust enabled and similarly configured.

DCT does not verify that the filesystem of a running container has not been altered from what was in the image. For example, it does not prevent a container from writing to the filesystem, once the container is running. Moreover, it does not prevent the image filesystem from being altered on the disk of a Docker host. DCT will also not prevent unsigned images from being imported, loaded, or created.

Enabling DCT within the Mirantis Container Runtime¶

DCT is controlled by the Docker Engine configuration file, which by default is located at /etc/docker/daemon.json. For more information on the configuration file, refer to the official docker documentation, Daemon configuration file.

Note

The configuration can be set only on Linux machines.

The content-trust section is based around a mode option that instructs the engine on whether to enforce signed images, and a trust-pinning section that instructs the engine on which sources to trust.

Mode can take one of three values: disabled, permissive, or enforced.

disabled: Verification is not active and the remainder of the content-trust related configuration is ignored. This is the default value if mode is not specified.
permissive: Verification will be performed, while failures are only logged. Images that cannot be verified successfully can still be pulled and run. This configuration is intended for testing of changes related to content-trust. The results of the signature verification are displayed in the MCR daemon logs.
enforced: Content trust is enforced, thus an image that cannot be verified successfully is not pulled or run.

{
    "content-trust": {
        "mode": "<variable-type>"
    }
}

Official Docker images¶

Note

The IDs of all Notary root keys that are used to verify Docker Official Images are embedded in MCR.

If you want to configure MCR so that only Docker Official Images can be used, you can configure your daemon to do so using the embedded key IDs:

{
  "content-trust": {
    "trust-pinning": {
      "official-library-images": true
    },
    "mode": "enforced"
  }
}

User-signed images¶

There are two options for trust pinning user-signed images: Notary Canonical Root Key ID and Notary Root key ID.

Notary canonical root key ID¶

The Notary Canonical Root Key ID, or DCT Root Key, describes only the root key used to sign a repository, or rather its respective keys. This is the root key on the host that originally signed the repository, such as your workstation. It can be retrieved from the workstation that signed the repository through $ grep -r "root" ~/.docker/trust/private/ (assuming your trust data is at ~/.docker/trust/*). It is expected that this canonical ID has initiated multiple image repositories (mymsr/user1/image1 and mymsr/user1/image2).

Retrieve root ID:

$ grep -r "root" ~/.docker/trust/private
/home/ubuntu/.docker/trust/private/0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403.key:role:
root

Use a canonical ID. In the example that follows, the canonical ID has signed two repos, mymsr/user1/repo1 and mymsr/user1/repo2. Note that wildcards are allowed.

{
  "content-trust": {
    "trust-pinning": {
      "root-keys": {
        "mymsr/user1/*": [
          "0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403"
        ]
      }
    },
    "mode": "enforced"
  }
}

Notary root key ID¶

The Notary Root key ID, or DCT Certificate ID, describes the same as the Notary Canonical Root Key ID; the ID is unique per repository. For example, mymsr/user1/image1 and mymsr/usr1/image2 will each have a unique certificate ID. A certificate ID can be retrieved through a $ docker trust inspect command, labeled as a root-key, referring back to the Notary key name. This is designed for when different users are signing their own repositories, such as when there is no central signing server. As a cert-id is more granular, it would take priority if a conflict occurs over a root ID.

Retrieve root ID:

$ docker trust inspect mymsr/user1/repo1 | jq -r '.[].AdministrativeKeys[] | select(.Name=="Root") | .Keys[].ID'
9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168

Use cert IDs by specifying two repositories with their DCT root ID.

 {
   "content-trust": {
     "trust-pinning": {
       "cert-ids": {
          "mymsr/user1/repo1": [
            "9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168"
          ],
          "mymsr/user2/repo1": [
            "544cf09f294860f9d5bc953ad80b386063357fd206b37b541bb2c54166f38d08"
          ]
       }
     },
     "mode": "enforced"
   }
}

Using DCT in an offline environment¶

If your engine is unable to communicate to the registry, DCT can be enabled to trust cached signature data. This is configured through the allow-expired-cached-trust-data option.

{
  "content-trust": {
    "trust-pinning": {
      "official-library-images": true,
      "root-keys": {
        "mymsr/user1/*": [
          "0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403"
        ]
      },
      "cert-ids": {
        "mymsr/user2/repo1": [
          "9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168"
        ],
      }
    },
    "mode": "enforced",
    "allow-expired-cached-trust-data": true
  }
}

Client Enforcement with Docker Content Trust¶

Content trust is disabled by default in the Docker Client. To enable it, set the DOCKER_CONTENT_TRUST environment variable to 1. This prevents users from working with tagged images unless they contain a signature.

When DCT is enabled in the Docker client, docker CLI commands that operate on tagged images must either have content signatures or explicit content hashes. The commands that operate with DCT are:

push
build
create
pull
run

For example, with DCT enabled a docker pull someimage:latest command only succeeds if someimage:latest is signed. However, an operation with an explicit content hash always succeeds as long as the hash exists:

$ docker pull msr.example.com/user/image:1
Error: remote trust data does not exist for msr.example.com/user/image: msr.example.com does not have trust data for msr.example.com/user/image

$ docker pull msr.example.com/user/image@sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1: Pulling from user/image
ff3a5c916c92: Pull complete
a59a168caba3: Pull complete
Digest: sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1
Status: Downloaded newer image for msr.example.com/user/image@sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1

Open Source Components and Licenses¶

Click any product component license below to download a text file of that license to your local system.

Get Support¶

Mirantis Container Runtime (MCR) subscriptions provide access to prioritized support for designated contacts from your company, agency, team, or organization. MCR service levels are based on your subscription level and the cloud or cluster that you designate in your technical support case. Our support offerings are described on the Enterprise-Grade Cloud Native and Kubernetes Support page. You may inquire about Mirantis support subscriptions by using the contact us form.

The CloudCare Portal is the primary way that Mirantis interacts with customers who are experiencing technical issues. Access to the CloudCare Portal requires prior authorization by your company, agency, team, or organization, and a brief email verification step. <<<<<<< PATCH SET (15828f MCR 23.0 - change back end to backend) After Mirantis sets up its backend systems at the start of the support subscription, a designated administrator at your company, agency, team, or organization, can designate additional contacts. If you have not already received and verified an invitation to our CloudCare Portal, contact your local designated administrator, who can add you to the list of designated contacts. Most companies, agencies, teams, and organizations have multiple designated administrators for the CloudCare Portal, and these are often the persons most closely involved with the software. If you do not know who your local designated administrator is, or you are having problems accessing the CloudCare Portal, you may also send an email to Mirantis support at support@mirantis.com.

Once you have verified your contact details and changed your password, you and all of your colleagues will have access to all of the cases and resources purchased. Mirantis recommends that you retain your Welcome to Mirantis email, because it contains information on how to access the CloudCare Portal, guidance on submitting new cases, managing your resources, and other related issues.

We encourage all customers with technical problems to use the knowledge base, which you can access on the Knowledge tab of the CloudCare Portal. We also encourage you to review the MKE product documentation and release notes prior to filing a technical case, as the problem may already be fixed in a later release or a workaround solution provided to a problem experienced by other customers.

One of the features of the CloudCare Portal is the ability to associate cases with a specific MKE cluster. These are referred to in the Portal as “Clouds”. Mirantis pre-populates your customer account with one or more Clouds based on your subscription(s). You may also create and manage your Clouds to better match how you use your subscription.

Mirantis also recommends and encourages customers to file new cases based on a specific Cloud in your account. This is because most Clouds also have associated support entitlements, licenses, contacts, and cluster configurations. These greatly enhance the ability of Mirantis to support you in a timely manner.

You can locate the existing Clouds associated with your account by using the Clouds tab at the top of the portal home page. Navigate to the appropriate Cloud and click on the Cloud name. Once you have verified that the Cloud represents the correct MKE cluster and support entitlement, you can create a new case via the New Case button near the top of the Cloud page.

One of the key items required for technical support of most MKE cases is the support bundle. This is a compressed archive in ZIP format of configuration data and log files from the cluster. There are several ways to gather a support bundle, each described in the paragraphs below. After you obtain a support bundle, you can upload the bundle to your new technical support case by following the instructions in the Mirantis knowledge base, using the Detail view of your case.

Obtain a full-cluster support bundle using the MKE web UI¶

Log in to the MKE web UI as an administrator.
In the left-side nagivation panel, navigate to <user name> and click Support Bundle.

It may take several minutes for the download to complete.

Note

The default name for the generated support bundle file is docker-support-<cluster-id>-YYYYmmdd-hh_mm_ss.zip. Mirantis suggests that you not alter the file name before submittal to the customer portal. However, if necessary, you can add a custom string between docker-support and <cluster-id>, as in: docker-support-MyProductionCluster-<cluster-id>-YYYYmmdd-hh_mm_ss.zip.
Submit the support bundle to Mirantis by clicking Share support bundle on the success prompt that displays when the support bundle finishes downloading.

Note

Mirantis uses the support bundles you submit for product improvement purposes. Be aware, though that these submissions are not sent directly to the Mirantis Customer Support team that is assigned to the particular issue.
Fill in the Jira feedback dialog, and click Submit.

Obtain a single-node support bundle using the CLI¶

Use SSH to log into a node and run:

MKE_VERSION=$((docker container inspect ucp-proxy \
--format '{{index .Config.Labels "com.docker.ucp.version"}}' \
2>/dev/null || echo -n 3.7.1)|tr -d [[:space:]])

docker container run --rm \
  --name ucp \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --log-driver none \
  mirantis/ucp:${MKE_VERSION} \
  support > \
  docker-support-${HOSTNAME}-$(date +%Y%m%d-%H_%M_%S).tgz

Important

If SELinux is enabled, include the following additional flag: --security-opt label=disable.

Note

The CLI-derived support bundle only contains logs for the node on which you are running the command. If your MKE cluster is highly available, collect support bundles from all manager nodes.

Add the --submit option to the support command to submit the support bundle to Mirantis Customer Support. The support bundle will be sent, along with the following information:
- Cluster ID
- MKE version
- MCR version
- OS/architecture
- Cluster size
Note

Mirantis uses the support bundles you submit for product improvement purposes. Be aware, though that these submissions are not sent directly to the Mirantis Customer Support team that is assigned to the particular issue.

For more information on the support command, refer to mke-cli-support.

Use PowerShell to obtain a support bundle¶

Run the following command on Windows worker nodes to collect the support information and automatically place it in a zip file:

$MKE_SUPPORT_DIR = Join-Path -Path (Get-Location) -ChildPath 'dsinfo'
$MKE_SUPPORT_ARCHIVE = Join-Path -Path (Get-Location) -ChildPath $('docker-support-' + (hostname) + '-' + (Get-Date -UFormat "%Y%m%d-%H_%M_%S") + '.zip')
$MKE_PROXY_CONTAINER = & docker container ls --filter "name=ucp-proxy" --format "{{.Image}}"
$MKE_REPO = if ($MKE_PROXY_CONTAINER) { ($MKE_PROXY_CONTAINER -split '/')[0] } else { 'mirantis' }
$MKE_VERSION = if ($MKE_PROXY_CONTAINER) { ($MKE_PROXY_CONTAINER -split ':')[1] } else { '3.6.0' }
docker container run --name windowssupport `
-e UTILITY_CONTAINER="$MKE_REPO/ucp-containerd-shim-process-win:$MKE_VERSION" `
-v \\.\pipe\docker_engine:\\.\pipe\docker_engine `
-v \\.\pipe\containerd-containerd:\\.\pipe\containerd-containerd `
-v 'C:\Windows\system32\winevt\logs:C:\eventlogs:ro' `
-v 'C:\Windows\Temp:C:\wintemp:ro' $MKE_REPO/ucp-dsinfo-win:$MKE_VERSION
docker cp windowssupport:'C:\dsinfo' .
docker rm -f windowssupport
Compress-Archive -Path $MKE_SUPPORT_DIR -DestinationPath $MKE_SUPPORT_ARCHIVE

Release Notes¶

Important

Mirantis Container Runtime 23.0 follows the version numbering scheme of the upstream Moby and Docker CLI projects. Mirantis may skip upstream versions released in short succession, though, and opt instead to release a patch that contains the content of all upstream versions released in the intervening period since the previous MCR 23.0 patch release.

MCR 23.0.10 current

Patch release for MCR 23.0, which focuses on the delivery of CVE and bug fixes.

Updated containerd to version 1.6.30~rc.2
Updated runc to 1.1.12-rc1.m1
Updated cri-dockerd to version 0.3.11
Updated Fipster (Go runtime) to version go1.21.8m1

Learn more

MCR 23.0.9-1

Patch release for MCR 23.0 that delivers a runc update that fixes CVE-2024-21626.

Learn more

MCR 23.0.9

Patch release for MCR 23.0, which focuses on the delivery of CVE and bug fixes.

Fixed an issue that pertains to the enabling of FIPS for Swarm.
Fixed an issue that prevented docker exec from working in FIPS mode.
Updated Fipster (Go runtime) to version 1.20.12m1
Updated containerd to version 1.6.28-rc.1
Update cri-dockerd to version 0.3.9
Updated buildx version 0.12.0m (4932eecc)

Learn more

MCR 23.0.8

Patch release for MCR 23.0, which introduces the following key product improvements:

Updated Fipster (Go runtime) to version go1.20.10m1
Updated containerd to version 1.6.25-rc.1
Update cri-dockerd to version 0.3.7
Updated buildx version 0.12.0-rc1
Resolved CVEs in the Go runtime

Learn more

MCR 23.0.7

Patch release for MCR 23.0, which introduces the following key product improvements:

Updated Fipster (Go runtime) to version go1.19.12m1
Updated containerd to version 1.6.22
Resolved CVEs in the Go runtime

Learn more

MCR 23.0.6

Patch release for MCR 23.0, which introduces the following key product improvements:

Updated Fipster (Go runtime) to version go1.19.10m1
Updated containerd to version 1.6.21
Updated docker buildx to version 0.10.5
Updated cri-dockerd to version 0.3.4
Resolved CVEs in the Go runtime

Learn more

MCR 23.0.5

Patch release for MCR 23.0, which introduces the following key product improvements:

Updated Fipster (Go runtime) to version go1.19.8m1
Bug fixes in the daemon and CLI
Resolved CVEs in the Go runtime

Learn more

MCR 23.0.3

Patch release for MCR 23.0, which introduces the following key product improvements:

Updated Fipster (Go runtime) to version go1.19.7m3
Updated containerd to version 1.6.19
Updated docker buildx to version 0.10.4
Updated cri-dockerd to version 0.3.1
Resolved CVEs in Moby
Resolved CVEs in the Go runtime and FIPS module

Learn more

MCR 23.0.1

Initial release for MCR 23.0, which introduces the following features and improvements:

Storage driver removals
Semantic Versioning (SemVer) format
CSI drivers
BuildKit and buildx by default
Volume Prune and API 1.42
Windows Server 2019 required
Health checks
Rootless and seccomp

Learn more

23.0.10¶

Release date	Name	Upstream release
2024-MAR-20	MCR 23.0.10	Moby 23.0.10 and Docker CLI 23.0.10

Important

Following the initial MCR 23.0.10 patch release, as testing and internal usage continued, it was discovered that Mirantis customers on Linux could be impacted by an upstream race condition issue in the 1.6.30-rc.1 version of containerd. To remedy the matter, Mirantis quickly replaced that version of containerd with a new version, containerd 1.6.30~rc.2.

Mirantis recommends that you check the containerd version on your MCR 23.0.10 deployment. If you have containerd 1.6.30-rc.1, download and install containerd 1.6.30-rc.2.

To learn more about the upstream race container issue, refer to Mirantis patches containerd to address race condition on the Mirantis blog.

Changelog¶

MCR 23.0.10 comprises the Moby 23.0.10 upstream release.

Changes specific to MCR¶

MCR contains the following component updates:
- containerd 1.6.30~rc.2
- runc 1.1.12-rc1.m1
- cri-dockerd 0.3.11
- Fipster (Go runtime) go1.21.8m1

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.10 release:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.10 is presented in the table below:

Component	Version
Moby	23.0.10
containerd	1.6.30~rc.2
runc	v1.1.12-rc1.m1
cri-dockerd	0.3.11
buildx	0.12.0m (4932eecc)
Fipster (Go runtime)	go1.21.8m1
buildkit	0.10.7-m1
rootlesskit	1.1.0

23.0.9-1¶

For information on the MCR 23.0.9-1 release and its effect on MKE, refer to the the following technical bulletins:

Important

Launchpad users should confirm that they have installed the latest version before using the product to install MCR 23.0.9-1.

Release date	Name	Upstream release
2024-FEB-08	MCR 23.0.9-1	Moby 23.0.9 and Docker CLI 23.0.9

Changelog¶

MCR 23.0.9-1 comprises the Moby 23.0.9 upstream release.

Changes specific to MCR¶

An upgrade to runc 1.1.11-rc1.m1 resolves CVE-2024-21626.

Major component versions¶

Version detail for the major components that comprise MCR 23.0.9-1 is presented in the table below:

Component	Version
Moby	23.0.9
containerd	1.6.28-rc.1
runc	v1.1.11-rc1.m1
cri-dockerd	0.3.9
buildx	0.12.0m (4932eecc)
Fipster (Go runtime)	go1.20.12m1
buildkit	0.10.7
rootlesskit	1.1.0

23.0.9¶

Release date	Name	Upstream release
2024-JAN-31	MCR 23.0.9	Moby 23.0.9 and Docker CLI 23.0.9

Changelog¶

MCR 23.0.9 comprises the Moby 23.0.9 upstream release.

Changes specific to MCR¶

Fixed an issue that pertains to the enabling of FIPS for Swarm. Users need to be aware that with this fix in place, FIPS-disabled nodes can no longer join a FIPS-enabled cluster.

Fixed an issue that prevented docker exec from working in FIPS mode.

MCR contains the following component updates:
- containerd 1.6.28-rc.1
- cri-dockerd 0.3.9
- buildx 0.12.0m (4932eecc)
- Fipster (Go runtime) 1.20.12m1

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.9 release:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.9 is presented in the table below:

Component	Version
Moby	23.0.9
containerd	1.6.28-rc.1
runc	1.1.11-rc1
cri-dockerd	0.3.9
buildx	0.12.0m (4932eecc)
Fipster (Go runtime)	go1.20.12m1
buildkit	0.10.7
rootlesskit	1.1.0

23.0.8¶

Release date	Name	Upstream release
2023-11-20	MCR 23.0.8	Moby 23.0.8 and Docker CLI 23.0.8

Changelog¶

MCR 23.0.8 comprises the Moby 23.0.8 upstream release.

Changes specific to MCR¶

MCR contains the following component updates:
- containerd 1.6.25-rc.1
- cri-dockerd 0.3.7
- buildx 0.12.0-rc1
- Fipster (Go runtime) go1.20.10m1

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.8 release:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.8 is presented in the table below:

Component	Version
Moby	23.0.8
containerd	1.6.25-rc.1
runc	1.1.9
cri-dockerd	0.3.7
buildx	0.12.0-rc1
Fipster (Go runtime)	go1.20.10m1
buildkit	0.10.7-0.20230412161310-d52b2d584242
rootlesskit	1.1.0

23.0.7¶

Release date	Name	Upstream release
2023-09-26	MCR 23.0.7	Moby 23.0.7 and Docker CLI 23.0.7

Changelog¶

MCR 23.0.7 comprises the Moby 23.0.7 upstream release.

Changes specific to MCR¶

MCR contains the following component updates:
- containerd v1.6.22, which fixes the following CVEs:
  - NVD CVE-2022-32149
  - NVD CVE-2022-41721.
- Fipster (Go runtime) go1.19.12m1, which fixes:
  - Resolved CVE-2023-29409
  - Security fix net/http: insufficient sanitization of Host header.

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.7 release:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.7 is presented in the table below:

Component	Version
Moby	23.0.7
Docker CLI	23.0.7
containerd	1.6.22
runc	1.1.8
cri-dockerd	0.3.4
buildx	0.10.7
Fipster (Go runtime)	go1.19.12m1
buildkit	0.10.7-0.20230412161310-d52b2d584242
rootlesskit	1.1.0

23.0.6¶

Release date	Name	Upstream release
2023-07-13	MCR 23.0.6	Moby 23.0.6 and Docker CLI 23.0.6

Changelog¶

MCR 23.0.6 comprises the Moby 23.0.6 upstream release.

Changes specific to MCR¶

MCR contains the following component versions:
- Fipster (Go runtime) go1.19.10m1
  
  Contains fixes for the following CVEs: CVE-2023-29402, CVE-2023-29403 CVE-2023-29404, and CVE-2023-29405.
- containerd v1.6.21
- buildx 0.10.5
- cri-dockerd 0.3.4

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.6 release:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.5 is presented in the table below:

Component	Version
Moby	23.0.6
Docker CLI	23.0.6
containerd	1.6.21
runc	1.1.7
cri-dockerd	0.3.4
buildx	0.10.5
Fipster (Go runtime)	go1.19.10m1
buildkit	0.10.7-0.20230412161310-d52b2d584242
rootlesskit	1.1.0

23.0.5¶

Release date	Name	Upstream release
2023-05-16	MCR 23.0.5	Moby 23.0.5 and 23.0.4, Docker CLI 23.0.5 and 23.0.4

Changelog¶

MCR 23.0.5 combines the Moby 23.0.4 and Moby 23.0.5 upstream releases.

Changes specific to MCR¶

MCR contains the following component versions:
- Fipster (Go runtime) go1.19.8m1
  
  Contains fixes for the following CVEs: CVE-2023-24534, CVE-2023-24536 CVE-2023-24537, CVE-2023-24538.
- containerd v1.6.20

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.4 and Moby 23.0.5 releases:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.5 is presented in the table below:

Component	Version
Moby	23.0.5
Docker CLI	23.0.5
containerd	1.6.20
runc	1.1.4
cri-dockerd	0.3.1
buildx	0.10.4
Fipster (Go runtime)	go1.19.8m1
buildkit	0.10.7-0.20230208155512-4f0ee09c40e2
rootlesskit	1.1.0

23.0.3¶

Release date	Name	Upstream release
2023-04-04	MCR 23.0.3	Moby 23.0.3 and 23.0.2, Docker CLI 23.0.3 and 23.0.2

Changelog¶

MCR 23.0.3 combines the Moby 23.0.2 and Moby 23.0.3 upstream releases.

Changes specific to MCR¶

MCR contains the following component versions:
- Fipster (Go runtime) go1.19.7m3
  - Fixes for Go CVEs: CVE-2022-41724, CVE-2022-41723, CVE-2022-41725, CVE-2022-41722, and CVE-2023-24532.
  - Fixes for FIPS module CVEs: CVE-2023-0286, CVE-2023-0215, and CVE-2022-4304.
  - Early backport of Go CL 478660 to solve a regression related to RLIMIT_NOFILE.
- containerd v1.6.19
- buildx v0.10.4
- cri-dockerd v0.3.1

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.2 release:

In addition, as a security-only release, Moby 23.0.3 is tracked by a GitHub security advisory rather than a milestone:

moby/moby, GHSA-232p-vwff-86mp advisory

Major component versions¶

Version detail for the major components that comprise MCR 23.0.3 is presented in the table below:

Component	Version
Moby	23.0.3
Docker CLI	23.0.3
containerd	1.6.19
runc	1.1.4
cri-dockerd	0.3.1
buildx	0.10.4
Fipster (Go runtime)	go1.19.7m3
buildkit	0.10.7-0.20230208155512-4f0ee09c40e2
rootlesskit	1.1.0

23.0.1¶

Release date	Name	Upstream release
2023-02-23	MCR 23.0.1	Moby 23.0.1 and 23.0.0, Docker CLI 23.0.1 and 23.0.0

Highlights¶

Enhancement	Detail
Storage driver removals	Beginning with the release of MCR 23.0, Mirantis no longer delivers unsupported storage drivers to customers. While this creates an upgrade barrier for customers using MCR 20.10 with an unsupported storage driver, it is certain to prevent the late discovery of an unsupportable MCR deployment. `overlay2` is the only storage driver MCR builds and supports, with the exception of the `btrfs` storage driver, which Mirantis will continue to build and support exclusively for the SLES platform (for which `overlay2` is also viable). In addition, Mirantis continues to make the `vfs` storage driver available, but only for the purpose of helping to debug the storage back end. The `vfs` driver remains unsupported and is entirely unfit for use in production environments. In removing the unsupported storage drivers, Mirantis aims to align customers with a longer-term migration to new storage backends that are currently under development in the Moby project. Other points of interest: `overlay2` is now preferred to `btrfs` and `zfs`, which affects new MCR deployments running on SLES systems. `overlay2` can no longer be used on a file system without `d_type`,which may prevent in-place upgrades.
Semantic Versioning (SemVer) format	Beginning with the MCR 23.0 release, in alignment with Moby, Semantic Versioning (SemVer) replaces Calendar Versioning (CalVer). Upstream Moby is moving to SemVer as part of the migration to a Go module, however Moby 23.0 is not yet Go module compatible.
CSI drivers	MCR 23.0 introduces experimental support for Container Storage Interface (CSI) drivers in Swarm. CSI drivers are the same storage drivers that Kubernetes uses, and as Swarm matures as a CSI-compliant implementation it is expected that an entire ecosystem of persistent storage backends will become available. For use with Swarm, a CSI driver must not have a direct coupling to the Kubernetes control plane. The driver must also be packaged natively for Swarm as an Engine plugin. At this time, CSI on Swarm is only fit for development and experimental use. Mirantis is working actively with the Moby development community to evangelize Swarm CSI and further develop its implementation, quickly addressing any bugs and missing features as these become apparent.
BuildKit and buildx by default	MCR 23.0 defaults to the BuildKit builder (`DOCKER_BUILDKIT=1`) on Linux. In addition, the 23.0 CLI makes `docker build` an alias for `docker buildx build`. This reflects the growing maturity of BuildKit, and it will help customers to take advantage of the significant improvements that BuidlKit brings in caching, performance, and flexibility. Though this is a large change in behavior, it is also a mostly transparent one, and users should be aware that they can still request the previous behavior through `DOCKER_BUILDKIT=0`. Refer to the upstream documentation, Differences between legacy builder and BuildKit for more information.
Volume prune and API 1.42	The MCR 23.0 release increments the supported Docker Engine API version to 1.42. With this version of the API, the volume prune action only considers anonymous volumes, ignoring those that were given a name at creation. This change in behavior only occurs when both the CLI and daemon support API version 1.42. Only MCR 23.0 supports API 1.42 at this time, and thus an updated API client such as the MCR 23.0 CLI is required to encounter this new behavior. Users should be aware that older versions of the Docker Engine API continue to consider both anonymous and named volumes when performing a volume prune. A new `all=1` filter is available for use with Docker Engine API 1.42, to widen the filtering so that it once again considers named volumes. Specifically, using an MCR 23.0 CLI, `docker volume prune --filter all=1` produces the same result as `docker volume prune` with an older CLI. `docker system prune -a` is not able to specify this filter, and as such will always reflect the default behavior of the negotiated API version. Refer to Docker Engine API (1.42) for the full API documentation, and to Engine API version history for the full list of changes.
Windows Server 2019 required	Support for Windows Server 2016 is dropped in MCR 23.0. Windows Server RS5 / LTSC 2019 (build 17763) is the new baseline version.
Health checks	In MCR 23.0, the overhead that is required to perform a health check is no longer counted as part of the time threshold. Health checks now properly resume when the daemon is restarted with running containers. Also, rather than being left to hang indefinitely, timed-out health checks are now more reliably killed.
Rootless and seccomp	MCR 23.0 further develops rootless mode by improving support for privileged features, and by making significant enhancements to the capabilities of the seccomp filtering implementation. Advanced MCR users should consider the following changes when diagnosing issues with privilege and permissions: Engine plugins are discoverable at well known user-specific paths in rootless mode. `--privileged` rootless containers can use host devices. `--ipc=host` now works in rootless mode. seccomp profiles can now pass additional flags to the seccomp userspace binary. ErrnoRet can now be set in seccomp profiles. `clone3` is correctly blocked so that glibc will instead use `clone`. `AF_VSOCK` is blocked in the default profile as it cannot be containerized. Other enhancements to the built-in seccomp profile for new system calls, such as BPF and `clock_settime64`.

Changelog¶

MCR 23.0.1 represents the first iteration of the MCR 23.0 major release, combining the Moby 23.0.0 and Moby 23.0.1 upstream releases.

Changes specific to MCR¶

MCR no longer builds unsupported storage drivers, also known as graphdrivers.
apparmor is now unconditionally installed on Ubuntu systems.
MCR contains the following component versions:
- Fipster (Go runtime) go1.19.5m1
- containerd v1.6.17
- buildx v0.10.0
- cri-dockerd v0.3.0

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

What is new

moby/moby#43992 Set Buildx and BuildKit as the default builder on Linux.
- docker/cli#3314 Alias docker build to docker buildx build.
- To use the legacy builder, set DOCKER_BUILDKIT=0.
- Refer to Multi-stage builds to learn the differences between how BuildKit and the legacy builder handle multi-stage builds.
- moby/moby#41759, moby/moby#42862 Add support for pulling zstd compressed layers.
moby/moby#43887, moby/moby#43993 Added support for alternate OCI runtimes that are compatible with the containerd runtime v2 API on Linux.
moby/moby#42089 Added support for the containerd runhcs shim on Windows (off by default).
moby/moby#42393 Added the dockerd --validate option, to check the daemon JSON configuration and exit.
moby/moby#42835 Added the ability to configure the daemon HTTP proxy through flags or JSON configuration.
moby/moby#42626 Added support for RFC 3021 point-to-point networks (IPv4 /31s) and single hosts (IPv4 /32s). For networks with two or fewer addresses, IPAM does not reserve a network and broadcast address.
moby/moby#42542 Added support for setting ipvlan_flag and using the l3s ipvlan_mode in the ipvlan network driver.
moby/moby#43557 Added support for displaying the value of the metacopy option for the overlay2 storage driver.
moby/moby#43368 Added support for describing Windows devices using the syntax IDType://ID.
moby/moby#42330 Added RootlessKit, slirp4netns, and VPNKit version reporting.
moby/moby#41982 Added experimental support for SwarmKit cluster volumes (CSI).
- docker/cli#3606 CLI: Add cluster volume (CSI) options to docker volume.
- docker/cli#3662 CLI: Add cluster volume (CSI) support to docker stack.
docker/cli#2907 Added support for SwarmKit jobs in docker stack deploy.
docker/cli#3544 Added the docker stack config command, which outputs the merged and interpolated configuration files as used by stack deploy.
docker/cli#3567 Added the docker context show command, which prints the name of the current context.
docker/cli#2936 Added the --format=json shorthand variant of --format="{{ json . }}" to all commands supporting the --format flag.
docker/cli#3377 Added a --quiet option to both the docker create and docker run commands, to suppress output when pulling an image.
docker/cli#3547 Added a --force option to the docker network rm subcommand, which causes the CLI to return a 0 exit code even if the network does not exist. This option has no effect on the server-side procedure for removing a network.
docker/cli#3614 Added a --signal option to the docker stop and docker restart commands.
moby/moby#44703 Added a --version (-v) flag to docker-proxy.
moby/moby#44778 Plugins are now discoverable in well-known user-level paths when the daemon is running in rootless mode.
moby/moby#44777, moby/moby#44832 Improved the daemon handling of common alternate JSON encodings in the JSON configuration file, which includes the reporting of useful errors.
- UTF-8 with a byte order mark is accepted.
- UTF-16 with a byte order mark is accepted.
- Invalid UTF-8 is reported early, with a comprehensible error message.
moby/moby#43369 Now allows the use of STOPSIGNAL through the docker commit command.
moby/moby#42132 Added a new option to the awslogs log driver, to allow for skipping log stream creation in CloudWatch.
moby/moby#42838 Added a new option to the awslogs log driver, to specify the log format that is sent to CloudWatch.
moby/moby#43100 Added a new option to the fluentd log driver, to set the reconnection interval.
moby/moby#42224 Added new options-setters to the Go API client: WithTLSClientConfigFromEnv(), WithHostFromEnv(), and WithVersionFromEnv().
docker/cli#3429 Added generation of shell command completion through a docker completion subcommand.
Added to the API:
- moby/moby#42064 Swarm header to GET /_ping and HEAD /_ping, which allows single-request detection of Swarm support.
- moby/moby#43206 signal parameter to POST /containers/{id}/stop and POST /containers/{id}/restart, to set the signal used.
- moby/moby#43484 CreateMountPoint parameter to POST /containers/create.
- moby/moby#42531 shared-size parameter to GET /images/json, to enable shared-size computation of images.
- moby/moby#42559 type parameter to GET /system/df, to control which object types are considered in computing disk usage.

Bug fixes

moby/moby#44944 Fixed an issue wherein BuildKit-enabled builds with inline caching enabled were causing the daemon to crash.
moby/moby#44959 Fixed an issue wherein BuildKit improperly loaded cached layers created by previous versions.
moby/moby#44937 Fixed an issue wherein ipvlan networks created prior to upgrading would prevent the daemon from starting.
moby/moby#44922 Fixed an issue wherein the overlay2 storage driver failed early in metacopy testing when it was initialized on an unsupported backing filesystem.
moby/moby#44892 Fixed an issue wherein exec exit events were misinterpreted as container exits under some runtimes, such as Kata Containers.
docker/cli#4004 Improved the error message that the CLI returned upon receipt of a truncated JSON response caused by the API hanging up during a request.
docker/cli#4004 Fixed an incorrect CLI exit code that occurred when attempting to execute a directory with a runc compiled using Go 1.20.
docker/cli#4004 Fixed an issue wherein --device-write-bps interpreted the size argument not as a size but as a path.
moby/moby#42661 Promoted overlay2 to default storage driver. btrfs and zfs are now opt-in.
docker/cli#2708 Added a loading spinner to the docker cp command.
docker/cli#2819 Deprecated the ElectAuthServer function and forced it to return the default registry without calling the GET /info API endpoint.
docker/cli#2940 Progress bars no longer reverse when Swarm services are rolled back.
docker/cli#2972 net.JoinHostPort() is now used to fix formatting with IPv6 addresses.
docker/cli#3044 CLI error messages are now printed to stderr.
docker/cli#3179 Improved the performance of docker info for instances in which a custom --format is used that only requires local information. Now, the CLI only uses the daemon API if it detects that information from the daemon is required.
docker/cli#3245 Removed the default value from the --stop-signal flag, as at times it may not reflect the actual default in use by the daemon.
docker/cli#3257 Added Compose schema 3.10 to docker stack to thus allow ommission of the version field (resulting in latest).
docker/cli#3445 Compose version 3 is now equivalent to 3.x, the latest version, in docker stack.
docker/cli#3302 Fixed an issue wherein <Ctrl-C> did not send SIGTERM when invoking docker run without --interactive (-i) on Windows.
docker/cli#3469 Added relative source paths to the run command in the -v / --volume and -m / --mount flags.
docker/cli#3627 docker exec -t now sets the console size for the executed process immediately upon creation.
docker/cli#3645 Updated the pretty-print format of docker info, to provide more details on installed plugins.
docker/cli#3668 Added printing of warning messages for the docker context list and docker context use commands, to display whenever the context is overridden by the environment.
docker/cli#3694 Added a custom aliases annotation, to print all available aliases for a command.
docker/cli#3721 The CLI no longer creates or updates the context file when running docker context use with the already active context.
docker/cli#3791 Non-existing contexts are now ignored when docker context rm --force is run.
docker/cli#3812 Integers can now be overridden to 0 in Compose files.
docker/cli#3849 SIGINT (<Ctrl-c>) now passes through to running containers rather than causing the CLI to exit.
docker/cli#3892 Improved the docker port CONTAINER UX by sorting ports prior to printing.
moby/moby#39812 Improvement to the API wherein GET /containers/{id}/logs and POST /containers/{id}/attach now report which raw-stream format is in use by way of the Content-type response header on API version >= 1.42.
moby/moby#41636 Set default sandbox size for Windows layers to 127GB, and ensured that the --storage-opts flag applies to all storage on Windows.
moby/moby#41675 Removed the plugin section from the containerd configuration file (/var/run/docker/containerd/containerd.toml).
moby/moby#41842 null manifests are now rejected during tar import.
moby/moby#41854 Added shim configuration for custom runtimes for plugins.
moby/moby#41935 Fixed an issue wherein container health checks did not resume when the daemon was restarted.
moby/moby#42273 Fixed an issue wherein quota was disabled on cleanup of the btrfs driver.
moby/moby#42638 Accessible host devices can now be mounted in --privileged rootless containers.
moby/moby#42676 Fixed the incorrect handling of **/foo recursive wildcard directory patterns in .dockerignore.
moby/moby#43103 docker import --platform can now mark an imported image as a foreign architecture.
moby/moby#43131 The validation of CPU real-time options is now performed when the daemon starts, rather than being done separately for each individual container, which allows startup to fail earlier in the process.
moby/moby#43210 Close the namesgenerator package off from new additions.
moby/moby#43322 The containers/{id}/attach/ws API endpoint only attaches to the requested streams, as specified by the stdin, stdout, and stderr parameters on API version >= 1.42.
moby/moby#43409 Fixed an issue wherein UDP traffic in containers did not work following container restart under sustained traffic.
moby/moby#43434 Added support for pulling images with custom amd64 micro-architecture feature levels, as supported by the latest versions of Go, GCC, LLVM, and other compilers.
moby/moby#43463 Improved validation of invalid JSON requests in the API.
moby/moby#43480 Mitigated the impact of slow exec starts on health checks. Now, check timeout only applies to the duration that the health check command is running, and the time needed to start the command no longer counts against the timeout.
moby/moby#43593, moby/moby#43622 Console tty size is set immediately on creation.
moby/moby#43659 Fixed an issue wherein overlay2 mounts were not cleaned up following failed container starts, or daemon shutdowns.
moby/moby#43675 Matched manifest list resolution with containerd.
moby/moby#43813 firewalld-enabled networking is now skipped when the daemon is running in rootless mode.
moby/moby#43858 Fixed an issue wherein custom NAT networks were not re-created following daemon restart if they were missing on Windows.
moby/moby#43994 Fixed an issue wherein the container health-check process would not terminate at time out.
moby/moby#44237 Fixed an issue wherein restart policies and volume refs were not correctly restored when the live-restore feature is enabled.
moby/moby#44259 Only anonymous volumes are now pruned by default on API version >= v1.42. To restore the previous setting, wherein named volumes were also included in pruning, pass the filter all=true.
moby/moby#42715 The API now supports concurrent calls to the GET /system/df endpoint.
moby/moby#44831 Improved the reliability of the daemon dumping the stack when sent a SIGQUIT, and exit with status code 2 on SIGQUIT.
moby/moby#43294 Improved the reliability of docker logs -f on Windows, and prevent newlines from being dropped in the local log driver.
moby/moby#44856 Fixed an issue wherein a rare deadlock in the daemon occurred due to the buffering of container logs.
moby/moby#44834 Improved error handling in misc filesystem operations so that the daemon can start on a overlayfs backing filesystem.
moby/moby#44863 Fixed an issue wherein --ipc=host was incorrectly handled whenever the daemon was run in rootless mode.
moby/moby#44752 Fixed a long-standing set of issues wherein stale conntrack entries caused incorrect routing of UDP traffic for containers.
moby/moby#44633 Fixed an issue wherein half-registered containers were listed in the API, as well as a nil pointer de-reference and panic that were caused by the use of a partially registered container in API calls.
moby/moby#44845 Fixed an issue wherein the DOCKER-USER ip6tables chain was not created.
moby/moby#44727 Fixed a failure to clean up iptables rules when the ip6tables command is not available.
moby/moby#44811 Fixed an issue wherein a number of iptables NAT rules were not cleaned up when reenabling the userland proxy.
moby/moby#44400 Fixed a process leak that can occur when a container start fails on Linux.
moby/moby#44725 Fixed an issue wherein the CreatedAt time of a volume was reflecting initialization and not creation.
docker/cli#3901, docker/cli#3904 Fixed an issue in a number of commands wherein the CLI incorrectly reported an incompatible server rather than an unreachable server.
docker/cli#2998 Fixed broken completion of volumes in Zsh.
docker/cli#3847 Improved the output of docker context when an invalid context is present.
docker/cli#3973 Removed ANSI decoration of CLI help annotations when the output is not a TTY, and added a newline for readability.
docker/cli#3986 Added docker container remove as an alias for docker container rm.

GitHub milestones¶

The Github milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 23.0.0 and Moby 23.0.1 releases:

Major component versions¶

Version detail for the major components that comprise MCR 23.0.1 is presented in the table below:

Component	Version
Moby	23.0.1
Docker CLI	23.0.1
containerd	1.6.17
runc	1.1.4
cri-dockerd	0.3.0
buildx	0.10.0
Fipster (Go runtime)	go1.19.5m1
buildkit	0.10.7-0.20230208155512-4f0ee09c40e2
rootlesskit	1.1.0

Release Compatibility Matrix¶

MCR 23.0 Compatibility Matrix¶

Mirantis Container Runtime (MCR) enables containers to run efficiently on any substrate, powering business critical applications at leading companies worldwide.

Mirantis validates MCR for the operating system environments specified here, adhering to the MKE, MSR, and MCR Maintenance Lifecycle. Support for MCR is defined in the Mirantis Cloud Native Platform Subscription Services agreement.

Note

MCR 23.0.5 is the final 23.0.x version to support Ubuntu 18.04.x, as standard LTS support for the distribution ended on 2023-May-31.
MKE 3.5.x and 3.4.x do not support Windows Server 2022.
OS distributed versions not listed in the following matrix are not supported under Standard Support Subscriptions. For such versions, contact your Mirantis rep to discuss support options.

Caution

CentOS 8 entered EOL status as of 31-December-2021. For this reason, Mirantis no longer supports CentOS 8 for all versions of MCR. We encourage customers who are using CentOS 8 to migrate onto any one of the supported operating systems, as further bug fixes will not be forthcoming.

MCR	Max. supported Client API	Platform	Versions
23.0.10	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	9.2, 9.1, 9.0, 8.6, 7.9, 7.8
		RHEL	9.3, 9.2, 9.1, 9.0, 8.9, 8.8, 8.7, 8.6, 8.5, 7.9, 7.8
		Rocky Linux	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5
		SLES	15 SP5, 12 SP5
		Ubuntu	22.04.3, 20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.9-1	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	9.2, 9.1, 9.0, 8.6, 7.9, 7.8
		RHEL	9.3, 9.2, 9.1, 9.0, 8.9, 8.8, 8.7, 8.6, 8.5, 7.9, 7.8
		Rocky Linux	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5
		SLES	15 SP5, 12 SP5
		Ubuntu	22.04.3, 20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.9	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	9.2, 9.1, 9.0, 8.6, 7.9, 7.8
		RHEL	9.3, 9.2, 9.1, 9.0, 8.9, 8.8, 8.7, 8.6, 8.5, 7.9, 7.8
		Rocky Linux	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5
		SLES	15 SP5, 12 SP5
		Ubuntu	22.04.3, 20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.8	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	9.2, 9.1, 9.0, 8.6, 7.9, 7.8
		RHEL	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5, 7.9, 7.8
		Rocky Linux	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5
		SLES	15 SP5, 15 SP4, 12 SP5
		Ubuntu	22.04.3, 20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.7	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	9.2, 9.1, 9.0, 8.6, 7.9, 7.8
		RHEL	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5, 7.9, 7.8
		Rocky Linux	9.2, 9.1, 9.0, 8.8, 8.7, 8.6, 8.5
		SLES	15 SP4, 12 SP5
		Ubuntu	22.04.3, 20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.6	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	8.6, 7.9, 7.8
		RHEL	9.0, 8.8, 8.7, 8.6, 8.5, 7.9, 7.8
		Rocky Linux	8.8, 8.7, 8.6, 8.5
		SLES	15 SP4, 12 SP5
		Ubuntu	20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.5	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	8.6, 7.9, 7.8
		RHEL	9.0, 8.7, 8.6, 8.5, 8.4, 7.9, 7.8
		Rocky Linux	8.7, 8.6, 8.5
		SLES	15 SP4, 12 SP5
		Ubuntu	20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0, 18.04.6, 18.04.5, 18.04.4, 18.04.3, 18.04.2, 18.04.1, 18.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.3	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	8.6, 7.9, 7.8
		RHEL	9.0, 8.7, 8.6, 8.5, 8.4, 7.9, 7.8
		Rocky Linux	8.7, 8.6, 8.5
		SLES	15 SP4, 12 SP5
		Ubuntu	20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0, 18.04.6, 18.04.5, 18.04.4, 18.04.3, 18.04.2, 18.04.1, 18.04.0
		Microsoft Windows Enterprise Server	2022, 2019
23.0.1	1.42	CentOS	7.9.2009, 7.8.2003
		Oracle Linux 1	8.6, 7.9, 7.8
		RHEL	9.0, 8.7, 8.6, 8.5, 8.4, 7.9, 7.8
		Rocky Linux	8.7, 8.6, 8.5
		SLES	15 SP4, 12 SP5
		Ubuntu	20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0, 18.04.6, 18.04.5, 18.04.4, 18.04.3, 18.04.2, 18.04.1, 18.04.0
		Microsoft Windows Enterprise Server	2022, 2019

1(1,2,3,4,5,6,7,8,9): Regarding the Oracle Linux kernel, only Red Hat Compatible Kernel (RHCK) 3.10.x is supported. Unbreakable Enterprise Kernel (UEK) is not supported.
2(1,2,3,4,5,6,7,8,9): A known critical issue is present in the 5.13.0-1028-aws and 5.13.0-1029-aws kernels of the Ubuntu AMIs on AWS. The issue was resolved in the 5.13.0-1030-aws kernel. If you are an AWS user, refer to Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22 and Docker container ports cannot be allocated, otherwise check with your cloud provider.

MKE, MSR, and MCR Maintenance Lifecycle¶

The MKE, MSR, and MCR platform subscription provides software, support, and certification to enterprise development and IT teams that build and manage critical apps in production at scale. It provides a trusted platform for all apps which supply integrated management and security across the app lifecycle, comprised primarily of Mirantis Kubernetes Engine, Mirantis Secure Registry (MSR), and Mirantis Container Runtime (MCR).

Mirantis validates the MKE, MSR, and MCR platform for the operating system environments specified in the MCR 23.0 Compatibility Matrix, adhering to the Maintenance Lifecycle detailed here. Support for the MKE, MSR, and MCR platform is defined in the Mirantis Cloud Native Platform Subscription Services agreement.

Detailed here are all currently supported product versions, as well as the product versions most recently deprecated. It can be assumed that all earlier product versions are at End of Life (EOL).

Important Definitions

“Major Releases” (X.y.z): Vehicles for delivering major and minor feature development and enhancements to existing features. They incorporate all applicable Error corrections made in prior Major Releases, Minor Releases, and Maintenance Releases.
“Minor Releases” (x.Y.z): Vehicles for delivering minor feature developments, enhancements to existing features, and defect corrections. They incorporate all applicable Error corrections made in prior Minor Releases, and Maintenance Releases.
“Maintenance Releases” (x.y.Z): Vehicles for delivering Error corrections that are severely affecting a number of customers and cannot wait for the next major or minor release. They incorporate all applicable defect corrections made in prior Maintenance Releases.
“End of Life” (EOL): Versions are no longer supported by Mirantis, updating to a later version is recommended.

Support lifecycle¶
GA to 12 months	12 to 18 months	18 to 24 months
Full support	Full support ¹	Limited Support for existing installations ²

¹ Software patches for critical bugs and security issues only; no feature enablement.

² Software patches for critical security issues only.

Mirantis Kubernetes Engine (MKE)¶

	3.6.z	3.7.z
General Availability (GA)	2022-OCT-13 (3.6.0)	2023-AUG-30 (3.7.0)
End of Life (EOL)	2024-OCT-13	2025-AUG-29
Release frequency	x.y.Z every 6 weeks	x.y.Z every 6 weeks
Patch release content	As needed: Maintenance releases Security patches Custom hotfixes	As needed: Maintenance releases Security patches Custom hotfixes
Supported lifespan	2 years ¹	2 years ¹

¹ Refer to the Support lifecycle table for details.

EOL MKE Versions¶

MKE Version	EOL date
2.0.z	2017-AUG-16
2.1.z	2018-FEB-07
2.2.z	2019-NOV-01
3.0.z	2020-APR-16
3.1.z	2020-NOV-06
3.2.z	2021-JUL-21
3.3.z	2022-MAY-27
3.4.z	2023-APR-11
3.5.z	2023-NOV-22

Mirantis Secure Registry (MSR)¶

	2.9.z	3.1.z
General Availability (GA)	2021-APR-12 (2.9.0)	2023-SEP-28 (3.1.0)
End of Life (EOL)	2024-OCT-13	2025-SEP-27
Release frequency	x.y.Z every 6 weeks	x.y.Z every 6 weeks
Patch release content	As needed: Maintenance releases Security patches Custom hotfixes	As needed: Maintenance releases Security patches Custom hotfixes
Supported lifespan	2 years ¹	2 years ¹

¹ Refer to the Support lifecycle table for details.

EOL MSR Versions¶

MSR Version	EOL date
2.1.z	2017-AUG-16
2.2.z	2018-FEB-07
2.3.z	2019-FEB-15
2.4.z	2019-NOV-01
2.5.z	2020-APR-16
2.6.z	2020-NOV-06
2.7.z	2021-JUL-21
2.8.z	2022-MAY-27
3.0.z	2024-APR-20

Mirantis Container Runtime (MCR)¶

	Enterprise 23.0
General Availability (GA)	2023-FEB-23 (23.0.1)
End of Life (EOL)	2025-FEB-22
Release frequency	x.y.Z every 6 weeks
Patch release content	As needed: Maintenance releases Security patches Custom hotfixes
Supported lifespan	2 years ¹

¹ Refer to the Support lifecycle table for details.

EOL MCR Versions¶

MCR Version	EOL date
CSE 1.11.z	2017-MAR-02
CSE 1.12.z	2017-NOV-14
CSE 1.13.z	2018-FEB-07
EE 17.03.z	2018-MAR-01
Docker Engine - Enterprise v17.06	2020-APR-16
Docker Engine - Enterprise 18.03	2020-JUN-16
Docker Engine - Enterprise 18.09	2020-NOV-06
Docker Engine - Enterprise 19.03	2021-JUL-21
MCR 19.03.8+	2022-MAY-27
MCR 20.10.0+	2023-DEC-10

Release Cadence and Support Lifecycle¶

With the intent of improving the customer experience, Mirantis strives to offer maintenance releases for the Mirantis Container Runtime (MCR) software every six to eight weeks. Primarily, these maintenance releases will aim to resolve known issues and issues reported by customers, quash CVEs, and reduce technical debt. The version of each MCR maintenance release is reflected in the third digit position of the version number (as an example, for MCR 23.0 the most current maintenance release is MCR 23.0.9).

Regarding major releases, MCR is dependent on Docker Engine major releases upstream. Following such a release, the Mirantis support lifespan of the resulting major version of MCR will adhere to our legacy two year standard.

End of Life Date

For information on MCR version lifecycles, refer to the MKE, MSR, and MCR Maintenance Lifecycle.

As necessary, Mirantis may produce an MCR release between upstream releases. These so-called dash releases can contain hotfixes, packaging changes or depenency changes. In such cases, these dash releases replace the previous release of the same version (as an example, MCR 23.0.9-1 replaces MCR 23.0.9).

Note

In general, MCR dash releases for a particular patch version share the same OS and kernel compatibility.

The MCR team will make every effort to hold to the release cadence stated here. Customers should be aware, though, that development and release cycles can change, and without advance notice.

Technology Preview features¶

A Technology Preview feature provides early access to upcoming product innovations, allowing customers to experiment with the functionality and provide feedback.

Technology Preview features may be privately or publicly available and neither are intended for production use. While Mirantis will provide assistance with such features through official channels, normal Service Level Agreements do not apply.

As Mirantis considers making future iterations of Technology Preview features generally available, we will do our best to resolve any issues that customers experience when using these features.

During the development of a Technology Preview feature, additional components may become available to the public for evaluation. Mirantis cannot guarantee the stability of such features. As a result, if you are using Technology Preview features, you may not be able to seamlessly upgrade to subsequent product releases.

Mirantis makes no guarantees that Technology Preview features will graduate to generally available features.

QuickStart: MCR on Ubuntu¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Ubuntu systems from the repository.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on Ubuntu:

Set up the repository¶

To install MCR using the Mirantis repository you must first set up the repository on the host machine.

Note

MCR only supports x86_64/amd64.

Update the apt package index:
```
sudo apt-get update
```

Install packages that allow apt to use a repository over HTTPS:

sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  software-properties-common

Store https://repos.mirantis.com in an environment variable:
```
DOCKER_EE_URL="https://repos.mirantis.com"
```
Add a $DOCKER_EE_VERSION variable into your environment.
```
DOCKER_EE_VERSION=<mcr-version>
```

Add Docker’s official GPG key:

curl -fsSL "${DOCKER_EE_URL}/ubuntu/gpg" | sudo apt-key add -

Verify that you now have the key with the fingerprint DD91 1E99 5A64 A202 E859 07D6 BC14 F10B 6D08 5F96 by searching for the last eight characters of the fingerprint:

sudo apt-key fingerprint 6D085F96

pub   4096R/0EBFCD88 2017-02-22
      Key fingerprint = DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96
uid                  Docker Release (EE deb) <docker@docker.com>
sub   4096R/6D085F96 2017-02-22

Use the following command to set up the stable repository:

sudo add-apt-repository \
  "deb [arch=$(dpkg --print-architecture)] $DOCKER_EE_URL/ubuntu \
  $(lsb_release -cs) \
  stable-$DOCKER_EE_VERSION"

Install MCR¶

Install the latest version of MCR and containerd:

sudo apt-get install docker-ee docker-ee-cli containerd.io

Note

To install a specific version of MCR:

sudo apt-get install docker-ee=<VERSION_STRING> docker-ee-cli=<VERSION_STRING> containerd.io

Start Docker:
```
sudo systemctl start docker
```

Verify that you installed MCR correctly:

sudo docker run hello-world

This command downloads a test image and runs it in a container. If successful, the command prints the following informational message and exits:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.
Restart MCR:
```
sudo systemctl restart docker
```
Verify the installation:
```
sudo docker info | grep -i license
```

What’s next¶

Refer to Install Mirantis Container Runtime for Ubuntu to learn about these additional installation topics:
- Install from a Debian package
- Upgrade Mirantis Container Runtime
- Uninstall Mirantis Container Runtime (including old versions)
Begin using Docker Hub to find and share images.
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR).
Learn about all the components of Mirantis Cloud Native Platform.

QuickStart: MCR on CentOS¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to CentOS systems from the repository.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on CentoOS:

Set up the repository¶

You only need to set up the repository once, after which you can install MCR from the repository and upgrade as needed. MCR supports the latest version of CentOS 64-bit running on x86_64.

Note

MCR supports the overlay2 storage drivers on CentOS. The following limitations apply:

If you enable selinux, MCR supports overlay2 on CentoOS 7.4 and higher.
If you disable selinux, MCR supports overlay2 on CentOS 7.2 and higher, with kernel version 3.10.0-693 and higher.

Remove any existing Docker repositories from /etc/yum.repos.d/:
```
sudo rm /etc/yum.repos.d/docker*.repo
```
Store https://repos.mirantis.com in an environment variable:
```
export DOCKERURL="https://repos.mirantis.com"
```

Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

sudo -E sh -c \
'echo "$DOCKERURL/centos" > /etc/yum/vars/dockerurl'

Store your operating system version string (7) in /etc/yum/vars/dockerosversion:
```
sudo sh -c 'echo "7" > /etc/yum/vars/dockerosversion'
```
Install the yum-utils that provides the yum-config-manager utility:
```
sudo yum install -y yum-utils
```

Enable the extras RHEL repository to ensure access to the container-selinux package that docker-ee requires:

All architectures except IBM Power

sudo yum-config-manager --enable rhel-7-server-extras-rpms

IBM Power only (little-endian)

sudo yum-config-manager --enable extras
sudo subscription-manager repos \
--enable=rhel-7-for-power-le-extras-rpms
sudo yum makecache fast
sudo yum -y install container-selinux

AWS and Azure require that you enable another repository. For AWS, refer to the official Red Hat Update Infrastructure (RHUI) documentation. For Azure, refer to the official Azure RHUI documentation.

Add the stable MCR repository:

sudo -E yum-config-manager \
--add-repo "$DOCKERURL/centos/docker-ee.repo"

Install MCR¶

Install the latest version of MCR and containerd:
```
sudo yum -y install docker-ee docker-ee-cli containerd.io
```
If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and accept it.
Note

To install a specific version of MCR:
1. Download the three packages required for the desired MCR version from https://repos.mirantis.com/rhel/8/x86_64/stable-23.0/Packages/.
2. Run the following command to complete the MCR installation.
  sudo yum -y install docker-ee-<version-string> \ docker-ee-cli-<version-string> containerd.io
Start Docker:
```
sudo systemctl start docker
```

Verify that you installed MCR correctly:

sudo docker run hello-world

This command downloads a test image and runs it in a container. If successful, it prints the following informational message and exits:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.
Restart MCR:
```
sudo systemctl restart docker
```
Verify the installation:
```
sudo docker info | grep -i license
```

What’s next¶

Refer to Install Mirantis Container Runtime for CentOS to learn about these additional installation topics:
- Install with a package
- Upgrade with a package
- Uninstall Mirantis Container Runtime (including old versions)
Begin using Docker Hub to find and share images.
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR).
Learn about all the components of Mirantis Cloud Native Platform.

QuickStart: MCR on Oracle Linux¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Oracle Linux systems from the repository.

Note

The documentation herein applies only to Oracle Linux 7. Mirantis does not support Oracle 8.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on Oracle Linux:

Set up the repository¶

Note

The documentation herein applies only to Oracle Linux 7. Mirantis does not support Oracle 8.

You only need to set up the repository once, after which you can install MCR from the repository and upgrade as needed.

MCR supports Oracle Linux 64-bit version 7.8 or later and Red Hat Compatible Kernel (RHCK) version 3.10.0-1127 or later.

Note

Mirantis recommends using fast storage, such as solid-state media.

Remove any existing Docker repositories from /etc/yum.repos.d/:
```
sudo rm /etc/yum.repos.d/docker*.repo
```
Store https://repos.mirantis.com in an environment variable:
```
export DOCKERURL="https://repos.mirantis.com"
```

Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

sudo -E sh -c \
'echo "$DOCKERURL/oraclelinux" > /etc/yum/vars/dockerurl'

Install yum-utils to get the yum-config-manager utility:
```
sudo yum install -y yum-utils
```
Enable the Oracle ol7_addons repository to ensure that you have access to the container-selinux package that docker-ee requires:
```
sudo yum-config-manager --enable ol7_addons
```

Add the stable MCR repository:

sudo -E yum-config-manager \
--add-repo \
"$DOCKERURL/oraclelinux/docker-ee.repo"

Install MCR¶

Note

The documentation herein applies only to Oracle Linux 7. Mirantis does not support Oracle 8.

Install the latest version of MCR and containerd:
```
sudo yum -y install docker-ee docker-ee-cli containerd.io
```
If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and accept it.
Note

To install a specific version of MCR:
1. Download the three packages required for the desired MCR version from https://repos.mirantis.com/oraclelinux/7/x86_64/stable-23.0/Packages/.
2. Run the following command to complete the MCR installation.
  sudo yum -y install docker-ee-<version-string> \ docker-ee-cli-<version-string> containerd.io
Start Docker:
```
sudo systemctl start docker
```

Verify that you installed MCR correctly:

sudo docker run hello-world

This command downloads a test image and runs it in a container. If successful, it prints the following informational message and exits:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.
Restart MCR:
```
sudo systemctl restart docker
```
Verify the installation:
```
sudo docker info | grep -i license
```

What’s next¶

Refer to Install Mirantis Container Runtime for Oracle Linux to learn about these additional installation topics:
Begin using Docker Hub to find and share images
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR)
Learn about other components of Mirantis Cloud Native Platform

QuickStart: MCR on RHEL¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Red Hat Enterprise Linux (RHEL) systems from the repository.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on RHEL:

Set up the repository¶

You only need to set up the repository once, after which you can install MCR from the repository and upgrade as needed. MCR supports RHEL 64-bit version 7.4 and higher running on x86_64.

Note

MCR supports the overlay2 storage drivers on RHEL. The following limitations apply:

If you enable selinux, MCR supports overlay2 on RHEL 7.4 and higher (OverlayFS).
If you disable selinux, MCR supports overlay2 on RHEL 7.2 and higher, with kernel version 3.10.0-693 and higher.

Set up the repository for RHEL 7
Set up the repository for RHEL 8

Set up the repository for RHEL 7¶

Remove existing Docker repositories from /etc/yum.repos.d/:
```
sudo rm /etc/yum.repos.d/docker*.repo
```
Store https://repos.mirantis.com in an environment variable:
```
export DOCKERURL="https://repos.mirantis.com"
```

Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

sudo -E sh -c 'echo "$DOCKERURL/rhel" > /etc/yum/vars/dockerurl'

Store your OS version string in /etc/yum/vars/dockerosversion. Use 7 or include the minor version starting with 7.2:
```
sudo sh -c 'echo "<version>" > /etc/yum/vars/dockerosversion'
```
Install the yum-utils that provides the yum-config-manager utility:
```
sudo yum install -y yum-utils
```

Enable the extras RHEL repository to ensure access to the container-selinux package that docker-ee requires:

All architectures except IBM Power

sudo yum-config-manager --enable rhel-7-server-extras-rpms

IBM Power only (little-endian)

sudo yum-config-manager --enable extras
sudo subscription-manager repos \
--enable=rhel-7-for-power-le-extras-rpms
sudo yum makecache fast
sudo yum -y install container-selinux

Enable another repository for AWS and Azure:

AWS

sudo yum-config-manager --enable rhel-7-server-rhui-extras-rpms

Azure

sudo yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms

Add the stable MCR repository:

sudo -E yum-config-manager \
--add-repo \
"$DOCKERURL/rhel/docker-ee.repo"

Set up the repository for RHEL 8¶

Remove existing Docker repositories from /etc/yum.repos.d/:
```
sudo rm /etc/yum.repos.d/docker*.repo
```
Store https://repos.mirantis.com in an environment variable.
```
export DOCKERURL="https://repos.mirantis.com"
```

Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

sudo -E sh -c 'echo "$DOCKERURL/rhel" > /etc/yum/vars/dockerurl'

Store your OS version string in /etc/yum/vars/dockerosversion. Use 8:
```
sudo sh -c 'echo "<version>" > /etc/yum/vars/dockerosversion'
```
Install the yum-utils that provides the yum-config-manager utility:
```
sudo yum install -y yum-utils
```

Add the stable MCR repository:

sudo -E yum-config-manager \
--add-repo \
"$DOCKERURL/rhel/docker-ee.repo"

Install MCR¶

Install the latest version of MCR and containerd:
```
sudo yum -y install docker-ee docker-ee-cli containerd.io
```
If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and accept it.
Note

To install a specific version of MCR:
1. Download the three packages required for the desired MCR version from https://repos.mirantis.com/rhel/8/x86_64/stable-23.0/Packages/.
2. Run the following command to complete the MCR installation.
  sudo yum -y install docker-ee-<version-string> \ docker-ee-cli-<version-string> containerd.io
Start Docker:
```
sudo systemctl start docker
```

Verify that you installed MCR correctly:

sudo docker run hello-world

This command downloads a test image and runs it in a container. If successful, it prints the following informational message and exits:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.
Restart MCR:
```
sudo systemctl restart docker
```
Verify the installation:
```
sudo docker info | grep -i license
```

What’s next¶

Refer to Install Mirantis Container Runtime for Red Hat Enterprise Linux to learn about these additional installation topics:
- FIPS 140-2-support
- Install with a package
- Upgrade from the repository
- Upgrade with a package
- Uninstall Mirantis Container Runtime
Begin using Docker Hub to find and share images
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR).
Learn about other components of Mirantis Cloud Native Platform.

AWS (where `REGION` is a literal and does not represent the region your machine is running in)	Product Documentation for Red Hat Update Infrastructure 4.
Azure	Red Hat Update Infrastructure for on-demand Red Hat Enterprise Linux VMs in Azure

Introduction¶

Product Overview¶

Reference Architecture¶

Storage driver compatibility¶

Deployment Guide¶

Install the license¶

Install MCR on Linux distros¶

Install Mirantis Container Runtime for CentOS¶

Prerequisites¶

Architectures and storage drivers¶

Uninstall old Docker versions¶

Repo install and upgrade¶

Set up the repository¶

Install from the repository¶

Package install and upgrade¶

Install with a package¶

Upgrade with a package¶

Enable MCR Telemetry¶

Run MCR as a non-root user (Rootless mode)¶

Uninstall Mirantis Container Runtime¶

Install Mirantis Container Runtime for Oracle Linux¶

Prerequisites¶

Architectures and storage drivers¶

FIPS 140-2 cryptographic module support¶

Disabling FIPS 140-2¶

Uninstall old Docker versions¶

Repo install and upgrade¶

Set up the repository¶

Install from the repository¶

Upgrade from the repository¶

Package install and upgrade¶

Install with a package¶

Upgrade with a package¶

Enable MCR Telemetry¶

Run MCR as a non-root user (Rootless mode)¶

Uninstall Mirantis Container Runtime¶

Install Mirantis Container Runtime for Red Hat Enterprise Linux¶

Prerequisites¶

Architectures and storage drivers¶

FIPS 140-2 cryptographic module support¶

Disabling FIPS 140-2¶

Uninstall old Docker versions¶

Repo install and upgrade¶

Set up the repository¶

Install from the repository¶

Upgrade from the repository¶

Package install and upgrade¶

Install with a package¶

Upgrade with a package¶

Enable MCR Telemetry¶

Run MCR as a non-root user (Rootless mode)¶

Uninstall Mirantis Container Runtime¶

Install Mirantis Container Runtime for SLES¶

Prerequisites¶

OS requirements¶

Uninstall old versions¶

Configure the Btrfs filesystem¶

Install Mirantis Container Runtime¶

Install using the repository¶

Install from a package¶

Enable MCR Telemetry¶

Run MCR as a non-root user (Rootless mode)¶

Uninstall Mirantis Container Runtime¶

Install Mirantis Container Runtime for Ubuntu¶

Prerequisites¶

Uninstall old versions¶

Install Mirantis Container Runtime¶

Install using the repository¶

Install from a Debian package¶

Enable MCR Telemetry¶

Run MCR as a non-root user (Rootless mode)¶

Uninstall Mirantis Container Runtime¶

Install MCR on Windows Servers¶

System requirements¶

Install MCR with an Internet connection¶

FIPS 140-2 cryptographic module support¶

Install MCR offline¶

Install a specific version¶

Update MCR¶

Install script usage¶