All Products
Search
Document Center

Container Service for Kubernetes:Supply chain security

Last Updated:Jun 25, 2026

Software supply chain security protects software and its components during development, delivery, and use from malicious code, vulnerabilities, and other risks. This topic provides security recommendations for container images, registries, and workloads across the build, deploy, and runtime stages in ACK clusters.

Attack surface by stage

Stage Attack types
Build IDE tool pollution, third-party library vulnerabilities and web shells, source code pollution
Deploy Substitution and tampering of stored data, data transmission hijacking, drive-by download attacks
Runtime Software update hijacking, runtime vulnerabilities and web shells, zero-day vulnerabilities in third-party libraries

A compromised container image can lead to container escapes, host takeover, and lateral movement to sensitive data. Kubernetes admission control verifies pod security at deploy time, and continuous runtime monitoring enables rapid threat response.

Build stage

Build minimal container images

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

  • Remove unnecessary binaries from images. Use Dive to inspect Docker Hub image layers, or check layer content in the Container Registry console after pushing.

  • 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 use multiple FROM statements in a Dockerfile. The final image contains only the application artifacts, not the build toolchain.

This reduces image size and attack surface, and integrates into CI/CD pipelines.

See Build an image for a Java application using a multi-stage Dockerfile.

Run containers as a non-root user

Add the USER instruction to Dockerfiles. After USER, RUN, ENTRYPOINT, and CMD execute under that user. Apply the same setting in the PodSpec.

Download dependencies from trusted sources

Download verified container images, artifacts, and packages from the Alibaba Cloud image repository.

For internal dependency management, use Apsara DevOps Artifact Repository Packages — a private repository supporting Maven, Gradle, and npm packages with remote proxying, one-click migration, tenant isolation, permission control, and high-availability storage.

Registry stage

Restrict access with RAM policies

Use Resource Access Management (RAM) policies to restrict access to specific Container Registry instances, namespaces, or repositories. For example, cr:ListInstance* matches all actions starting with cr:ListInstance. Set the resource to acs:cr:*:*:repository/$instanceid/$namespace/* — for example, acs:cr:cn-hangzhou:1234567:repository/cri-123456/ns/* grants instance cri-123456 in cn-hangzhou, owned by account 1234567, query access to all repositories in namespace ns. The following policy grants read-only access to a 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"
}

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.

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 that rejects requests violating admission policies. Call CreateRepoTagScanTask to check whether images being pulled contain critical vulnerabilities. If found, Container Registry blocks pod deployment and generates an event listing the issues.

See CreateRepoTagScanTask.

Sign images and verify signatures

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

Container Registry Enterprise Edition supports automatic signing in specific namespaces. After a push, Container Registry signs the image based on matched signing rules. See Sign container images.

Deploy stage

Enforce signature verification with kritis-validation-hook

Install kritis-validation-hook in ACK clusters to verify container image signatures at deploy time. Built on the open-source Kritis project, it integrates with Container Registry and Key Management Service (KMS).

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

See:

Use the cloud-native delivery chain

Container Registry provides a cloud-native delivery chain covering image building, scanning, global synchronization, and distribution — observable, traceable, and secured.

After you push an image, Container Registry scans it and applies configured security policies. Images exceeding the severity threshold are blocked from distribution and deployment.

Integrate the image scanning API into your systems to schedule scans on demand. See Create a delivery chain.

Runtime stage

Monitor runtimes with Security Center

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

It automatically collects threat intelligence, traces attack origins, and responds in real time. 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

See What is Security Center?

References