Container Image Security Scan
The CRS supports security scanning for all Linux-based container images, identifying all known vulnerabilities in the image and performing risk evaluations on them. This section introduces how to specify image editions for scanning and perform container image scanning for specific target namespaces, and how to obtain vulnerability information from the images.
Overview
On cloud-native platforms, container image security is a critical aspect of delivering secure cloud-native apps. To ensure the security of deployed services and prevent services from being maliciously attacked due to image vulnerabilities, the CRS offers a security scanning feature for images. You can initiate a scan from the Cloud Container Repository page. The duration of the security scan primarily depends on the size of the image. Under general circumstances, scanning an image can be completed within three minutes. The current image security scanning service is based on the open-source Trivy solution. The vulnerability information is sourced from the official vulnerability database and is regularly synchronized.
Procedure
1. Access the Cloud Container Repository console.
2. Click the name of the activated instance.
3. In the left navigation pane, select Container Image – Image Repository.
4. On the Image Repository page, click the target repository name to enter the Image Edition List page.
5. Click the Security Scan button on the right of the image edition you wish to scan.
6. After the scan is complete, you can view the scan results in the Vulnerability column.
7. Click the Image Edition Digest name to view detailed information about the vulnerabilities on the Image Details page.
Image Signing and Verification
Overview
The image signing feature ensures the source of the image is secure and trustworthy, preventing man-in-the-middle attacks and the updating or running of unauthorized images. CRS supports automatic signatures for images within namespaces. Every time a container image is pushed, it will match the signature rules and automatically sign, ensuring the content of your container image is trustworthy.
Image Signing Steps
The steps to set up automatic signing for images under a namespace are as follows:
1. Log in to the Cloud Container Repository console;
2. On the top menu bar, select the resource pool required.
3. On the instance page, select the container image repository instance.
4. On the left menu of the enterprise instance management page, select Image Distribution (which will be moved to Image Security) > Image Signature, then click the Create button in the upper left corner.
5. In the pop-up dialog, fill in the image signing rules, then click the OK button to complete the creation. The descriptions for each parameter on the interface are as below.
6. The created rule will be displayed in the Image Signature list. You can edit the signature rules, such as changing the signature key, etc.
Parameter | Description |
Namespace | Required. Select the namespace name that needs automatic signing |
Use the default private key | Whether to use the default private key when signing. If checked, it means the default private key is used for signing. If unchecked, a custom private key is required, and you need to enter the details of the custom private key below |
Private Key | If " Use the default private key " is unchecked, you must fill in this box with your custom private key. You can " paste your private key directly or import from a file ". The private key should be in PKC8 RSA format and its length should not exceed 2048 |
Password | If a password was added when creating the RSA key pair, it needs to be entered here; otherwise, it will affect the execution of the signing |
Note:
1. Image signing does not affect the regular use of the image, and certainly does not affect the inherent abilities and business functions within the image.
2. Only one signing rule can be created per namespace.
3. If you are using a custom key, the key pair needs to be properly maintained. Only the matching public key can verify the signature successfully
Image Signature Verification Steps
Image signature verification ( referred to as verification ) is mainly executed by the container image users. By installing a verification plug-in called " cube-sign " from the CCSE Plug-in Market, your cluster will have the ability to verify signatures. Only the images that have been signed by the private key corresponding to the provided public key can pass the verification.
Note:
• Before installing this plug-in, please first install cert-manager
• Be cautious when configuring the plug-in during installation, as improper configuration could affect the normal creation of other Pods in the cluster, thereby impacting the functionality of the cluster
During the installation of the verification plug-in, you need to provide relevant configuration information according to the actual situation for the verification to operate correctly and for the normal use of the cluster functions. The description of the configuration parameters is as follows
Parameter | Description | Default Value |
signconfig.useDefaultSignKey | Using the default signature | true |
signconfig.customSignKey | If the default signkey is used, you do not need to fill in the custom field. If the custom field is filled in, the public key will be encoded using base64 -w0 | "" (empty string) |
signconfig.ignoreList | Collection of trustlisted items to ignore during signature verification. See configuration example below | [] |
allowList: ## Trustlist namespaces only. Separate multiple namespaces with a comma ",". - namespaces: "default,dev" ## Trustlist images only. image names support exact matching and can use the asterisk (*) character for basic wildcard matching. Further details on wildcard matching follow - imagenamepattern: "nginx*" ## Trustlist image names under a namespace - namespaces: "grey" imagenamepattern: "busybox:1.28"
imagenamepattern Details
• When the configured value does not contain an asterisk (*) character, it will match the value exactly as configured. For example, nginx:v0.1.0 only matches nginx:v0.1.0.
• When using an asterisk (*) character for wildcard matching, the following restrictions apply:
• When the asterisk (*) is at the end, it matches any character except a forward slash (/). For example, a. com / nginx* matches a. com / nginx:v0.1.0, but does not match a. com / nginx/test:v0.1.0.
• When the asterisk ( * ) is not at the end, it matches letters, numbers, hyphens ( - ), and underscores ( _ ). For example, registry - vpc.cn-*.ctyun.com / pause:3.2 matches both registry - vpc.cn - hangzhou.ctyun.com / pause:3.2 and registry - vpc.cn - beijing.ctyun.com / pause:3.2.
Note: Specifically, all images under the kube-system namespace are not subject to signature verification. Similarly, when using other third-party open-source images, to bypass the signature verification process, these images need to be trustlisted during the installation of the signature verification plug-in
If the signature verification fails, the following event prompts can be observed in the container events of the Pod
Image Edition Unchangeable
Overview
The CRS supports the activation of the Image Edition Unchangeable feature. This ensures that the same edition of an image is only pushed once, effectively preventing edition overwriting issues due to operational errors. The feature is currently configurable at the namespace level, and you can customize the image repositories and editions for which you want to enable the Image Edition Unchangeable feature.
Procedure
Creating an Unchangeable Edition Rule
1. Access the Cloud Container Repository console.
2. Click the name of the activated instance.
3. In the left navigation pane, click Container Image - Edition Unchangeable.
4. Click the Add Rule button on the page.
5. Select a namespace, and fill in the repository and Tag where the rule will take effect. The matching rules for the repository and Tag are as follows:
Parameter | Description |
key | Exact match for the repository or Tag named "key" |
key* | Matches any repository or Tag with a prefix of "key" |
** | Matches all repositories or Tags |
{key1,key2,key3*} | Matches multiple repositories or Tags |
6. Click Confirm to complete the rule creation.
Managing Unchangeable Edition Rules
1. Access the Cloud Container Repository console.
2. Click the name of the activated instance.
3. In the left navigation pane, click Container Image - Edition Unchangeable to view the list of existing unchangeable edition rules.
4. Click the Edit button to modify the details of existing unchangeable edition rules.
5. Click the Disable button to deactivate existing unchangeable edition rules.
6. Click the Delete button to remove existing unchangeable edition rules.
Operation Audit
Overview
The Operation Audit page records the actions users have performed in the Cloud Container Repository console, allowing users a comprehensive understanding of operational behavior history.
Viewing Operation Audit Records
1. Access the Cloud Container Repository console.
2. Click on the name of the activated Enterprise Edition instance.
3. In the left navigation pane, click Instance Management - Operation Audit to view the operation audit records.
Operational Object Filter
1. The Operation Audit page allows you to filter by operation objects.
2. On the Operation Audit page, click the operational object filter box.
3. In the filter box, click on the operational object you need to filter.
4. The Operation Audit page will automatically filter the operation audit records of the selected operation objects.
Operational Time Filter
1. The Operation Audit page allows you to filter by operation time.
2. On the Operation Audit page, click the time filter box.
3. Select the desired time range in the filter box and click Confirm.
4. The Operation Audit page will automatically filter the audit records within the selected time range.
Keyword Filtering
1. The Operation Audit page allows you to filter operation audit records based on keywords.
2. Enter the desired keyword in the keyword input box located at the top right corner of the Operation Audit page.
3. Click the query button located next to the keyword input box to perform the filtering.
4. The Operational Auditing page will automatically filter the operation audit records containing the keyword. Keyword filtering criteria: At least one of the fields of audit record operation user, namespace name, repository name, operation behavior, and source IP contains the corresponding keyword.