本次分享的主题是云卓越架构：容器安全最佳实践，由阿里云智能集团解决方案架构师张玉峰分享。
本次主题是云卓越架构：容器安全最佳实践。
本次分享在云卓越架构的框架下容器安全的最佳实践。将分享包含三个部分：
首先谈一下在容器安全层面遇到的一些问题和挑战。
第二部分从阿里云的视角看容器安全和云原生维度的安全体系和架构是什么样的。
第三个部分展开讲解目前遇到比较多的一些容器安全维度的典型的场景，在分享之前，同步一下Landing Zone和WA的定义，为什么讲云卓越架构的最佳实践？
用户在使用阿里云的时候，分成两个阶段，第一个阶段是初始化阶段，是刚上云的客户，推荐参考Landing Zone的框架，在框架中，会指导客户如何快速使用云资源，如何高效使用云资源，包含八个大模块，包括财务管理，资源规划等，其中安全防护是Landing Zone模块的其中之一，教如何快速的使用阿里云的一些云产品，帮助搭建业务。第二个阶段是当用户使用一段云资源之后对云有所了解后，如何更好的使用云产品完成业务上的诉求，称之为最佳实践。
在WA的框架中包含五个大的支柱，分别是安全合规、稳定性、卓越运行、成本优化和高效性能。其中安全合规排在第一位，意味着在上云之后，在第二个阶段深度用云的阶段，安全合规是一个非常重要的话题，今天分享的容器安全最佳实践为什么有卓越架构。意味着在WA的卓越架构下，安全防护的维度有一个叫计算资源防护，容器是云上最常见的工作负载之一，云上除容器以外，还有ECS，Serverless，包括面向AI的一些基础设施，所以关注基础设施的安全防护该如何做的层面，实际放在了WA的框架中，如果感兴趣，后续可以在提供的物料当中有二维码，关注更多Landing zone和WA的安全防护内容。
一、容器安全的挑战
接下来步入今天分享的正题，第一部分容器安全面临什么样的挑战。这里做了一组统计的数字，可以看到Sysdig在2023年的数据，看到2024年最新更新的数据，比这里获取到的还要更激进一些。
看到中间第二部分90%的授权没有实际使用，但在2024的调研报告中，95%甚至更高的比例的授权没有实际使用，在容器和云原生的挑战中，87%的容器镜像包含严重或者高危的恶意漏洞，在2020年Docker Hub上有非常严重的镜像投毒事件。镜像实际在2020年被用于挖矿，挖门罗币。
当时统计数据，镜像被下载200万次，意味着大概有200万个Pod遭受容器攻击的事件，所以这称之在云原生和容器维度里供应链安全最主要的一个风险，是容器本身的镜像的安全性和镜像该如何去保护，这是面临容器安全的主要挑战，包括镜像的安全，漏洞，风险，权限高，以及在容器生产运行过程中，存在的一些风险该如何防护。
再看容器入侵的攻击面分析，这里从两个维度剖析容器入侵的一个过程。第一个方面是从云资源层面的攻击路径，第二个层面是从K8s Pod容器本身的攻击路径，最左侧是面向云平台，意味着无论用哪一家云厂商使用的K8s平台，使用的一些关键的组件，使用的一些比如ingress，APSO等都存在一些比如身份，权限授权过渡，控制面的配置不当，网络上存在非授权访问的一些问题，这些都是在云资源发起攻击的时候，黑客会利用到的比较常见的攻击面，看左侧这张图，不仅是云原生和容器，把它放大到不同的安全事件当中。
对于云上的一些攻击路径，无非是三种比较常见的攻击入口，第二张图是从K8s层看到的一些攻击路径，这里列两个攻击的入口，第一个入口是应用漏洞，第二个入口是内核漏洞，意味着从安全，从整个入侵的维度来看，漏洞仍是遇到最主要的一个攻击暴露面之一。
举个实例，攻击者通过Pod里运行的一些应用组件存在的公开的漏洞，打入到容器内部，然后利用一些比如容器逃逸或者是Pod与APSO或者在Pod与Pod之间缺乏严格的网络隔离策略的时候。做一些入侵去实现主机逃逸，或者是防内部其他的移云资源，实际是看到当前容器入侵的主要的两个攻击面，下面围绕这两个资源，这两个层面看怎么做相关的防御。
谈完攻击面再来看容器面临哪些暴露面。攻击面是从黑客的视角来看怎么去入侵关键技术实施和入侵服务。暴露面是使用容器的资源，容器会用到各种各样的组件以及各种各样的配置，在安全层面有哪些暴露面，从攻防的视角和从安全产品的视角做一些梳理，大概总结有五个暴露面：
第一个是网络维度暴露。在使用容器服务的时候。肯定会使用APSO， K8s的APSO包括创建ingress，创建一些service，比如class的ip， node的一些端口等，包括在云上会使用到各种各样的VPC，包括容器的VPC，以及通过容器服务调后端，比如pass资源的一些跨VPC的资源访问等，都是遇到的一些网络暴露的点。
第二是在容器里配置一些敏感的数据和敏感的文件，核心的两个一个是Secret，一个是AK和SK。在上面两个topic，介绍如何在阿里云上使用VK或者是AK的一些最佳实践，但在容器里不仅AK是敏感数据，使用的比如一些API的token，或者是一些password，或者是一些应用程序里的密钥称之为Secret，这些在Pod里的康复文件里也都是明文存储的。怎么保障这些配置文件的安全性，后面会有介绍。
第三个是容器突破，指的是在围绕整个攻击的视角，黑客会利用哪些攻击手段对Pod，对容器的环境做一些攻击，比如典型的容器逃逸，典型的容器勒索病毒包括前几年比较流行的利用容器挖矿，因为容器的资源实际上很大，而且它的生命周期也很快，所以利用容器做勒索病毒的扩散和容器的挖矿，在前几年比较常见。第三点是横向入侵，像Webshell，特权访问，过度授权，这些都是容器突破维度的一些暴露面。
第四点是大部分客户会忽略的一点，是在谈容器的时候大部分用户只关注Pod或者是K8s层面，但围绕K8s和Pod的基础设施，比如构建ACK， ACK里会创建各种各样的比如ECS的node节点，Master节点。如果用的是一些Serverless的资源就不谈，谈的是围绕基础设施的问题，基础设施会存在相关的漏洞，比如主机节点的漏洞，或者是使用一些K8s里的应用软件比如cod， DNS，ingress等或者一些编排软件K8s，ACK等，这些基础设施本身的漏洞是不是值得注意，第五点是高风险镜像，比如有存在漏洞的一些镜像，没有经过安全检测和安全审核的镜像，以及包含敏感信息的镜像，当这些镜像被拉到Pod之后。意味着暴露面已经暴露在互联网上。攻击者可以利用在野的一些漏洞，或者敏感文件，或者一些授权过渡来对容器环境进行入侵。
二、云原生容器安全架构
第二部分容器安全的架构应该是什么样的，首先抛出来一个问题是容器安全到底要关注什么东西。是不是只关注镜像就可以。还是要把整个容器的全生命周期，围绕CI/CD，围绕开发布整个的环节都要关注，大概列五个维度：
第一个维度重点的提出身份是一切的基石，所以无论今天用阿里云，还是用阿里云上的任何一款SAS或pass类的服务，身份永远是安全要考虑的第一要位，所以容器的身份和权限在实际做安全体系架构设计的时候要充分考虑。核心还是老生常谈的秉持着最小化的原则，进行容器的身份的权限设计和安全的管理。
第二是配置管理，容器的配置管理包含哪些，比如配置是不是要合规，因为做安全体系建设的时候，合规是绕不开题，尤其在容器，因为容器本身是和业务层面关系非常紧密的一个应用和一个基础设施，安全团队怎么介入到应用侧管理合规问题。围绕的是创建的Pod和使用的云资源是不是合规的，配置有没有相关的不得当的比如满足国内的一些要求，满足海外的要求等，然后哪些配置项需要额外的注意和保护，该如何管理容器和K8s中的凭据。都是配置管理里需要关注的问题。
第三点关注的是容器运行时和基础设施的安全，首先容器运行时是Runtime层面会存在哪些风险，第二是在阿里云上创建一个ACK资源，或者Serverless资源的时候，它会同步帮用户开通哪些云资源，比如前面讲的SLB，负载均衡，ingress或者ECS等，这些资源本身的安全性也是用户需要关注的，否则就变成只注重上层的安全，底层的安全被入侵也是一样的风险。
第四点需要关注的是漏洞和补丁的管理，在云原生服务中，常谈一个问题，漏洞到底是由厂商负责还是由用户负责，责任的边界到底是什么。当用不同的云资源，比如ACK的pro的版本，或者Serverless的版本，不同的版本对应的给用户提供的基础设施也不同，这些的漏洞职责和义务分别是什么。用户需要有非常清晰的界限和定义，什么时候该打补丁，有没有自动化打补丁的方案，以及打不了补丁该怎么办，比如这些补丁没有办法修复，很常见一些应用的一些补丁，如果要做修复，就面临着整个的业务系统重启，对于整个在线的业务来讲是比较大的损失，而业务肯定还有一方要妥协，打不了补丁该怎么办。怎么提供一些Runtime的防护。
第五点是前几年在聊容器安全的时候，经常会提到的问题-安全左移，但随着这几年的能力的迭代，或者一些技术的进步。并没有看到安全左移成功，不确定是业界的问题，还是客户对于安全左移的概念有一些误解，安全左移在阿里云上有几个难点。第一个难点是当使用一些安全的控制措施，怎么和云服务尽可能的耦合起来，对于用户的改造和业务方的侵入，实际上达到的成本最低。
可能并没有践行安全左移最主要的一个原因，在分享当中会详细介绍阿里云上围绕云原生的容器的服务的产品，安全类的一些服务，它和云原生的服务怎么做耦合，尽可能降低用户的使用门槛和接入难度。从安全架构维度来讲，需要关注五个层面。
安全架构长成什么样子？安全架构分成两个层面，最底层是围绕基础设施的安全加固，要做到网络隔离和访问控制，意味着创建了一个ACK的集群，ACK的集群会占用VPC地址，占用CI/CD，也会去占用云账号、云资源，这些云资源和其他非生产或者其他业务方怎么做到网络的隔离和访问控制。
第二是稳定性和可用性的加固，在WA里是另外一个话题，因为最近其他的场馆在讲容器云原生的稳定性和可用性的一些话题。
第三点是漏洞和补丁管理。围绕基础设施包括刚才介绍的使用的云原生服务当中漏洞的分类和职责的一个边界。
第四点是日志审计和监控，是必不或缺的一个能力。最后一点是工作负载安全防护和加固，围绕的是构建的容器服务的基础设施展开的一系列的安全访问控制。上面是围绕整个容器安全包含K8s，Pod维度来看。
这里分四类，第一类是身份及权限管理，这里提到在K8s里，要做RBAC的授权，要做RAM的权限管理，以及怎么把RAM和RBAC结合起来，少维护一套身份体系。
第二点是配置安全检查，比如检查授权过度，检查敏感数据，检查不当配置，以及对于AK， SK，Secret管理的方案，因为在前面的方案里提到在AK里有RSA的方案提供，Pod里通过SDS token调用云资源的一些方案最佳实践。都是属于容器安全，包括整体架构里的部分。
然后第三点是运行时防护，包含像容器防逃逸，防勒索，防病毒，容器文件保护以及应用层的安全防护等。
第四点是镜像的安全检测以及发布的安全，包含安全检测、漏洞扫描、镜像发布的安全管控、主动防御以及OPA策略等，这些实践或者安全架构都是在构建整个容器环境当中必不可缺的控制措施。
三、容器安全典型场景
下面重点看容器安全里几个典型的场景，逐一介绍这些场景怎么实现和怎么做。
第一个重点介绍容器身份和权限管理。当使用ACK的时候，注意到在ACK的授权体系依赖于RAM，但它又有独立的授权体系，这里可以看到在ACK里的授权的分层，它分成基础资源层，集群层和用户层。基础资源层是完全依赖RAM的体系管控。今天通过一些RAM user或RAM Rod的授权管控用户能够访问ACK依赖的云产品的Open API，这是一个维度包括集群的创建，查看，删除，对于集群的管理等。
第二个层面是在K8s的集群里，提到RBAC的授权的模型，RBAC本身是对运行在ACK集群当中的应用进行运维的操作，比如对于connected对象的增删改查等，它的力度更细，发现在模型当中至少有两层的授权模型，一层是RAM，一层是RBAC，对于运维和安全来讲，这两层的授权都要做检查、管控和理解。同样要对RAM的授权做最小化的检测和管理，对RBAC也要做一些最小化授权和管理。
但有一个问题，RAM可能会由安全团队和infra团队管控，一旦到集群层内部，到RBAC层面，可能往往不取决于infra或者安全团队的职责范围内，往往都是比如divorce，或者应用团队对RBAC进行配置和授权，从职责层面会有分层，所以出现一个问题是安全团队怎么有效的管理RBAC的权限，以及如何将RAM的身份和RBAC的身份做映射来尽可能的减少管理不同的身份体系的策略。
看一个方案，在K8s的应用组件里推荐的方案之一。采用到K8s的ACK- RAM-authenticator的一个组件，组件本身用到K8s webhook的旁路认证的机制，实现的目的是当企业采用统一的IDP管理身份的时候，因为RAM是阿里云的身份，对于一个企业来讲，企业拥有的实际上是他的企业身份，比如他的AAD，或者是他的QTA的身份，或者是来自于ldep或者AD的身份，这些身份可以有效的和RAM通过SSO，通过RAM user的方式结合。但怎么和K8s的身份结合。
可以通过组件实现企业IDP的身份和容器内的身份进行相关的mapping和绑定，实现的效果是当再发起些请求的时候，整个的建全会通过组件调用阿里云的RAM，阿里云的RAM调用户的IDP来实现建全，所以最终满足的是企业的SSO角色接入的场景，以及满足企业客户IDP身份下发和审计的诉求，也有效解决一些比如用户常见的困扰，今天员工离职，员工发生了变更，这些变更的信息在企业的权威的数据源里，无论是AD还是HR系统。
这些身份、这些信息的变化如何同步到ACK里，就可以通过一个组件来实现身份的贯穿。
第二个场景是容器的密钥管理，前面讲容器基于RSA来实现Pod调用阿里云的API的场景，讲的是AK的使用方式，今天在Pod里还会配置多非AK类的敏感数据。比如应用程序的password，数据库的password，密钥，key，怎么做配置的管理和最佳实践的使用。这里提到KMS，ACK也提供两个组件。一个是ACK的Secret-manager，一个是Secret-store的csi的provider的组件，这两个组件的本质是通过凭据的替换。在配置文件里不去写入明文的password，也不去写入明文的AK， SK，而写入的是一个Secret name，通过Secret name的调用和交互。实现在配置文件里不去保存明文的一些敏感信息，同时通过KMS的Secret manager的组件有效的对保管在Pod的康复文件里的凭据进行轮转替换，或者是安全的访问控制。是有效能够解决容器密钥管理的实践之一。
这两个图有什么区别。第一个是通过ACK的Secret manager实现密钥的同步，意味着将凭据集中的存放在KMS的服务里，通过组件可以将KMS的凭据同步给Pod里的配置文件，这是同步的作用。
但是有一个风险是同步之后，Secret也可能会被泄露，这是一个潜在的风险，所以有第二种做法，第二种做法是挂载它的csi的provider，它存储的一个标准方案。它提供的是今天在KMS里存储的凭据，可以直接把它挂载在Pod的某个路径下，当Pod要读取配置文件，读取本机路径的时候，可以直接通过插件，读到KMS托管的凭据。所以这两种方案第一能够解决Secret的管理的问题。
第二提供两种不同安全等级的措施和最佳实践，企业在实际Pod的应用当中使用哪种方式更合理。
第三个最佳实践是容器运行时的防入侵。总结一下容器在Runtime下对于Pod的防护，从攻击的类别来看，大致可分为三类：
第一类也是最严重的一类是容器逃逸，因为容器逃逸之后，意味着它对于管控层面拥有控制权，它就可以做很多非Pod维度的事情，后面也给大家讲几个容器逃逸的成功的案例，它是怎么攻击的过程。
第二个是容器的防勒索，因为勒索病毒和勒索软件包括挖矿软件在国内还是比较盛行，但在海外最盛行，因为海外，毕竟整个的金融支付和交易对比特币比较友好，中国防勒索的攻击事件相对来讲还是会少一些，但是不意味着容器的防勒索并不是常见的一个攻击手段。
第三点是容器的防入侵。比如容器的一些webshell，包括一些容器的基于APSO的攻击。先来看几个典型的常见容器的攻击事件。
这里列举了三类，分别代表三种不同的类型，第一种是常见的容器的入侵的事件，攻击者尝试挂载一个敏感目录来实现容器逃逸或者容器穿透的过程，最终目的是容器逃逸。但是攻击手法是通过挂载敏感路径的方式，是以读写权限挂载系统的根目录，然后到容器环境里，因为一旦挂载根目录之后。它可以通过一些xss攻击，或者是反弹shell下载一些恶意的shell文件在根目录下做执行，获取更高的权限，最终实现的效果是越权访问，或者是攻击病毒的扩散等，这是第一个典型的案例。
第二是通过K8s的service account攻击K8s的API事件，意味着是配置权限授权过度，导致在使用一些权限命令的时候，因为授权过渡可以通过K8s service account向K8s的API发起相关的非授权的指令等，这是第二个典型的case。
第三个是一个利用容器漏洞进行逃逸的事件。在讲容器攻击面的时候，攻击面的第二张图介绍利用漏洞去容器逃逸，在过程当中攻击者利用四步完成容器的逃逸。可以看到标红的部分是在每个请求里执行的恶意的命令和恶意的文件。
第一个命令做了一些编译，翻译过来是执行一个cod的命令，执行通过cod到恶意的IP，下载可执行格置的Shell，第一个通过一个漏洞，一个xss的漏洞来打到Pod里。
第二步进入到容器的内部，然后启动容器的进程挂载宿主机的根目录，同时在新的容器当中执行反弹Shell脚本可以看到标红的两段。第一个实际是挂载一个根目录到容器tmp的目录里，然后下面红色是在新的容器环境里执行一个cod命令，到106。12。108。68恶意的ip下载一个可执行的shell到本地目录。
第三步做一个保留进程，做一个定时任务，因为第二步执行完成之后。如果有一些Runtime的防护，它会对下载的shell或者对反弹shell的行为做拦截，所以会做一个持久化的动作，定期的启动反弹主机的shell，这是一个真实的容器逃逸的过程，除了这三类。
围绕整个攻防的角度来看，业界有一个matter attck的攻防矩阵的框架，在框架当中尤其提到在容器环境的一些攻击的场景，横着来看是攻击阶段，从初始入侵下发指令，持久控制，权限提升，然后到横向移动，达成目标。纵向的是在每一个阶段当中，黑客会用到的一些攻击手段比如使用恶意镜像，前面介绍Docker Hub投毒的事情，然后刚才案例里介绍K8s API Server未授权访问的问题，然后可以看到通过挂载目录向宿主机写文件的攻击方式。在大的矩阵当中实际上是穷举攻击者能够利用到的攻击手法对Runtime的层面进行攻击，画成攻击的矩阵，怎么去防入侵。
从阿里云的层面来讲，阿里云的云安全中心提供一种One Agent的运行时的宿主机的防护和Pod的维度的防护，云安全中心本身是agent base。
有一些客户像在2-4的场馆里发布的云安全中心提到两种模式，一种是agent base，一种是agent list两种模式，agent base的模式。它能够起到的是防御，agent list能够起到的是检测，实际上按不同的需要提供相关的检测措施，云安全中心怎么做容器运行时的防御。首先通过挂载在ECS上的云安全中心的进程，监控跑在ECS上面的容器的进程实现一个防御，所以对于用户提供容器运行防护的时候，它的便利性和阻碍就会变得很小，依赖宿主机的进程，对于容器进行一个监控和防护，可以看到能够防护的类型包括容器的逃逸，容器文件的防篡改，容器入侵的检测拦截，从网络和进程的维度，像前面讲的案例，启动的恶意进程，挂载敏感路径，然后执行一个web shell，对于云安全中心，第一能够识别，第二能够拦截，以及包括恶意进程的启动拦截，包括可以自定义一些敏感进程的启动都可以做。
讲完容器的Runtime的入侵，还有一个层面大家会缺乏一些关注-应用安全的防护，在Pod里部署相关的一些应用，比如会有一些tompad，有一些apache的应用，有一些Log4j等应用，应用怎么做防护。比如以Log4j的攻击为例，可以看到左侧这张图，上面是做Log4j攻击的执行的恶意命令，做攻击的时候要做防护，会通过RASP的一个技术，RASP是一个agent，但agent埋在应用的函数上面，通过hook的关键函数进行检测，它能够实现的是获取应用进程或者函数调用的上下文的信息以及函数的参数堆栈的内容判断。
通过上下文，通过语义，通过专家规则判断的行为是不是恶意，为什么在环境当中讲RASP。因为在国内，大家都知道互网演习，互网演习绕过wave，或者利用一些0day的攻击入侵的一些场景，这些场景怎么有效的提供一些防御的手段。在最终执行攻击的末端，也是应用侧提供防入侵和防御，因为在应用侧通过hook函数，能够看到的攻击信息会更多，所以这里也穷举一些应用的行为，包含恶意的DNS的查询，或者是JNDI的注入，或者是线程的注入，命令执行，SQL注入，特别像内存马的攻击，内存马的注入等，都可以通过RASP的技术能够实现有效的防护和防入侵，这是在容器运行时应用上层的安全，前面讲的是容器Pod本身的入侵Runtime层面的安全，可能是更上层的level。
再看下面实践是容器运行时的基础设施，在安全架构的最底层是关注容器的运行，容器的基础设施。基础设施包含什么。这里以阿里云上目前用到最多的容器产品为例。ACK托管版，ACK专属版和ACK serverless版本，这三个版本。看到它创建的云资源是不同的，也意味着创建ACK的时候，会同时拉起n多台ECS取决于plaster，或者Master节点的大小，还会创建ingress，无论用的是阿里云原生的ingress，比如ALB的ingress，MSE的ingress，还是自建的Nignx的ingress，创建容器基础设施的时候，它用到的一些组件，还有像CLB是用于为API提供负载访问的服务还有NAT gateway。当ACK或者集群要对外发起访问的时候，可能还会拉起一台NAT的gateway，同时创建EIP，Pod。当网络环境比较复杂的时候。可能还会将K8s的VPC关联在企业的CEN内和其他的VPC之间做互联互通，当开通一个ACK服务的时候，会创建所有的云资源。
云资源该怎么去防护，或者该从哪几个维度去看。这张图是实际的云上的部署的架构图，是开通完这些资源之后，这些流量的流向和云产品部署的位置什么样，以及推荐的在这张图里能够提供的安全控制措施的位置是什么，比如网络边界，期望通过边界防火墙实现Inbound和outbound流量的检测。
在ingress层面，通过waf来做一些入侵，在容器内部通过node节点的主机安全，通过容器防火墙，通过上层的Pod的安全，包括rap等提供Pod内的一些安全。在有CEN的场景，通过VPC防火墙的访问控制，对于底层node节点运维的场景。通过堡垒机实现权限的身份的认证和行为的审计。
大概总结四点。
第一网络隔离和访问控制。
第二稳定性和应用层的安全。
第三漏洞和补丁管理。
第四是工作负载的安全防护和加固。这是容器运行时的基础设施安全的最佳实践和架构图。
下一个场景是容器漏洞和补丁管理，大概列四类，在使用的云原生和容器服务的过程当中，漏洞肯定是一个避不开的话题，漏洞该怎么去看待。
；
首先看漏洞的分类。漏洞可以分为四类：
第一类是用户的Master节点上面存在的漏洞。
第二是node节点的漏洞。
第三是K8s组件的漏洞。
第四是镜像的漏洞。
在不同的云产品上，用户的职责和阿里云的职责也有所不同，比如在ACK的Serverless版本，可以清晰的看到node节点和Master节点的漏洞本身不是用户的职责，因为在使用ACK的Serverless资源的时候，并没有创建出来node和Master，用的只是平台层或者调度层或者Pod上层的应用。在用到一些ACK托管版或者专属版的时候。对应的职责就会有所不同。
比如当完全使用Master节点和node节点都是自建的场景下。上述的这四类漏洞都是用户的职责和责任，怎么判断容器漏洞的可见性和真实性。在云安全中心里提供容漏洞可见性的图，可以在云安全中心图里可以清晰的看到KBS平台组件的漏洞，容器运行时的漏洞的情况，因为它是动态的，前面讲漏洞分成两类，一个是静态的漏洞的信息，一个是动态的漏洞信息。特别在容器的Runtime层面，存有动态的漏洞的信息，还有最后一个是该集群节点node和Master节点漏洞的情况，怎么判断漏洞的真实性能。
阿里云对漏洞的真实性判断做比较多的工作，大概分成三个维度。
第一个是时间因子，在阿里云的官方漏洞库里，可以看到每个漏洞的详细的信息，包括阿里云对漏洞的评分。
阿里云对漏洞评分结合cyss的评分的基础之上叠加三个维度，第一个维度叫时间因子，是漏洞从公开到出现利用的工具的时间，时间越久利用的难度就越低，因为在野的时间越长，Pod的工具就越多，暴露的风险就越大。
如果漏洞的时间因子比较小，意味着目前在市面上没有一些Pod的工具对漏洞做入侵，同样评分可能会相对的有所下降。
第二个是实际环境因子，产品判断漏洞所在的服务器，它所在的环境是否和公网有真实的互联互通。如果漏洞是远程可执行利用的漏洞，还会判断漏洞能够被利用的真实性和可能性有多高。如果这台ECS或者容器本身都没有权限访问互联网，可被执行的漏洞的程度和风险也就随之降低。
第三点是资产的重要性，和企业在很多年前维护CMDB的套逻辑相似，在云上需要一套CMDB管理的工具和维护的一个思路，要对Pod，对集群，对ECS去打标，哪些资产，哪些应用是重要应用。重要应用发现一些高危漏洞，再叠加前面的时间因子，环境因子，以及前面提到的漏洞的基础评分，是不是需要关注的重要漏洞。所以阿里云为用户提供。
第一漏洞的可见性，四种维度的漏洞都可以在云安全中心里看到。
第二提供漏洞的真实性判断，意味着帮客户去减少、减轻一些漏洞维护和处理的复杂度。漏洞是成百上千的，处理起来是非常难的，所以叠加三个维度来看，能够减轻一些漏洞处理和漏洞判定的一些原则和条件。
下面一个是安全左移，安全左移是一直在谈的在容器或者在CI/CD当中最重要的一个话题。安全左移本身是将安全的控制措施尽可能的移动到开发流程，结合CI/CD包括交付，运行，意味着不再去或者尽可能的减小对于Runtime层面的一些防护和关注，尽可能的把安全控制措施左移到开发侧。
在过程当中可以看到从研发，源代码，coding，然后到镜像的构建，到上传镜像仓，在镜像仓环节要做安全的扫描，做配置的检查，保障上传的镜像是安全合规的镜像，上传完成之后要对镜像做签名，在后面做部署的时候要做验签，保障镜像的完整性和真实性得到安全准许，然后在做ACK集群做拉起的时候，做调度的时候，在调度之前要通过OPA的一些policy的策略，准入策略管理对发布拉起的一些镜像，或者一些配置进行检查，通过policy做管理，所以可以看到在整个安全左移的过程当中，会用到几类控制措施。
第一类容器的镜像扫描，第二类镜像的配置检查，第三类容器的镜像签名，第四类容器的安全策略管理。第五类容器的主动防御。在安全左移，阿里云上推荐大家使用的五个安全控制措施，先看第一个镜像安全检查的扫描，实现的效果是什么。
今天用到阿里云的ACR和阿里云的ACK的时候，可以直接在ACR和ACK里开启镜像扫描的能力，它是一个一键开启能力，不需要用户再去集成相关的一些扫描的工具，漏洞检查的工具，是前面介绍的安全左移提供最大的便利性给到客户，让客户使用起来尽可能的门槛降低。扫描的类型包含扫描配置基线，镜像的配置基线，扫描系统的漏洞，扫描应用的漏洞，扫描敏感文件，以及提供运行时的漏洞扫描，但是这里可能少写一块，还有扫描恶意文件，比如在像Docker Hub，在2020年的投毒镜像一样，它在镜像里植入一个恶意文件，然后当镜像被拉起的时候，恶意文件就会通过反连的形式连到c to c的一个中控的主机，实现全网的挖矿，所以在上传镜像的第一步骤。
通过检查可以快速的发现镜像里有没有存储恶意的文件和恶意的类型。
第二个是容器的配置安全检查，用户问题是推荐检测哪些基线是没有问题的，能不能给一个最佳实践推荐，所以在这里大概罗列针对于比如K8s的Master节点，node节点和在Docker，Pod维度推荐的一些基线是什么。比如像K8s node节点拒绝未授权的访问请求，或者是配置文件设为root索引等，或者在Docker里，会限制容器的内存使用量，主要是防止容器逃逸，不要在容器里挂载主机的敏感目录等，也是防止容器逃逸。
所以会内置一些从合规维度，从实际攻防的维度来看，哪些基线是可以用于扫描，用于检测，包含对于身份维度，授权维度，弱口令维度，敏感文件维度相关的一些扫描的内容。第三是镜像的签名和验签。第三步当扫描完镜像之后，也做镜像的检查之后镜像在企业内部就被认为是安全可信的镜像。怎么去验证可信。常见的手段是签名和验签。
在阿里云上打通镜像仓ACR和ACK集群，KMS，云安全中心四款产品，让用户可以一键的开启镜像签名的功能，而不需要改代码，集成SDK，搞复杂的策略，可以在云上快速的使用签名能力，实际上流程会在KMS里创建用于签名的一个密钥，然后ACR和ACK集成KMS的组件，它会有一些内部集成的逻辑保障做签名和验签的时候，都能够调取到KMS创建的密钥，而且密钥在KMS里做保存，它的安全性本身也是能够提供。
然后第二是创建签名策略，可以为镜像仓name space开通经验签名的一些策略的能力，然后确保进行上传，之后通过KMS完成数据签名，然后当拉起的时候，对整个过程进行验证，去保障整个供应链的一个安全，也是解决供应链，攻击和投毒镜像攻击最有效的手段之一。
最后是配置主动防御。主动防御是一个什么概念。可以看左侧这两张图，先看左上角的这张图，这里用T和T+1，T+2的形式，描绘时间轴，首先在T时刻上传一个镜像，也做镜像的扫描，也做镜像的加签，把它上传到镜像的仓库里。但是镜像是T+2时刻被拉起的，意味着在T+2的时间段之内，实际上是镜像本身的一个暴露窗口。为什么会有暴露窗口。取决于镜像扫描的任务。
它是一个周期性的任务。它是一个不可能去实时的扫描镜像，因为对开销，对成本都是有一定的影响，所以镜像扫描是一个任务制的，它有时间窗口。如果恰巧在没有扫描镜像的时刻，镜像被拉起，这是不是镜像的风险的暴露的一个窗口。
主动防御是一个什么概念。在T+2时刻，在部署阶段拉起镜像的时候，对镜像做一个检测，做一个策略的过滤，比如检测镜像被拉起的这一刻有没有经过扫描，如果没有做扫描，要打回要在流程当中立即做一个扫描，同时会检测镜像是不是来自于互联网的非法镜像，比如没有经过签名，认为是来自于互联网的非法镜像，当然这是策略的宽松度，还有一点是看镜像里是不是包含一些高危的漏洞，是不是包含一些高危的恶意样本等，或者是不是有敏感文件，通过的策略的检查，称之为主动防御，镜像拉起之前对它进行一个过滤，保障拉起的镜像一定是安全可靠的。
拉起之后是Runtime保护的范围，Runtime保护的范围并不是安全左移的概念，都是安全左移里的，在和客户聊的时候发现一个问题，聊的都是镜像扫描，镜像的安全检测，镜像的漏洞管理，但是忽略的一点是事前发现镜像有漏洞，接下来会做什么。是告诉开发把漏洞修掉，还是有一些真正的控制手段，让镜像不会被拉起，不会被运行。客户是没有的，告诉研发把漏洞去掉，但研发说应用立即就要上线，能不能允许带伤上阵，带伤上阵要考量的Runtime的保护足不足够强大，所以主动防御是在充分的保障Runtime之前的最有效的安全措施，也能够给企业内部留足比较充分的安全防御的时间窗口，这是容器主动防御的一个最佳实践和它的一个定义。
回顾今天讲的容器安全体系和全生命周期的覆盖，围绕CI/CD两个过程在开发、构建、部署、运行维度。在开发构建层面，通过镜像的漏洞扫描、镜像的配置扫描以及安全准入和主动防御和CI/CD做集成能够有效的保障制品安全，在运行之前，尽可能做到安全。在运行和部署Runtime层面，要做漏洞的风险的管理，容器运行时的防护和应用的自保护-RASP。
