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
SETUIDandSETGIDpermission bits — attackers can use these to escalate privileges. -
Remove shells and tools that attackers commonly exploit, such as
ncandcurl.
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
HIGHorCRITICAL, 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.
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