Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Each Container Registry has an option to configure the Garbage Collection schedule. By default, Garbage Collection is disabled because each customer should choose a schedule based on their needs.
Note: The container registry is read-only during the Garbage Collection to perform a complete analysis without changing the repositories.
Garbage Collection frees up storage space for layer data that are no longer referenced. It optimizes the volume of storage needed for each Container Registry and is necessary if all your artifacts use the same base operating system. Each layer can be referenced by more than one artifact. Hence, Garbage Collection ensures that other artifacts do not reference the layers before deletion.
The duration of the Garbage Collection will increase based on the volume of deleted repositories or tags and the total number of repositories and tags to be checked.
Note: Container Registries cannot immediately reduce storage usage when deleting artifacts or repositories.
Garbage Collection ensures the registry maintains data integrity while periodically cleaning up unused storage to optimize resource utilization.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry you want to configure.
3. Click > on the right of the Garbage Collection schedule in the Properties section.
4. Select the Day(s) and Time(UTC) to run the Garbage Collection on a weekly basis and click Update Schedule.
Note: You can configure it via the API for more granular and customized control over the Garbage Collection schedule.
Software development is constantly evolving, and security is a top priority. The Vulnerability Scanning feature is specifically designed to enhance the security of your containerized applications by proactively identifying potential vulnerabilities present in your artifacts. Scans take place every time an artifact is pushed to the registry and when new vulnerability definitions are published. This allows for quick detection of any security weaknesses in container dependencies and libraries, allowing you to react immediately to prevent exploitation.
Adopting the scanning feature is not just about maintaining security; it is also essential for complying with industry regulations, managing risks effectively, and sustaining the trust of your users. You can integrate the feature into your CI/CD pipeline, providing continuous security assessments to keep your containers safe in a fast-paced development environment.
We prioritize detected vulnerabilities based on severity, enabling you to focus on the most critical issues. Our recommendations for patch management, minimizing the attack surface, and using trusted base artifacts form part of a comprehensive security posture. By adopting the Vulnerability Scanning feature, you are taking a proactive approach to enable your team to safeguard your applications against emerging threats, ensuring the integrity of your software delivery.
For more information, see .
Note: Our price list provides comprehensive details about the costs associated with our various products and services. IONOS offers an enhanced add-on service, which operates on a pay-as-you-go model similar to our basic container registry. This means that the cost will scale according to your usage, providing you with the flexibility to control your expenses. For more information, see .
Note: While we strive to provide accurate and up-to-date vulnerability information, it's important to note that the scanning results are contingent on the contents of third-party, market-leading vulnerability database(s). IONOS is not responsible for any missing definitions or inaccuracies in the database.
1. To add Vulnerability Scanning to a Container Registry, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry you want to enable Vulnerability Scanning for.
3. Navigate to the Properties section and click on Enable in the Vulnerability Scanning area.
4. Confirm the action to enable Vulnerability Scanning.
Learn how to create a Container Registry using the DCD.
Create, update, and delete tokens that control access to your Container Registry.
Set up a Garbage Collection to release space when it is no longer in use.
Enable vulnerability scanning of the artifacts in your container registry to keep up with any CVEs found in your software supply chain.
Review the results of the vulnerability scans performed on the contents of your container registry.
Delete a repository that you no longer need.
Delete a registry that you no longer need.
Tokens manage access to your Container Registry effectively and efficiently. Tokens serve as secure authentication methods, eliminating the need for personal credentials to be used during Continuous Integration and Continuous Deployment (CI/CD) processes. Personal credential management can become cumbersome and impractical as your services and deployments expand. Tokens provide a scalable solution for access control.
In order to minimize the permissions given to each token, you can also use:
Scopes to limit token access as narrowly as possible to specific resources and the actions it is permitted to perform on those resources to enhance security during artifact deployment. Each token can link to an individual or service, simplifying the audit process and strengthening the ability to monitor registry activity.
Expiration dates to ensure that the permissions of tokens can be automatically revoked after a period of time.
Distinct tokens for each environment to ensure access appropriately aligns with each environment's requirements and your security policies.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to configure.
3. Click Add Token in the Tokens tab to create a new Token
4. Provide the following details:
Name: Enter a Name for the token. It is a user-visible name making it simple to recognize the token.
Notes:
It is not possible to change the token name later.
The registry name:
must contain only alphanumeric characters and dashes.
must be between 3 and 63 characters in length.
must begin with an character between a-z.
must end with an alphanumeric character.
Status: Turn on the toggle button to enable the status. The token can be disabled later.
Expiry Date: Select Expire on (minimum 1 hour) to enter an expiry date. Otherwise, select No expiry.
Note: The Expiry Date must be at least one hour in the future. When the Expiry Date is reached, the token is deleted, it is not disabled.
Scopes: Define all actions the token has permission to perform and on which repositories. Provide the following details:
Type: Select either of the following types:
Registry: Select it to create a token to get the list of repositories in the registry.
Repository: Select it to manage the contents of the repository(s).
Path: Enter the names of repositories to which the token will have access. *
can be used as a wildcard. *
will provide access to all repositories.
Action: Select the one or more of the following Action(s) for the token:
Admin: Select Admin if you want to allow the token to delete artifacts from the repository.
Push: Select Push if you want the token to push new artifacts to the repository. When choosing Push, you must also set the Pull action for the token.
Pull: Select Pull if you want this token to be able to pull artifacts from the repository.
Note: You can set a single scope when you add a token; however, further scopes can be added later at any time. For more information, see Adding scopes to a token.
5. Click Add Token.
Result: You will get the Docker Login command using the newly created token along with all the details of the newly created credential.
Note: You will only have access to this token's password at this time. We recommend that you save the token safely and securely because the password cannot be recovered.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to configure.
3. Select the Tokens tab.
4. Identify the token you want to edit and click on the â‹® on the right side of the table and select Edit.
5. Provide the updated information for the following fields:
Status
Expiry Date (if required)
6. Click Save
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to configure.
3. Navigate to the Tokens section.
4. Identify the token you want to edit and click on the â‹® on the right side of the table and select the Manage Scope option from the drop-down list.
5. Complete the following fields:
Type Select either of the following types:
Registry: Select it to create a token to get the list of repositories in the registry.
Repository: Select it to manage the contents of the repository(s).
Path: Enter the names of repositories to which the token will have access. *
can be used as a wildcard. *
will provide access to all repositories.
Action: Select the one or more of the following Action(s) for the token:
Admin: Select Admin if you want to allow the token to delete artifacts from the repository.
Push: Select Push if you want the token to push new artifacts to the repository. When choosing Push, you must also set the Pull action for the token.
Pull: Select Pull if you want this token to be able to pull artifacts from the repository.
6. Click Add Scope.
7. Repeat steps 5 and 6 for additional scopes.
8. Click X to close the window.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to configure.
3. Select the Tokens tab.
4. Identify the token you want to edit and click on the elipses on the right side of the table and select Manage Scope.
5. Identify the scope that is not required and click x Remove or used x Remove all.
6. Click X to close the window.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry from which you want to delete the token.
3. Select the Tokens tab.
4. Identify the token you want to delete and click on the elipses on the right side of the table and select x Delete.
5. Review and confirm that you wish to delete the token. This action is irreversible.
Note: The action of deleting a repository is not reversible.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to review.
3. Select the repository you want to delete and click â‹® on the right side of the table and select Delete.
4. Review and confirm that you wish to delete the repository.
The IONOS Cloud Container Registry service allows you to manage Docker and OCI compatible registries for use by your managed Kubernetes clusters. Use a container registry to make sure you have a private registry to effectively support pulling images.
Endpoint: https://api.ionos.com/containerregistries
To make authenticated requests to the API, you must include a few fields in the request headers. Please find relevant descriptions below:
We use curl
in our examples, as this tool is available on Windows 10, Linux and macOS. Please refer to our blogpost about curl
on Windows if you encounter any problems:
The IONOS Cloud Container Registry is a universal repository manager with a recommended service for storing and managing custom container images and other artifacts in IONOS Cloud. Deploying and pulling images can be done using the Docker CLI or added directly to a Kubernetes deployment.
The IONOS Cloud Container Registry provides users with a dedicated registry or multiple registries based on their contracts, allowing them to host their own Docker images without the need for an external provider (such as Docker Hub).
A container registry is created to store and share custom images in the same regions where you deploy them. Container Registry is a high-performance platform for storing custom image containers. It can be used as part of CI/CD workflows for container workloads.
You can order and manage the Container Registry through the API. The API will allow integration into the Data Center Designer (DCD).
The IONOS Cloud Container Registry allows you to manage compatible registries by offering the following:
An authenticated registry where OCI-compliant artifacts (including Docker container images) can be stored and retrieved.
Access via the Public Internet and secure by requiring authentication to view, push, or pull images. The Container Registry is maintained by IONOS Cloud on your behalf, which means that our experts will apply non-stop patches to the underlying infrastructure and Container Registry software.
All images stored in the container registry are encrypted at rest.
Each container registry can have many repositories.
The IONOS Cloud Container Registry specifications are as follows:
Our platform is responsible for providing the operations required to facilitate the distribution of images.
The container registry is accessible from the public internet and maximally available (High availability setup) for pushing and pulling artifacts.
The service is managed, including any components on which it is built.
It also supports authentication tokens for use by robot accounts to be able to integrate into an automated CI/CD pipeline. You can create a one-time token to allow the CI/CD pipeline to push a new image.
It is possible to use the same credentials to access all registries and repositories in the same IONOS Cloud account that the user has access to.
All data in the registry will be encrypted at rest.
The IONOS Cloud Container Registry is available in the FRA region.
The IONOS Container Registry offers the following benefits:
create a registry access token with limited or unlimited permissions
create a temporary registry access token with limited or unlimited permissions
support for docker tools
login to registry
push an image
pull an image
delete an image
Note: The network traffic is not charged.
There are the following few limitations when working with IONOS Container Registry APIs:
You cannot choose your encryption keys (Trust-No-One) when encrypting data at rest; the Container Registry platform manages the keys.
It is not possible to grant repository access permissions to push, pull, or delete from a specific repository.
Any unauthenticated user will not be able to access the registry contents.
Header | Required | Type | Description |
---|
Specification | Status |
---|
The container registry supports the , which allows it to be integrated into an automated CI/CD pipeline.
You can use the registry with compliant tools, e.g. .
For more information, see .
Authorization | yes | string | HTTP Basic authorization. A base64 encoded string of a username and password separated by a colon. |
X-Contract-Number | no | integer | Users with more than one contract may apply this header to indicate the applicable contract. |
Content-Type | yes | string | Set this to |
Docker Registry | Yes |
Built-in CI/CD | The container registry supports the Docker Registry HTTP v2 API, allowing it to be integrated into an automated CI/CD pipeline. |
Built-in OSS Vulnerability Scan | No |
Once you have fetched your required information, you can now create a new registry. For the registry, you can alter the days and time. You can also update the location based on the available container registry locations.
We assume the following prerequisites:
With the POST
request, you can create a container registry.
You can update the limit value to get specific registries based on the limit value being passed.
200 OK - Successfully showed the list of registries
Note:
Your values will differ from those in the sample code. The container registry will be created as shown in the 201 response. Your response will have a different id
, createdBy
and createdDate
.
Here, we do not get a hostname in the output because the host has not be allocated yet.
400 Bad Request - The request made is invalid or corrupted
Each Container Registry can provide a detailed detailed analysis of Common Vulnerabilities and Exposures (CVEs) that may be exploitable in your artifacts. For more information, see .
Vulnerability scan results provide detailed information about the security of your artifacts at different levels. The following sections provide more information.
When new vulnerabilities are identified, you may want to search your entire Container Registry to see if any of the artifacts are vulnerable. To do this, you will need the Common Vulnerabilities and Exposures (CVE) number. Every published vulnerability or security issue is assigned a unique CVE number.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to search, and click on the Vulnerability Search section.
3. Enter the full CVE number of the vulnerability you want to search for.
Result: A list of artifacts known to be vulnerable to the CVE are displayed.
To ensure that your artifacts, and the software supply chain they rely on, remain secure, you will need to review the results of the vulnerability scan periodically. The first step in this review process will be to see which repositories contain vulnerabilities.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to review.
Result: You will see a list of repositories in the registry. The VULNERABILITIES column shows you the highest severity vulnerability in the last artifact pushed to the repository.
Note: Depending on the content of your registry, there may be too many repositories to list on a single page. Remember to use the per page to set the number of repositories displayed per page and to navigate between pages using < and >.
You can review which artifacts in a specific repository are exposed to vulnerabilities. This approach will show you which artifacts have known fixes, as well as when that artifact was last pushed (that is, when updates have been made) and when they were last pulled, this often aligns with software being deployed to an environment.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to review.
3. Select the repository that you want to review.
Result: You can now see all artifacts in the repository listed by artifact and displaying the following:
the tag used when pushing the artifact to the repository.
the VULNERABILITIES column shows you the highest severity vulnerability in the artifact at the time of the LAST SCAN.
the LAST PUSH date and time.
the LAST PULL date and time.
Note: Depending on the content of your repository, there may be too many artifacts to list on a single page. Remember to use per page to set the number of artifacts displayed per page and to navigate between pages using < and >.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry that you want to review.
3. Select the repository that you want to review.
4. Select the artifact you want to view.
Result: You can now see a list of all known CVEs that the artifact is vulnerable to.
You can filter the list by SEVERITY.
You can filter the list to only show those vulnerabilities that are reported as FIXABLE.
Once you have all the information about the available locations, you can check out the name of existing registries. The name you choose should be available and must not be already in use.
Note:
Your chosen name must be available for the registry.
All registry names must be unique.
Make sure the name is suitable for use in the new registry: it only uses the characters "a-z", "0-9" or "-", starts with a letter and ends with a letter or number, and can be from 3 to 63 characters long and is accessible.
You can retrieve all the existing registries to check out the available names.
You can update the limit value to get specific registries.
Field | Type | Description | Example |
---|
200 OK - Successfully showed the list of registries
Note: Your values will differ from those in the sample code. Your response will have a different id
and existing registries
.
To create a container registry, you should be aware of available locations where you can create your container registry.
Note: The retrieved locations are read-only and cannot be changed.
200 OK - Successfully received the locations of a registry
Note:
Your values will differ from those in the sample code. Your response will have different locations
.
A location is identified by a combination of the following characters:
a two-character value in Id
represents a country (example: de
)
a three-character value in Id
represents a city. The locationId
is typically based on the IATA code of the city's airport (example: fra
).
Prerequisites: Make sure you have the appropriate permissions. Only contract administrators, owners, and users with the Manage Registry permission can create a Container Registry.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, click Add a Registry to start creating a new container registry.
3. Provide an appropriate Name.
Note:
It is not possible to change the registry name later.
The registry name:
must be globally unique across all customers.
must contain only alphanumeric characters and dashes.
must be between 3 and 63 characters in length.
must begin with an character between a-z.
must end with an alphanumeric character.
4. Choose the Location where you want your container registry to be run and the artifacts to be stored from the drop-down list.
Note: It is not possible to change the Location later.
5. Turn on the Vulnerability Scanning toggle so that your Container Registry is created with the vulnerability scanning enabled.
Note: We recommend that you create your Container Registry with Vulnerability Scanning enabled.
Vulnerability Scanning gives you the benefit of all artifacts being scanned for CVEs when pushed into a Container Registry and every time CVE databases are updated with newly identified CVEs. It is possible to add Vulnerability Scanning to a Container Registry. Once Vulnerability Scanning is enabled, it cannot be disabled later.
6. Click Add Registry. Your Container Registry and storage will be created.
Result: Your Container Registry is ready to use when its status is updated to Running.
Note: The action of deleting a registry is not reversible.
1. In the DCD, go to Menu > Containers > Container Registry.
2. In the Container Registry Manager, select the Container Registry you want to delete.
3. In the Properties section, select the Delete icon to delete your Container Registry.
4. Confirm the action by selecting Delete Registry.
You can get the information for a particular container registry. At this point, a hostname will be allocated to your registry. The registry hostname becomes a part of your image or your manifest or the repository name.
With the GET
request, you can fetch the registry information by ID. The registryId
must be provided. You can get it through .
Note: The sample requestID
is 789f8e3c-d5c8-4359-8f85-c200fb89e97c
Field | Type | Description | Example |
---|
200 OK - Successful operation
Note:
Your values will differ from those in the sample code. Your response will have a different id
and a hostname
.
400 Bad Request - The request made is invalid or corrupted
404 Not Found - The server did not find anything matching the request
Field | Type | Description | Example |
---|---|---|---|
Field | Type | Description | Example |
---|---|---|---|
When you have found a specific CVE, either by or by , you can see more details about the CVE by clicking on the CVE identification number. This will provide additional information about the vulnerability and may include references to third-party sites where additional information can be found.
Field | Type | Description | Example |
---|
Field | Type | Description | Example |
---|
Field | Type | Description | Example |
---|
Save the hostname in the reponse sample for using the .
days
array
The days of the week selected.
Monday
time
string
The timestamp of creation of the registry
19:30:00+00:00
location
string
The location of the resource.
de/fra
name
string
The name of the registry. It must be unique within the folder.
Demo
days
array
The days of the week selected.
Monday
apiSubnetAllowList
array
The list of IP subnets that can access the registry. If this parameter is omitted, the registry will be accessible from any IP address.
198.51.100.0/24
id
string
The ID of fetched output.
locations
type
string
The type of resource.
registry
createdBy
string
ID of the user or service account that initiated the operation.
sample@ionos.com
createdDate
string
The date when the operation was initiated.
h2022-10-07T14:30:06Z
days
array
The days of the week selected.
Sunday, Saturday
apiSubnetAllowList
array
The list of IP subnets, in CIDR notation, that can access the registry. For single IPs a /32
mask can be used. Addresses without a mask will be assumed to carry a /32
mask.
198.51.100.0/24
limit | number | The output value if specified in the request. |
|
id | string | The ID of the fetched output. |
|
type | string | The type of the resource that has been retrieved. |
|
href | URL (string) | URL to the object representation (absolute path). |
|
createdBy | string | The ID of the user or service account that initiated the operation. |
|
createdByUserId | string | The email ID of the user or service account that initiated the operation. |
|
location | string | The location of the resource. |
|
days | array | The days of the week selected. |
|
id | string | The id of the object that has been retrieved. |
|
type | string | The type of the resource that has been retrieved. |
|
ref | URL (string) | URL to the object representation (absolute path) |
|
items | array | The location of the container registry |
|
createdBy | string | The user who created the token. |
|
type | string | The type of resource. |
|
createdByUserId | string | The ID of the user or service account that initiated the operation. |
|
createdDate | string | The date when the operation was initiated. |
|
state | string | The status of the registry. |
|
hostname | string | The allocated hostname for the particular registry. |
|
apiSubnetAllowList | array | The list of IP subnets that can access the registry. |
|
limit | integer | The limit of the registries that have been retrieved | 5 |
registryId | string | The ID of the registry to return. This is required. |
|
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.
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.
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.
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.
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.
This section shows you how to create a registry token. We assume the following prerequisite:
In this guide, we used test named repository to create registry tokens. Therefore, it is important that the you know your container registry name.
With the POST
request, you get the registry token. You will need to provide registry ID:
Note: The sample requestID
is 789f8e3c-d5c8-4359-8f85-c200fb89e97c
200 OK - Successfully showed the list of registries
Note:
Your values will differ from those in the sample code. Your response will have a different id
for your token.
Save the username and password in the reponse sample for using the Docker commands.
409 - Conflict
If you want to push your local images to docker repository, you need to login to it using:
You need to enter the following options to login:
Hostname
Username
Password
For more information, refer to the the Docker Commands.
You can push the images to your registry by providing all required information. You can query registries and look at images manifest, discover tags, delete layers and delete manifest etc. In the Docker API calls:
You can use the name of registry
Authenticate the API calls with a token
To know more, explore the Docker Documentation. On the other hand, DCD uses an easy to opt passthrough feature which as discussed uses Basic Auth feature, so you dont need to use a separate authentication method for Data Center Designer (DCD).
To delete your token, the registryId
and tokenId
to be deleted must be provided.
You can get registryId through GET Registries API call and Create Registry Token.
Delete the information about the token using the following curl
command:
Note: The sample requestID
is 779f8e3c-d5c8-4359-8f85-c200fb89e97c and the sample tokenID
is 4b120b87-91ab-4ec2-8952-cc771a37bd08
Field | Type | Description | Example |
---|---|---|---|
204 - No Content
The action was successful and the response body is empty.
400 Bad Request - The request made is invalid or corrupted
404 Bad Request - Not Found
This way you can delete a particular token.
To delete your container registry, destroying all container image data stored in it. The registryId
must be provided. You can get it through GET Registries API call.
Delete the registry using the following curl
command:
Note: The sample requestID
is 789f8e3c-d5c8-4359-8f85-c200fb89e97c
Field | Type | Description | Example |
---|---|---|---|
204 - No Content
The request was successfully fulfilled and there is no content in the body.
404 Bad Request - Not Found
This way you can delete the registry completely.
Once you have created a repository using the Docker URIs and performed all operations you can delete the repository completely. Since Docker Registry V2 API does not allow to delete the entire repository, you can use IONOS Container Registry's API call for deleting the repository.
To delete your repository, the registryId and repository name for the repository to be deleted must be provided.
You can get registryId
through GET Registries API call.
Delete the repository using the following curl
command:
Note: The sample requestID
is a8fb592e4-494c-11ed-b878-0242ac120002 and the sample registry_name
is test
Field | Type | Description | Example |
---|---|---|---|
204 - No Content
The request was successfully fulfilled and there is no content in the body.
Field | Type | Description | Example |
---|---|---|---|
registryId
string
The ID of the registry to be deleted.
779f8e3c-d5c8-4359-8f85-c200fb89e97c
tokenId
string
TThe associated ID of the token to be deleted.
4b120b87-91ab-4ec2-8952-cc771a37bd08
registryId
string
The ID of the registry to be deleted. It is a required field.
789f8e3c-d5c8-4359-8f85-c200fb89e97c
registryId
string
The ID of the registry to return. This is required.
8fb592e4-494c-11ed-b878-0242ac120002
repository_name
string
The name of the registry. It must be unique within the folder.
test
id
string
The id of the created token.
8fb592e4-494c-11ed-b878-0242ac120002
createdBy
string
The user who created the token.
sample@sample.com
createdByUserId
string
The ID of the user or service account that initiated the operation.
8fb59000-494c-11ed-0242ac120002
state
string
The status of the registry.
Running
hostname
string
The allocated hostname for the particular registry.
demo.cr.de-fra.test.com