What is the IONOS Container Registry?

IONOS Cloud Container Registry is a managed service that provides users with a dedicated Docker registry or multiple registries as part of their contract. This enables them to host their own Docker images without the need for an external provider (such as Docker Hub).

How to create a Container Registry?

Refer to the create container registry workflow.

What are the main benefits of the IONOS Container Registry?

IONOS Container Registry is totally private and requires authentication to access it. It resides in the same infrastructure as your other IONOS Cloud infrastructure. Any unauthenticated user will not be able to access the registry contents. IONOS Container Registry software is always up-to-date and resilient. You don't need to use mK8s capacity to run and then manage your Container Registry.

Can I get admin credentials for the container registry?

Refer to the create registry token workflow.

How can I access the Docker Registry HTTP API V2?

Refer to the Docker Documentation and go to the Docker Registry HTTP API V2 documentation.

What are the limits for the IONOS Container Registry?

Following are a few limitations for the IONOS Container Registry:

  • You cannot choose your encryption keys (Trust-No-One) when encrypting data at rest; the Container Registry platform manages the keys.

  • An unauthenticated user will not be able to access the registry contents.

  • To have a registry, you need authentication and authorization, and the registry's contents must not be accessible to unauthenticated users.

Can repositories be public?

All container registries are available on the public internet but cannot be accessed without a token with the correct rights.

What is vulnerability scanning?

Vulnerability scanning is an add-on feature for your container registry that analyzes known software in your container images against known security vulnerabilities (or CVEs) that may put your infrastructure, applications or data at risk.

What is a CVE?

CVE stands for Common Vulnerability and Exposure Report, which lists disclosed information regarding security vulnerabilities in publicly released software.

How are vulnerabilities scored?

We review multiple sources of information for any given CVE. These sources may independently score the risk differently. Hence, we constantly expose the highest score reported by the sources.

The Common Vulnerability Scoring System (CVSS) is used for calculating the severity of a CVE based on many factors (base, temporal and environmental).

CVSS assessment produces a number between 0-10. With 10 being the most severe rating. A CVSS qualitative rating systems helps simplify CVE severity classification, as follows:

  • 0.0 None

  • 0.1 - 3.9 Low

  • 4.0 - 6.9 Medium

  • 7.0 - 8.9 High

  • 9.0 - 10.0 Critical

Does vulnerability scanning detect all vulnerabilities?

The threat landscape is ever-changing, and we cannot guarantee that all vulnerabilities are detected.

New CVEs are published constantly, existing CVEs may be revised over time, either increasing or decreasing in severity.

If an image in my registry reports no vulnerabilities, is it guaranteed to be immune to vulnerabilities?

The threat landscape is ever-changing. New vulnerabilities are identified in software constantly, but only when they are publicly published can they be detected in your images.

Vendors and security researchers may choose not to announce certain vulnerabilities and exploits when they are first identified. This is usually the case if the vulnerability is particularly easy to exploit and is of high consequence. This gives software vendors time to analyze and fix or mitigate the issue.

What is the meaning of fixable?

Sometimes, a CVE may show up in your reports as being fixable. It means that the affected software is vulnerable only in specific versions of a package; the vendor may have released an updated version that fixes the vulnerability, or there may be other mitigations that the software vendor suggests to limit or negate the vulnerability.

How do I fix a CVE?

The answer to this varies on a case-by-case basis (What is the meaning of fixable?. Upgrading to the latest version of a software package may resolve the issue. Review the CVE details for a specific vulnerability and recommendations, if available, to determine how to resolve the issue.

At certain times, there may be no fix or mitigation available. In these situations, analysis of the risk and awareness can assist with managing information security risks your business is exposed to.

How can I reduce my exposure to Vulnerabilities.

If I have unfixable CVEs, then what steps should I take to solve them?

While it is important to be aware of vulnerabilities in your software, it is not always immediately possible to resolve them. For more information, see How can I reduce my exposure to Vulnerabilities.

How can I tell if older images in my registry are susceptible to newly published CVEs?

The vulnerability scanning service monitors for changes in published CVE reports. Images held in your registry that have been pushed or pulled recently (in the past 30 days) are rescanned as new information on vulnerabilities becomes available.

This also means that your vulnerability reports will be updated to reflect criticality changes if a vulnerability is reclassified. For example, if a particular vulnerability is downgraded in severity from Critical to High, your reports will be updated to reflect this.

For more information, see How are vulnerabilities scored?.

Why do some of my images report "Unknown" for vulnerability status?

Not all containers and their packages can be scanned successfully. If your image shows a Last Scan time and Unknown vulnerability status, the scanning engines may be unable to process the image. We monitor for these situations and regularly review the scanning techniques to ensure these are kept to a minimum.

In some cases, an image may display an Unknown vulnerability status and lack a Last Scan time. This can occur when the repository name is less than two characters long or exceeds 255 characters. While it's technically allowed to name a repository with just a single character, such names don't fulfil the requirements of the scanning engine. To address this issue, push your image again using a repository name that falls within the range of 2 to 255 characters in length.

It is also possible that the scanning of your container may still need to be completed. If your vulnerability report for an image does not show the Last Scan time, check again later when the scanning is complete.

How long does vulnerability scanning take?

Typically, scanning an image takes only a few seconds, but this depends on many factors, such as the size of the image, the number of layers, and the number and types of packages installed.

Can I still pull my image whilst scanning is performed?

Yes, vulnerability scanning is non-blocking, and your image may be pulled at any time.

How can I reduce my exposure to Vulnerabilties?

Maintaining good container hygiene practices helps to reduce your exposure.

  • Ensure that your container build process updates OS system packages for your container.

  • Regularly rebuild and redeploy your container images

  • Reduce your surface area—Analyze your images and include only the software and libraries required for your application to function.

  • Change your base image—In some cases, switching to a different base image may help. Example: Alpine.

  • Consider distroless/scratch images for your bases.

  • Review your supply chain when using third-party dependencies.

Is curl-pipe-bash a safe installation method?

Lots of software installation guides recommend using curl-pipe-bash.

Example: curl https://source-reposotory.tld/install.sh | bash

We recommend that you avoid this method. You may review the install.sh script at the first build, but if a malicious actor can modify that script later, your container build could be compromised.

Does vulnerability scanning modify my image(s)?

No, container vulnerability scanning is a read-only operation. The content of your image remains unchanged.

Last updated