Container Service for Kubernetes:Supply chain security

Build minimal container images

Keep container images as small as possible to reduce the attack surface.

• Delete all binary files you don't need from the image. If the container image is downloaded from Docker Hub, you must use Dive to inspect each image layer and identify unnecessary files. After pushing the image to Container Registry, inspect layer content directly in the Container Registry console.

• Remove all binaries with the SETUID and SETGID permission bits — attackers can use these to escalate privileges.

• Remove shells and tools that attackers commonly exploit, such as nc and curl.

To find binaries with SETUID or SETGID bits:

find / -perm /6000 -type f -exec ls -ld {} \;

To strip those permission bits in your Dockerfile:

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Use multi-stage builds

Multi-stage builds let you use multiple FROM statements in a single Dockerfile, each starting a new build stage with a different base image. The final image contains only the artifacts needed to run the application — not the full build toolchain.

This reduces image size, limits the attack surface, and integrates naturally into CI/CD pipelines for automated continuous integration.

For a worked example, see Build an image for a Java application using a multi-stage Dockerfile.

Run containers as a non-root user

Avoid running containers as root. Add the USER instruction to your Dockerfiles to specify a non-root user. After the USER instruction, RUN, ENTRYPOINT, and CMD all execute under that user account. Apply the same setting in the PodSpec to enforce this at the pod level.

Download dependencies from trusted sources

Only use dependencies from trusted sources. For Alibaba Cloud-verified container images, artifacts, and packages, see Alibaba Cloud image repository.

To manage dependencies internally, use Apsara Devops Artifact Repository Packages — an enterprise-class private repository service that supports Maven, Gradle, and npm packages. It provides remote repository proxying, one-click migration, tenant isolation, permission control, and high-availability storage.

Restrict access with RAM policies

Use Resource Access Management (RAM) policies to limit which teams or users can access specific Container Registry instances, namespaces, or repositories. For example, cr:ListInstance* specifies all actions that start with cr:ListInstance. You can set the resource to the format acs:cr:*:*:repository/$instanceid/$namespace/* — for instance, acs:cr:cn-hangzhou:1234567:repository/cri-123456/ns/* grants the instance cri-123456 in the cn-hangzhou region, owned by account 1234567, permission to query all repositories in the ns namespace. The following policy grants read-only access to a specific namespace in a specific instance:

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cr:ListRepository",
                "cr:GetImageLayer",
                "cr:GetRepoTag"
            ],
            "Resource": "*"
        },
        {
            "Action": [
                "cr:List*"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:cr:cn-hangzhou:1234567:repository/cri-123456/ns/*"
            ]
        }
    ],
    "Version": "1"
}

For more information, see RAM authentication rules and Grant permissions to a RAM role for custom OSS buckets.

Use Container Registry Enterprise Edition in production

Container Registry Enterprise Edition provides artifact encryption, multi-dimensional vulnerability reports, fine-grained action auditing, and access control for container images and Helm charts.

For production environments:

• Set repositories to private.

• Access Container Registry over a virtual private cloud (VPC) using internal endpoints. Disable public internet access.

• Configure network access control lists (ACLs) to restrict inbound traffic.

For setup instructions, see Create a Container Registry Enterprise Edition instance.

Scan images for vulnerabilities

Container Registry automatically scans newly uploaded images and rescans all existing images every 24 hours.

• If an image contains vulnerabilities rated HIGH or CRITICAL, delete or rebuild it immediately.

• If vulnerable images are already deployed, replace the affected containers as soon as possible.

To enforce scanning before deployment, configure a Kubernetes validating webhook. You can invoke the validating webhook before you call the Kubernetes API to reject requests that do not comply with the admission policies defined in the webhook. You can call the CreateRepoTagScanTask operation of the Container Registry API to check whether a container image being pulled by a cluster contains critical vulnerabilities. If critical vulnerabilities are found, Container Registry blocks pod deployment from that image and generates an event listing the detected issues.

For API reference, see CreateRepoTagScanTask.

Sign images and verify signatures

Image signing prevents man-in-the-middle (MITM) attacks and unauthorized image updates or deployments, and ensures image integrity from distribution through deployment.

Container Registry Enterprise Edition supports automatic image signing. Container Registry can automatically sign images in specific namespaces. After an image is pushed to Container Registry, Container Registry signs it based on the matched signature signing rules. For signing instructions, see Sign container images.

Enforce signature verification with kritis-validation-hook

Install the kritis-validation-hook component in ACK clusters to automatically verify container image signatures at deploy time. The component is built on the open source Kritis project and can be deeply integrated with Container Registry and Key Management Service (KMS).

Only images that pass signature verification are allowed to run in the cluster. To exclude sidecar container images injected by third-party components from verification, add them to the signature verification whitelist.

For setup and configuration, see:

• Use kritis-validation-hook to automatically verify container image signatures

• Introduction to kritis-validation-hook

• What is KMS?

Use the cloud-native delivery chain

Container Registry provides a cloud-native delivery chain that covers image building, scanning, global synchronization, and distribution. The entire delivery chain is observable, traceable, and secured.

After you push an image, Container Registry automatically scans it and applies the configured security policies. Images that fail the severity threshold are blocked from distribution and deployment. Only images that are allowed by security policies are distributed and deployed.

Integrate the image scanning API into your own systems to schedule scans on demand. For setup, see Create a delivery chain.

Monitor runtimes with Security Center

Security Center detects and blocks threats in cloud-native application runtimes, securing each pod individually.

It automatically collects threat intelligence, traces attack origins, and responds to threats in real time. Specific capabilities include:

• Detecting malicious code or command execution, SQL injection, and data breaches

• Associating log data across sources to identify risk patterns in context

• Auditing actions and identifying risks from Kubernetes logs and operations logs

• Mitigating container escapes, AccessKey breaches, and unauthorized access across ACK and other orchestration platforms

For more information, see What is Security Center?