preloader

Container Images

🗓️ Last updated on December 6, 2024 | 7 | Improve this page

Introduction

Microcks components are distributed as OCI container images that can be executed using container runtimes such as Docker or Podman. All our container images are produced for both linux/amd64 and linux/arm64 architectures.

The components container image tags are respecting the following versioning scheme:

  • The x.y.z tag identifies a released and stable version of the image, produced from a GitHub repo tag. This is an immutable tag,
  • The latest tag identifies the latest released and stable version of the image. This is a mutable tag,
  • The nightly tag identifies the latest built - and maybe un-stable - version of the image. This is a mutable tag.

Microcks images repositories are primilarly located on Quay.io and synchronized to the Docker Hub.

Container images

Here is below the list of available container images. For more information on their role in the archutecture, you may check the Architecture & deployment options explanations.

Microcks App

The Microcks main web application (also called webapp) that holds the UI resources as well as API endpoints. It is produced from https://github.com/microcks/microcks/tree/master/webapp repo folder.

RepositoryPull commandAvailable tags
quay.io/microcks/microcksdocker pull quay.io/microcks/microcks:latest Quay.io
docker.io/microcks/microcksdocker pull microcks/microcks:latest Docker.io

Microcks Async Minion

The Microcks Async Minion (microcks-async-minion) is a component responsible for publishing mock messages corresponding to AsyncAPI definitions. It is produced from https://github.com/microcks/microcks/tree/master/minions/async repo folder.

RepositoryPull commandAvailable tags
quay.io/microcks/microcks-async-miniondocker pull quay.io/microcks/microcks-async-minion:latest Quay.io
docker.io/microcks/microcks-async-miniondocker pull microcks/microcks-async-minion:latest Docker.io

Microcks Postman runtime

The Microcks Postman runtime (microcks-postman-runtime) allows the execution of Postman Collection tests. It is produced from the https://github.com/microcks/microcks-postman-runtime repository.

RepositoryPull commandAvailable tags
quay.io/microcks/microcks-postman-runtimedocker pull quay.io/microcks/microcks-postman-runtime:latest Quay.io
docker.io/microcks/microcks-postman-runtimedocker pull microcks/microcks-postman-runtime:latest Docker.io

Microcks Uber

The Uber distribution is designed to support Inner Loop integration or Shift-Left scenarios to embed Microcks in your development workflow, on a laptop, within your unit tests easy. It is produced from https://github.com/microcks/microcks/tree/master/distro/uber repo folder.

The Uber distribution provide additional tags with -native suffix (xyz-native, latest-native and nightly-native) that allows pulling a GraalVM native packageg image with reduced image size and faster bootstrap time. However, some dynamic features like SCRIPT dispatcher are not available in this native flavour.

RepositoryPull commandAvailable tags
quay.io/microcks/microcks-uberdocker pull quay.io/microcks/microcks-uber:latest
docker pull quay.io/microcks/microcks-uber:latest-native
Quay.io
docker.io/microcks/microcks-uberdocker pull microcks/microcks-uber:latest
docker pull microcks/microcks-uber:latest-native
Docker.io

Microcks Uber Async Minion

The Microcks Uber Async Minion (microcks-uber-async-minion) is responsible for publishing mock messages corresponding to AsyncAPI definitions with Uber distribution. It is produced from https://github.com/microcks/microcks/tree/master/distro/uber-async repo folder.

RepositoryPull commandAvailable tags
quay.io/microcks/microcks-uber-async-miniondocker pull quay.io/microcks/microcks-uber-async-minion:latest Quay.io
docker.io/microcks/microcks-uber-async-miniondocker pull microcks/microcks-uber-async-minion:latest Docker.io

Microcks Operator

This container image is a Kubernetes Operator for installing and managing Microcks using Custom Resources. It is produced from the https://github.com/microcks/microcks-operator repository.

RepositoryPull commandAvailable tags
quay.io/microcks/microcks-operatordocker pull quay.io/microcks/microcks-operator:latest Quay.io
docker.io/microcks/microcks-operatordocker pull microcks/microcks-operator:latest Docker.io

Microcks CLI

This container image is a CLI used for interacting with a Microcks instance. It is produced from the https://github.com/microcks/microcks-cli repository.

RepositoryPull commandAvailable tags
quay.io/microcks/microcks-clidocker pull quay.io/microcks/microcks-cli:latest Quay.io
docker.io/microcks/microcks-clidocker pull microcks/microcks-operator:latest Docker.io

Software Supply Chain Security

Software supply chain security combines best practices from risk management and cybersecurity to help protect the software supply chain from potential vulnerabilities. We aim to provide the most comprehensive information about the software, the people who wrote them, and the sources they come from, like registries, GitHub repositories, codebases, or other open source projects. It also includes any vulnerabilities that may negatively impact software security – and that’s where software supply chain security comes in.

Vulnerabilities

All our container images are scanned for vulnerabilities with both Clair on Quay.io and Docker Scout on Docker Hub. Scanning reports are available for each image on every repository.

The container images base layers as well as the Microcks application dependencies are regularly updated as per the SECURITY-INSIGHTS.yml and DEPENDENCY_POLICY.md file you may find in each GitHub source repository.

Signatures

All our images are signed with Cosign and using the Sigstore framework. The signing is actually done from withing our GitHub Actions process using the GitHub OIDC token associated with the Actions process.

To verify the signature of a Microcks container image you just pulled, you first have to check the name of the Actions process - usually build-verify.yml - and the tag or branch from where it has been produced.

For example: you can verify the signature of the microcks:nightly image, built from the 1.11.x branch, using those commands:

IMAGE_WITH_DIGEST=`docker inspect --format='{{index .RepoDigests 0}}' quay.io/microcks/microcks:nightly`

cosign verify $IMAGE_WITH_DIGEST --certificate-identity https://github.com/microcks/microcks/.github/workflows/build-verify.yml@refs/heads/1.11.x --certificate-oidc-issuer https://token.actions.githubusercontent.com | jq .

that may produced following output:

// Verification for quay.io/microcks/microcks@sha256:7241f2c0bbd9f5ba72c2bc908e9ee035db40c4fcff61d7d75788ddb8df139e2c --
// The following checks were performed on each of these signatures:
//  - The cosign claims were validated
//  - Existence of the claims in the transparency log was verified offline
//  - The code-signing certificate was verified using trusted certificate authority certificates
[
  {
    "critical": {
      "identity": {
        "docker-reference": "quay.io/microcks/microcks"
      },
      "image": {
        "docker-manifest-digest": "sha256:7241f2c0bbd9f5ba72c2bc908e9ee035db40c4fcff61d7d75788ddb8df139e2c"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "1.3.6.1.4.1.57264.1.1": "https://token.actions.githubusercontent.com",
      "1.3.6.1.4.1.57264.1.2": "push",
      "1.3.6.1.4.1.57264.1.3": "edbe55f846f554d500ac3dc33c8346195e70f2ac",
      "1.3.6.1.4.1.57264.1.4": "build-verify-package",
      "1.3.6.1.4.1.57264.1.5": "microcks/microcks",
      "1.3.6.1.4.1.57264.1.6": "refs/heads/1.11.x",
      "Bundle": {
        "SignedEntryTimestamp": "MEQCIGOggaElAVzClnzPfl1gs3+ZgBwl22XC51YhbTdqu+f8AiAQ3Nfk/GXwIe2X7KSVwFubiuJfdVyPeZQQN0mhnHVkpA==",
        "Payload": {
          "body": "ey---REDACTED---0=",
          "integratedTime": 1733173324,
          "logIndex": 152950063,
          "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
        }
      },
      "Issuer": "https://token.actions.githubusercontent.com",
      "Subject": "https://github.com/microcks/microcks/.github/workflows/build-verify.yml@refs/heads/1.11.x",
      "githubWorkflowName": "build-verify-package",
      "githubWorkflowRef": "refs/heads/1.11.x",
      "githubWorkflowRepository": "microcks/microcks",
      "githubWorkflowSha": "edbe55f846f554d500ac3dc33c8346195e70f2ac",
      "githubWorkflowTrigger": "push"
    }
  }
]

You can then extract the logIndex and connect to Rekor to get some details on it. Here: https://search.sigstore.dev/?logIndex=152950063

Provenance

All our images are built with a SLSA Provenance attestation (currently in v0.2). This attestation is attached as a layer of a metadata manifest of the main image index.

As Microcks images are provided for linux/amd64 and linux/arm64 architectures, the 2 first manifests of an image index are reserved for these architectures. Then, starting at index 2 come the metadata manifests from where you can extract attestations that are formatted as in-toto predicates.

For example: you can extract the Provenance of the microcks:nightly image using those commands - using ORAS utility:

PROVENANCE_DIGEST=`docker manifest inspect --verbose quay.io/microcks/microcks:nightly | jq -r '.[2].OCIManifest.layers | map(select(.annotations."in-toto.io/predicate-type" == "https://slsa.dev/provenance/v0.2") | .digest)[0]'`

oras blob fetch --output - quay.io/microcks/microcks:nightly@$PROVENANCE_DIGEST | jq .

that may produced following output:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "pkg:docker/quay.io/microcks/microcks@nightly?platform=linux%2Famd64",
      "digest": {
        "sha256": "109c1a70123a64c824b32dfebaf0934b6d40db127af409ed07ae303966f1b412"
      }
    },
    {
      "name": "pkg:docker/microcks/microcks@nightly?platform=linux%2Famd64",
      "digest": {
        "sha256": "109c1a70123a64c824b32dfebaf0934b6d40db127af409ed07ae303966f1b412"
      }
    }
  ],
  "predicate": {
    "builder": {
      "id": ""
    },
    "buildType": "https://mobyproject.org/buildkit@v1",
    "materials": [
      {
        "uri": "pkg:docker/registry.access.redhat.com/ubi9/ubi-minimal@9.4-1227.1725849298?platform=linux%2Famd64",
        "digest": {
          "sha256": "1b6d711648229a1c987f39cfdfccaebe2bd92d0b5d8caa5dbaa5234a9278a0b2"
        }
      }
    ],
    "invocation": {
      "configSource": {
        "entryPoint": "Dockerfile"
      },
      "parameters": {
        "frontend": "dockerfile.v0",
        "locals": [
          {
            "name": "context"
          },
          {
            "name": "dockerfile"
          }
        ]
      },
      "environment": {
        "platform": "linux/amd64"
      }
    },
    "metadata": {
      "buildInvocationID": "hpnt5a6sztl5mxvhlp1n8hd1v",
      "buildStartedOn": "2024-12-03T13:14:59.450237594Z",
      "buildFinishedOn": "2024-12-03T13:15:52.403132277Z",
      "completeness": {
        "parameters": false,
        "environment": true,
        "materials": false
      },
      "reproducible": false,
      "https://mobyproject.org/buildkit@v1#metadata": {
        "vcs": {
          "localdir:context": "webapp",
          "localdir:dockerfile": "webapp/src/main/docker",
          "revision": "f3cfa7c2c741e6023bd2bef77a5b87278f01d540",
          "source": "https://github.com/microcks/microcks"
        }
      }
    }
  }
}

You can find in the attestation the GitHub source and revision, the base image used (ubi9/ubi-minimal@9.4-1227.1725849298) as well as the build metadata.

SBOM - Softwate Bill Of Materials

All our images are built with a SPDX SBOM attestation (currently in v2.3). This attestation is attached as a layer of a metadata manifest of the main image index.

As Microcks images are provided for linux/amd64 and linux/arm64 architectures, the 2 first manifests of an image index are reserved for these architectures. Then, starting at index 2 come the metadata manifests from where you can extract attestations that are formatted as in-toto predicates.

For example: you can extract the SBOM of the microcks-postman-runtime:nightly image using those commands - using ORAS utility:

SBOM_DIGEST=`docker manifest inspect --verbose quay.io/microcks/microcks-postman-runtime:nightly | jq -r '.[2].OCIManifest.layers | map(select(.annotations."in-toto.io/predicate-type" == "https://spdx.dev/Document") | .digest)[0]'`

oras blob fetch --output - quay.io/microcks/microcks-postman-runtime:nightly@$SBOM_DIGEST | jq .
{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://spdx.dev/Document",
  "subject": [
    {
      "name": "pkg:docker/quay.io/microcks/microcks-postman-runtime@nightly?platform=linux%2Famd64",
      "digest": {
        "sha256": "11c951599ed1bf649abbc2b23ae2730a4e1ef6ad9537a7f10df39b6546bf8429"
      }
    }
  ],
  "predicate": {
    "spdxVersion": "SPDX-2.3",
    "dataLicense": "CC0-1.0",
    "SPDXID": "SPDXRef-DOCUMENT",
    "name": "sbom",
    "documentNamespace": "https://anchore.com/syft/dir/sbom-250326c0-1ac9-45df-b956-7034af7e03f0",
    "creationInfo": {
      "licenseListVersion": "3.23",
      "creators": [
        "Organization: Anchore, Inc",
        "Tool: syft-v0.105.0",
        "Tool: buildkit-v0.17.2"
      ],
      "created": "2024-12-03T13:19:29Z"
    },
    "packages": [
      {
        "name": "@colors/colors",
        "SPDXID": "SPDXRef-Package-npm--colors-colors-0d3fee5f6cc0bed6",
        "versionInfo": "1.6.0",
        "supplier": "Person: DABH",
        "originator": "Person: DABH",
        "downloadLocation": "http://github.com/DABH/colors.js.git",
        "filesAnalyzed": false,
        "homepage": "https://github.com/DABH/colors.js",
        "sourceInfo": "acquired package info from installed node module manifest file: /app/node_modules/@colors/colors/package.json",
        "licenseConcluded": "NOASSERTION",
        "licenseDeclared": "MIT",
        "copyrightText": "NOASSERTION",
        "description": "get colors in your node.js console",
        "externalRefs": [
          // [...]
        ]
      },
      // [...]
    ]
  }
}

You can find in the attestation all the packages directly or transitively included into the container image.

Still Didn’t Find Your Answer?

Join our community and get the help you need. Engage with other members, ask questions, and share knowledge to resolve your queries and expand your understanding.

Join the community