作者|阿里云容器安全专家，徐越（乐枕）
责编|屠敏
出品|CSDN（ID：CSDNnews）
容器化带来的安全隐患
过去的2019年是企业容器化爆发的一年。据统计已经有超过90%的互联网企业正在部署或使用容器，希望能通过更为敏捷的方式快速响应市场需求。
云上容器攻击矩阵概览
ATT＆CK®框架（ReferenceATTACKMatrixforContaineronCloud）是网络攻击中涉及的已知策略和技术的知识库。为便于企业构建容器化应用安全体系，阿里云在传统主机安全的基础上，围绕自建容器集群以及云原生容器服务场景，通过全面分析黑客攻击Docker和K8s的过程和手段，推出容器安全ATTCK矩阵，让黑客无所遁形，助力企业全面提升容器安全能力水位。
云上容器ATTCK矩阵详解
1.InitialAccess/初始访问
1.1云账号AK泄露
1.2使用恶意镜像
部分容器开发者会使用公开的镜像源(如dockerhub)下载镜像并在业务环境中运行，但如果不慎使用了存在漏洞的镜像，会给业务带来安全风险。此外，攻击者时常会将恶意镜像部署到dockerhub，并通过诱导安装或链路劫持对企业进行供应链攻击。
示例：一个在Dockerhub中伪装成mysql的恶意镜像，同时携带了挖矿程序：
1.3K8sAPIServer未授权访问
K8sAPIServer作为K8s集群的管理入口，通常使用8080和6443端口，其中8080端口无需认证，6443端口需要认证且有TLS保护。
如果开发者使用8080端口，并将其暴露在公网上，攻击者就可以通过该端口API，直接对集群下发指令，或访问/ui进入K8s集群管理dashboard，操作K8s实施破坏。
1.4K8sconfigfile泄露
K8sconfigfile作为k8s集群的管理凭证，其中包含有关K8s集群的详细信息，包括它们APIServer的地址和登录凭证。在购买托管容器服务时，云厂商会向用户提供该文件以便于用户可以通过kubectl对集群进行管理。如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过APIServer接管K8s集群，带来风险隐患。
示例：阿里云容器服务K8sconfigfile：
1.5Dockerdaemon公网暴露
Docker以client-server模式工作，其中dockerdaemon服务在后台运行，负责管理容器的创建、运行和停止操作，并提供docker许多其他运行时功能。执行docker命令会调用一个客户端，该客户端通过Docker的RESTAPI将命令发送到服务端(dockerdaemon)。
在Linux主机上，dockerdaemon监听它在/var/run/中创建的unixsocket。为了使dockerdaemon可管理，可以通过配置TCPsocket将其暴露在网络中，一般情况下2375端口用于未认证的HTTP通信，2376用于可信的HTTPS通信。
如果管理员测试业务时配置不当导致通过2375暴露在公网，攻击者即可通过该API接管docker服务。
示例：Dockerdaemon的2375端口的暴露：
dockerdaemon-Htcp://0.0.0.0:2375-Hunix:///var/run/
1.6容器内应用漏洞入侵
同主机安全一样，容器中运行的应用侧漏洞（如WEB应用RCE漏洞、Redis未授权访问等）也会成为黑客的突破口，攻击者可以利用这些漏洞进入容器内部并发起进一步攻击。
1.7Master节点SSH登录凭证泄露
常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。在此情况下，前置节点的SSH凭证泄露或被攻破也会使K8s集群暴露在风险中。
1.8私有镜像库暴露
在容器化应用场景中，公司使用镜像来进行持续集成和自动化部署，这些镜像往往通过专用的私有镜像库来管理。暴露在公网的私有镜像库极有可能遭受攻击者入侵，并通过劫持供应链来渗透下游业务。
2.Execution/执行
2.1通过kubectl进入容器
Kubectl是一个管理k8s集群的命令行工具，kubectl在$HOME/.kube目录中寻找一个名为config的文件并连接APIServer进行鉴权操作。攻击者可以通过kubectlexec指令在任意pod内部执行命令。
示例：kubectlexec进入pod内部执行指令：
xy@x-8~/D/t/K8s_demokubectlgetpod
NAMEREADYSTATUSRESTARTSAGE
app-1-wp-01/1Running0182d
app-1-wp-11/1Running0182d
myapp1/1Running011d
myappnew1/1Running011d
xy@x-8~/D/t/K8s_demokubectlexec-itmyappnew/bin/bash
root@myappnew:/cd/mnt
root@myappnew:/mnt以下命令相当于kubectlgetno
curl-s"Authorization:pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tOGprZmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2DydmljZS1hY2NvdW50LnVpZCI6Ijg4Y2ZmNmYzLWY0NzktMTFlOS1iZmY1LTJlYzU3MmZlMWRjOCI__vAO1XJWUw9fvNNI2e4LxHypkpzREmnqrK9UZ-rrp9tG8Vxbc65FlPFj9efdpfWYExxjDDQwQTi-5Afmk4EA6EH-4vEs4V1r4gb0za8cyPVSAjzmEh7uIMgQHVo7y32V_BqUd8cmBoTdgnTY8Nx2QvMClvoYvEWvDKhbMnQjWH1x5Z6jK0iNg7btlK_WXnz8-yU2a0-jgoZFZ8D_qX16mZJ_ZoxEwPNTeNR8pP1l3ebZGVqBQA1PIFVG4HOlYomZya_DWGleMRYpulnECtBOTYyswzCwN8qJUVsdv6yWH1blWHKzYrkcoDmp2r6QhekaG1KFoX_YA"--
2.5带有SSH服务的容器
含有SSH服务的容器暴露了新的攻击面，由于暴力破解或者登录凭证泄露，攻击者可以进入到容器内部执行指令进行恶意操作。这种情况多见于自建容器或K8s环境(一些运维人员将容器当做VM使用)。此外当攻击者逃逸到node节点时可以通过添加账号或写入/.ssh/authorized_keys等方式利用SSH下发后续恶意指令。
2.6通过云厂商CloudShell下发指令
针对VM和容器服务的管理，云服务商往往会提供沙箱化的便捷管理工具，在云账号凭证泄露的情况下，攻击者可以通过云厂商提供的API接管集群。此外云厂商沙箱本身的安全问题也会影响到用户集群安全。
示例：通过CloudShell管理集群：
3.Persistence/持久化
3.1部署远控客户端
（参考2.3部分通过K8s控制器部署后门容器）攻击者通过K8sDaemonSet向每个Node中植入后门容器，这些容器可以设置为特权容器并通过挂载宿主机的文件空间来进一步向每个Node植入二进制并远控客户端，从而完成Node层持久化，且后续操作不会触发K8s层的审计策略。
3.2通过挂载目录向宿主机写入文件
一种常见的容器逃逸方法，如果容器/Pod启动时将VM的核心目录以写权限挂载(如/root,/proc,/etc等)，则攻击者进入容器后可以修改敏感文件进行逃逸，如利用/etc/crontab执行定时任务、修改/root/.ssh/authorized_keys获取SSH登录权限、读取其他进程空间内容等。
示例：不安全的目录挂载：
dockerrun-it-v/root:/rootubuntu/bin/bash
写入SSH凭证
(echo-e"\n\n";catid_rsa_)/root/.ssh/authorized_keys
3.3K8scronjob持久化
Cronjob是K8scontroller的一种，用于创建基于时间的调度任务(类似主机的/etc/crontab)。攻击者在获取controllercreate权限后可以创建cronjob实现持久化。
示例：cronjob持久化
xy@x-8~/D/
apiVersion:batch/v1beta1
kind:CronJob
metadata:
name:echotest
spec:
schedule:"*/1****"
jobTemplate:
spec:
template:
spec:
containers:
-name:container
image:nginx
args:
-/bin/sh
--c
-echotest
restartPolicy:OnFailure
xy@x-8~/D/
/echotestcreated
xy@x-8~/D/testkubectlgetcronjobs
NAMESCHEDULESUSPENDACTIVELASTSCHEDULEAGE
echotest*/1****False326s3m8s
3.4在私有镜像库的镜像中植入后门
（参考1.8私有镜像库暴露）攻击者在接管企业私有镜像库之后，可以进行拉取私有镜像窃取信息、删除仓库中的镜像、替换仓库中的镜像、为已有镜像添加后门、在镜像服务中创建后门账号等恶意操作。
一种持久化攻击方式是在dockerfile中加入额外的恶意指令层来执行恶意代码，同时该方法可以自动化并具有通用性。同时在Docker镜像的分层存储中，每一层的变化都将以文件的形式保留在image内部，一种更为隐蔽的持久化方式是直接编辑原始镜像的文件层，将镜像中原始的可执行文件或链接库文件替换为精心构造的后门文件之后再次打包成新的镜像，从而实现在正常情况下无行为，仅在特定场景下触发的持久化工具。
3.5修改核心组件访问权限
攻击者通过ConfigMap修改Kubelet使其关闭认证并允许匿名访问，或暴露APIServer的未授权HTTP接口，使其在后续渗透过程中拥有持续的后门命令通道。
4.PrivilegeEscalation/权限提升
4.1利用特权容器逃逸
Docker允许特权容器访问宿主机上的所有设备，同时修改AppArmor或SELinux的配置，使特权容器拥有与那些直接运行在宿主机上的进程几乎相同的访问权限。在这种情况下，攻击者从特权容器逃逸是极其容易实现的。
示例：将系统盘挂载到容器内部，读写宿主机文件：
root@d000b330717d:/mkdir/mnt1
root@d000b330717d:/cd/mnt1
root@d000b330717d:/mnt1curl--insecure
Unauthorized
7.3Cluster内网扫描
黑客通常会对Node、Pod、Service三个网段进行主机存活探测和端口扫描，然后从K8s内置服务、用户应用、第三方K8s插件等角度寻找更多攻击面，同时会通过找到NodeIP并访问KubeletAPI获取pod的详细拓扑信息。
阿里云容器服务默认CIDR：
7.4访问K8sDashboard所在的Pod
KubernetesDashboard为用户提供WEB界面，便于创建、修改和管理Kubernetes资源(如Deployment，Job，DaemonSet等)。Dashboard的部署取决于云厂商和用户自身的配置，在官方的部署流程中，dashboard会创建独立的Namespace、Service、Role以及ServiceAccount。
示例：阿里云容器服务提供的dashboard：
由于K8spod之间默认允许通信，攻击者在进入某个pod之后，可以通过信息收集或内网扫描的方式发现K8sdashboard所在service地址，并通过kubernetes-dashboardserviceaccount进行认证操作。
7.5访问私有镜像库
参考1.8和3.4关于私有镜像库的攻击面，攻击者可以在K8ssecret或本地配置文件中找到私有镜像库的连接方式，并在权限允许的情况下劫持私有镜像库中的镜像，实现横向移动和持久化。
7.6访问云厂商服务接口
（参考6.2云产品AK泄漏）在云原生的容器化应用中，服务往往会与多种内外部API进行交互，攻击者可以通过收集这些API的登录凭据或测试是否存在未授权访问来进行攻击准备。
此外，在某些云服务商提供的CaaS或Serverless容器中，为便于使用者与底层云基础设施进行通信，厂商通过植入专用pod或者将API挂载到业务pod的方式提供额外的接口，这些接口也会成为攻击者收集信息过程中的突破口。
7.7通过NodePort访问Service
K8sservice的暴露方式由三种：ClusterIP，NodePort和LoadBalancer。其中LoadBalancer多与云厂商的负载均衡类产品集成，具有较强的流量审计能力。
一些业务场景中存在着K8s与VM并存的内网环境，当攻击者通过非容器化的弱点进入内网时，可以借助NodePort进行横向移动。在频繁迭代的业务中，使用NodePort的服务相比ClusterIP更加固定，可用做控制通道来穿透网络边界管控以及防火墙的限制。
默认情况下，K8s集群NodePort分配的端口范围为：30000-32767。
8.LateralMovement/横向移动
8.1窃取凭证攻击云服务
（参考6.2云产品AK泄漏）攻击者利用容器内部文件或K8ssecret中窃取到的云服务通信凭证进行横向移动。
8.2窃取凭证攻击其他应用
参考第6节的各项内容。在基础设施高度容器化的场景中，绝大部分服务都是API化的，这使凭证窃取成为扩展攻击面、获取目标数据的重要手段。K8s集群、云产品以及自建应用的通信凭证都是攻击者窃取的目标。
8.3通过ServiceAccount访问K8sAPI
（参考2.4利用ServiceAccount连接APIServer执行指令）攻击者在容器内部可通过ServiceAccount访问K8sAPI刺探当前pod用户权限，并在权限允许的前提下对API下发指令或利用K8s提权漏洞访问集群中的其他资源。
8.4Cluster内网渗透
一般情况下，K8s会默认允许Cluster内部的pod与service之间直接通信，这构成了一个"大内网"环境。攻击者在突破一个pod之后，可以通过内网扫描收集服务信息并通过应用漏洞、弱口令以及未授权访问等方式渗透Cluster的其他资源。K8s支持通过自带的网络策略(NetworkPolicy)来定义pod的通信规则，一些网络侧插件、容器安全产品也支持东西向的通信审计与管控。
8.5通过挂载目录逃逸到宿主机
（参考3.2通过挂载目录向宿主机写入文件）攻击者可以利用挂载到容器内部的目录完成从pod到node的移动。
8.6访问K8sDashboard
（参考7.4访问K8sDashboard所在的Pod）攻击者在进入某个pod之后，可以通过信息收集或内网扫描的方式发现K8sdashboard所在service地址，并在管理员权限配置失当的情况下通过K8sDashboard下发指令。
8.7攻击第三方K8s插件
为了快速上手，很多K8s快速入门指南都会介绍一些好用的插件和配置方案，但教程的创建者很少考虑到真实生产业务中的安全问题，而这些插件往往在初始的几个版本中存在鉴权方面的漏洞(如API默认允许未授权访问)，直到被攻击者反复测试之后才会逐渐稳定可靠。这些不安全的配置以及使用的第三方K8s插件/工具会引入新的攻击面，并为横向移动提供便利。
示例：常见的利用第三方组件进行横向移动的过程：
攻击者进入pod后，通过未授权访问或漏洞攻击第三方组件，并利用这些组件的权限操纵K8s集群。
9.Impact/影响
9.1破坏系统及数据
以破坏为目的的攻击者可能会停止或禁用系统上的服务、删除某些核心文件及数据以使合法用户无法使用这些服务。停止关键服务可能会抑制防御方对事件的响应，并有利于攻击者的最终目标。
9.2劫持资源
常见于攻击者通过自动化脚本入侵并植入挖矿程序进行获利。
9.3DoS
攻击者会发起DoS攻击，影响系统的可用性。容器化场景中的DoS攻击包括对业务层、K8sAPI层的攻击以及对Pod资源的抢占。
9.4加密勒索
在传统主机安全场景中，有经验的攻击者会找到企业核心数据并对其进行加密勒索。由于容器场景的资源弹性较大，且后端数据的产生、存储、销毁链路往往通过云服务API实现，而非在用户磁盘上进行，企业可以通过云原生的快照与备份服务来实现资产备份，避免核心数据丢失。
阿里云容器安全解决方案
阿里云容器服务（ACK）提供高性能可伸缩的容器应用管理服务，支持企业级Kubernetes容器化应用的生命周期管理。阿里云容器镜像服务（ACR）是云原生时代的重要基础设施之一，支撑阿里巴巴经济体容器镜像托管，分钟级分发万节点。自2015年起，先后服务了数千家企业，托管了数PB容器镜像数据，支撑月均镜像拉取数亿次。
借助云安全中心，阿里云可以为客户提供自动化的安全编排与响应能力，全面提升容器安全易用性；同时为容器镜像提供漏洞扫描和修复，并支持整合在容器构建流程中，避免部署存在风险的容器；对于运行时的容器被植入Webshell、挖矿病毒等场景，自动化将隔离恶意样本，并通过联动云防火墙，针对存在漏洞的容器，提供虚拟补丁的能力，缓解安全风险。
写在最后
理解容器ATTCK矩阵是构建容器安全能力的第一步，除了上述涉及的能力和措施外，阿里云安全团队建议用户在实施容器化过程中需要遵循以下几点安全规范，从不同角度缓解容器化带来的风险：
收集并妥善保管K8s集群、第三方CI组件以及云服务的API通信凭证，避免因人工误操作导致的AK泄露。
最后，针对上述容器ATTCK矩阵，阿里云推出容器安全运行检测清单，企业可以根据下图中所展示的内容检测自己的容器安全水位，以便及时发现问题及时修复。
内容致谢：
陈吴栋（自朴）阿里云高级产品经理、魏俊欣（艾格）阿里云高级安全专家、邱戈川（了哥）阿里云高级技术专家、杜航（达丁）阿里云容器解决方案架构师
