安全责任共担模型 - 容器计算服务 ACS

容器计算服务 ACS（Container Compute Service）集群托管架构遵循责任共担原则，其中ACS负责管理Kubernetes集群控制组件和相关阿里云基础设施的安全性。本文介绍容器计算服务ACS的安全责任共担模型。

术语约定

文档内容将会不可避免地反复用到相同的名称、代码等，为了使文档内容简短、精要，所以在此对一些常用术语进行约定：

ACS作为典型的Serverless形式的平台，具备了资源全托管特性，需要明确阿里云和客户之间的安全责任边界，各自守好战场，一般安全责任划分的原则如下：

阿里云的责任是维护Serverless平台的安全性和可靠性，确保平台的基础设施安全、提供安全的数据存储和处理服务以及保护客户数据的机密性等。阿里云需要确保其基础架构、管理、安全实践的合规性，以保护客户的应用程序不受攻击，同时保护客户数据的隐私性和完整性。

客户负责确保其Serverless应用的安全性，涵盖应用程序本身的数据安全性和访问控制、代码编写和审计，以及有效的认证和授权措施等，并且只允许授权的个人或者团队进行访问，主要的原则有：

自身引入的安全风险需要负责：部署具有安全隐患的Pod或者授权面过大，影响了业务，需要客户自行负责。
主动申请开放容器特权需要负责：平台默认禁止开放对于容器稳定性和安全有较大影响的特性（例如Privileged和Capabilities等），但是客户可以通过主动申请流程进行开放，因此如果由于过大的特权导致稳定性和安全问题，例如横向攻击集群内其他Pod，需要客户自行负责。

由于平台某些资源无法做到单方面管理及使用，例如客户的Pod安全组，理想的状态由阿里云进行全托管。然而有一些客观需求，客户想要参与管理或希望该资源更受控，就需要更明晰的原则界定：

谁引入风险谁兜底原则：例如客户创建有安全隐患的Pod或使用被投毒的镜像等，引发故障需要客户自行负责；阿里云保证，ACS范围内的管控Pod，不会有安全隐患，不会影响客户业务。
各方保证最小权限原则：如果客户侧开放公网范围过大，那么从这个方向进来的攻击行为及后果，需要客户自行承担；阿里云保证，ACS范围内的Pod安全组，不会扩大访问范围，客户的应用运行不会逃逸出容器。

安全是一个全面的体系，要求阿里云和客户之间的安全责任层次分明，同时保持密切协作。阿里云承担基础设施安全与合规保障的责任，客户则需要确保其应用和数据安全。对于责任交叉的灰色区域，阿里云将采取主动策略，确保风险无死角，致力于为客户提供额外安全的Serverless服务支持。

在设计和部署企业应用系统前，您需要明确企业与阿里云各自的安全责任界限。选择阿里云ACS集群，除了管理基础设施，阿里云还会确保Pod的运行环境及相关运行时组件的安全。下图展示了在Serverless架构中使用ACS集群时，阿里云和客户之间安全责任的具体划分。

在管控面侧，阿里云会基于K8s安全基线等业界通用的安全标准，对ACS集群管控面组件进行安全加固，同时面向企业云原生应用生命周期中安全防护的典型场景，提供必要的安全体系概述。在此基础上，阿里云主要负责以下内容：

安全类型	详细内容
基础设施的安全性	K8s持续升级、CVE漏洞更新。 K8s管控链路隔离、网络隔离（如VPC配置，VPC间隧道等）、存储隔离等。
弹性计算资源池的安全性	针对容器OS，提供沙箱隔离技术。针对节点OS，及时提供相关公告并修复漏洞。
集群管控及托管组件的安全性	集群鉴权及证书管理、集群内Secret凭据管理、对外暴露端口、VPC隔离及安全组配置的合理性等。
非托管组件和应用市场Chart的安全性	提供标准核心配置，保障基本安全问题。

在数据面侧，客户的安全运维人员需要负责部署在云上的业务应用安全防护以及云上资源的安全配置和更新。在此基础上，客户主要负责以下内容：

安全类型	详细内容
应用的安全性	应用制品供应链、应用运行时安全。敏感数据涵盖Data in transit 及Data at rest并加密落盘。基于最小化原则进行账号和角色的授权。采用云安全中心的应用级安全防控以及时发现并解决潜在的安全隐患。采用最小权限的容器特权，尽量不主动申请开放。
运维的安全性	业务云网络配置、业务云存储配置、业务可观性配置。
业务组件的安全性	对于Operator、Webhook等的业务逻辑需要严格限制，以防止影响其他应用的安全。
非托管组件和应用市场Chart的安全性	及时应用阿里云公告中推荐的补丁更新。遵循安全原则来配置参数，避免因不恰当地设置或权限分配而给攻击者留下漏洞。