Securing Serverless Containers with Cloud Security Center: Architecture & Challenges

Background

Cloud providers and traditional security vendors have been developing security solutions for cloud environments for over a decade. Security has become a critical priority for enterprises and governments, and the capabilities of cloud security services have evolved accordingly.

Security Capabilities for Serverless Containers

Vulnerability Scanning : The Cloud Security Center (CSC) client AliSecureCheckAdvanced runs locally and executes proof‑of‑concept (POC) requests to verify the existence and impact of application vulnerabilities without performing malicious attacks.

Intrusion Detection : Kernel‑mode hooks monitor system calls, VFS functions and low‑level APIs. Memory snapshots are collected and analyzed to detect hidden or obfuscated rootkits.

Baseline Checks : Configuration checks cover the operating system, databases, software packages and container settings to harden the environment, reduce intrusion risk and satisfy compliance requirements.

Serverless Integration Architecture

Security Architecture

Serverless application management (deployment, traffic routing, operations) is combined with CSC security functions (vulnerability scanning, malicious file detection, security auditing, configuration risk detection). The architecture creates a deep‑defense layer for Serverless workloads.

Integration Workflow

Container assets are reported to the SAE control plane.

SAE synchronizes the asset metadata to CSC.

CSC agents on the host perform baseline, intrusion and vulnerability checks against the reported containers.

The results are fed back to SAE, completing a security closed‑loop for Serverless containers.

Key Technical Challenges

Multi‑Tenant Isolation

Each tenant receives an isolated security container, a dedicated VPC network interface and segregated asset reporting. This prevents cross‑tenant data leakage and ensures that security policies are applied per user.

Resource Consumption Impact

Two deployment models are supported:

Fixed resource pool : The CSC agent runs on the host and communicates with containers via Unix sockets.

Elastic resource pool : The CSC agent shares CPU and memory with business containers.

Stress‑testing covered CPU configurations of 1, 2, 4 and 8 cores, including CPU interference scenarios. A CPU‑intensive workload was run on a “main” container, keeping CPU utilization at 60‑90 %. Measurements showed no noticeable latency spikes or resource contention for the business containers.

Blast‑Radius Control

Version rollout must keep container node components and the CSC agent in sync across fixed and elastic pools. The rollout proceeds region‑by‑region with a 1:1 matching strategy and gray‑scale activation based on user UID. If incompatibilities are detected, the system can roll back to the previous component version, preserving stability for existing workloads.

Future Security Extensions

Beyond the current compliance‑oriented capabilities, the roadmap includes:

Web Application Firewall (WAF)

Transport‑level encryption for inter‑service communication

Operation audit logging

Fine‑grained permission control and least‑privilege IAM

Code‑security scanning, bastion host integration, and additional attack‑surface protections

These extensions aim to support regulated industries such as finance, government and healthcare.

References

What is Vulnerability Management – https://help.aliyun.com/zh/security-center/user-guide/overview-4

Detect Linux Rootkit Intrusion Threats – https://help.aliyun.com/zh/security-center/user-guide/detect-linux-rootkit-intrusions

Baseline Check – https://help.aliyun.com/zh/security-center/user-guide/baseline-check

Cloud Security Center product page – https://www.aliyun.com/product/sas