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).
Refer to the create container registry workflow.
Refer to the create registry token workflow.
Refer to the Docker Documentation and go to the Docker Registry HTTP API V2 documentation.
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.
All container registries are available on the public internet but cannot be accessed without a token with the correct rights.
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.
CVE stands for Common Vulnerability and Exposure Report, which lists disclosed information regarding security vulnerabilities in publicly released software.
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
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.
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.
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.
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.
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.
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?.
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.
The scanning of your container may still need to be completed. If your vulnerability report for an image has no Last Scan time, please check again later when scanning has been completed.
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.
Yes, vulnerability scanning is non-blocking, and your image may be pulled at any time.
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.
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.
No, container vulnerability scanning is a read-only operation. The content of your image remains unchanged.