Overview
Overview
Welcome to Baidu AI Cloud's product, the Cloud Container Registry (CCR) Enterprise Edition. The CCR Enterprise Edition currently provides the following features:
-
Management of CCR Enterprise Edition instance
Enterprise Edition instance management, allowing you to manage existing CCR Enterprise Edition instances, including querying instance information, renaming instances, updating tags, and more.
-
Namespace management
Facilitates the management and isolation of image and Helm chart registries aligned with specific affiliations. Namespaces do not directly store cloud-native artifact data but can be mapped to internal organizational departments or enterprise product projects. Combined with permission management, this enables different users to access or operate data within designated namespaces.
-
Management of container image registry
Manages Docker images and other OCI artifacts. The image registry lets you manage various versions of container images. Registries belong to namespaces and inherit attributes like access type and vulnerability scan triggers from those namespaces.
-
Container image management
This feature manages Docker images and other OCI artifacts, supports managing different versions of container images, and includes a vulnerability scanning function to meet container image security requirements.
-
Management of Helm charts
Supports chart uploads and downloads via the console or Helm tool. This functionality allows for efficient and convenient hosting and distributing of various resources within Kubernetes clusters.
-
Container image trigger (Webhook)
Set appropriate triggers within the instance to automatically execute custom POST requests when specific triggering actions occur.
-
Container image on-demand loading
Supports configuring instances and flexibly using image acceleration rules to generate acceleration versions automatically. By deploying relevant components with the Cloud Container Engine (CCE) K8S Cluster, users can pull accelerated image versions during container deployment, eliminating full downloads and online decompression of container data, thus significantly enhancing container startup efficiency.
-
Access credentials
When pushing or pulling container images with the Docker client, you must log into the instance using access credentials. Run the Docker login command in the client and provide your username and password. The CCR Enterprise Edition supports both fixed and temporary login passwords.
-
Access control
The Cloud Container Registry Enterprise Edition offers network access control capabilities. By default, Enterprise Edition instances block all external access to ensure the security of your container images, Helm charts, and other OCI-compliant artifacts. You must configure public network or Virtual Private Cloud access control policies to access the instance via either method.
-
Container image migration
Supports migrating images from external registries to Enterprise Edition instances, facilitating cloud business migration. It also enables migrating container image data from Personal Edition to Enterprise Edition.
-
Cross-instance image synchronization
Supports copying container images and Helm charts from one instance to others across regions by configuring synchronization rules. It enables single-point pushes with automatic synchronization and distribution across multiple regions, helping enterprise users rapidly deploy and update container services globally.
The APIs provided in this document can be used to flexibly manage CCR Enterprise Edition services.
API overview
The CCR enterprise edition APIs cover the following types:
| API type | Description |
|---|---|
| [Enterprise Edition Instance APIs](CCR/Enterprise Edition API Reference/Enterprise Edition Instance APIs.md) | CCR Enterprise Edition instance management-related function APIs |
| [Namespace APIs](CCR/Enterprise Edition API Reference/Namespace APIs.md) | Namespace management-related function APIs |
| [Image Registry APIs](CCR/Enterprise Edition API Reference/Image Registry APIs.md) | Image registry management-related APIs |
| [Image APIs](CCR/Enterprise Edition API Reference/Image API.md) | Image creation, deletion, listing, and scanning-related APIs |
| [HelmChart APIs](CCR/Enterprise Edition API Reference/Helm Chart Management Interface.md) | Helm charts management related APIs |
| [Trigger APIs](CCR/Enterprise Edition API Reference/Trigger APIs.md) | Container image trigger management-related APIs |
| [Image On-demand Loading APIs ](CCR/Enterprise Edition API Reference/Image On-demand Loading APIs.md) | Image on-demand loading-related APIs |
| [Image Access Credential APIs](CCR/Enterprise Edition API Reference/Image Access Credential APIs.md) | Image access credential-related APIs |
| [Image access control APIs](CCR/Enterprise Edition API Reference/Image access control APIs.md) | Image access control-related APIs |
| [Image Migration APIs](CCR/Enterprise Edition API Reference/Image Migration APIs.md) | Image migration-related APIs |
| [Image Synchronization APIs](CCR/Enterprise Edition API Reference/Image Synchronization APIs.md) | Image synchronization-related APIs |
API authentication mechanism
The Access Key and request signature mechanism are uniformly adopted for all API security authentication. Access Key consists of an Access Key ID and a Secret Access Key, both of which are strings. For each HTTP request, use the algorithm described below to generate a authentication string. Submit the certification string in the Authorization header. The server verifies the correctness of the authentication string based on the generation algorithm. The certification string format is bce-auth-v{version}/{accessKeyId}/{timestamp}/{expirationPeriodInSeconds}/{signedHeaders}/{signature}.
- The version is a positive integer.
- The timestamp refers to the UTC time when the signature is created.
- The expirationPeriodInSeconds specifies the duration during which the signature remains valid.
- SignedHeaders includes the list of headers involved in the signature algorithm. The headers are separated by semicolons (e.g., host;x-bce-date) and arranged in lexicographical order. (This API signature involves only the host and x-bce-date headers.)
- The signature is a 256-bit signature represented as a 64-character lowercase hexadecimal digest.
When Baidu AI Cloud receives a user's request, the system uses the same SK and certification mechanism to generate a certification string. This string is then compared with the one included in the user's request. If the two match, the system confirms the user has the required permissions and proceeds with the operation. If they differ, the system cancels the operation and returns an error code.
For detailed information on the authentication mechanism, please refer to Authentication Mechanism.
Request structure description
The data exchange format is JSON, and all request and response body content is encoded in UTF-8.
Request parameters include the following 4 types:
| Parameter type | Description |
|---|---|
| URI | It is usually used to specify the operation entity, such as: POST /v{version}/instance/{instanceId} |
| Query | Request parameters included in the URL, typically specifying the action to be performed on an entity |
| HEADER | It is passed in through HTTP header, such as: x-bce-date |
| RequestBody | Request data body organized in JSON format |
Response structure description
Response values are in two forms:
| Response content | Description |
|---|---|
| HTTP STATUS CODE | Such as 200, 400, 403, 404, etc. |
| ResponseBody | Response data body organized in JSON format. |
Date and time regulations
There are multiple ways to represent date and time. For uniformity, unless it is conventional or there are corresponding specifications, UTC time shall be used wherever date and time need to be expressed, following ISO 8601, with the following constraints:
- Date shall be expressed in the format of
YYYY-MM-DD. For example,2014-06-01represents June 1, 2014. - Time shall be expressed in the
hh:mm:ss+ capital letter Z format, and capital letter Z indicates UTC time. For example,23:00:10Zrepresents 23:00:10 UTC. - When involving date and time, insert an uppercase letter T between them. For example,
2014-06-01T23:00:10Zrepresents 23:00:10 UTC on June 1, 2014.
Normalized string
A string can usually contain any Unicode character. This flexibility can cause many troubles in programming. Therefore, the concept of “normalized string” is introduced. A normalized string contains only percent-encoded characters and URI (Uniform Resource Identifier) unreserved characters. RFC 3986 stipulates that URI unreserved characters include the following: letters (A-Z, a-z), numbers (0-9), hyphens (-), dots (.), underscores (_), and tildes (~).
The way to convert any string into a normalized string is:
- Convert the string into a UTF-8 encoded byte stream.
- Leave all unreserved URI characters unchanged.
- Perform percent-encoding as described in RFC 3986 for the remaining bytes. Use a % symbol followed by two uppercase hexadecimal characters representing the byte value.
Example:
Original string: this is an example for testing,
Corresponding normalized string: this%20is%20an%20example%20for%20%E6%B5%8B%E8%AF%95.
