云原生的诞生
2013年Pivotal公司的Matt Stine首次提出云原生（CloudNative）的概念。随着时间的推移，现在的云原生概念概括为4个要点：微服务、容器化、DevOPS、持续交付。
云原生在项目开发时就和云环境绑定，相对应的云原生安全，需要在创建云环境时同步考虑云上应用安全，使应用安全问题左移，将安全问题前置。
应用使用云原生架构，传统软件安全问题并不会消失，反而会因为云上架构复杂，组件直接调用增多造成更多问题。云原生安全防护体系的建设要围绕云原生应用的生命周期来进行构建，整个生命周分为构建-分发-运行，涉及开发安全、镜像安全、容器安全、宿主机安全、应用安全、容器编排平台安全，这同样也是敏捷开发中DevSecOps 所倡导的应用安全模式。
在讲云原生安全之前，我们先拆开看云原生的4个要点。
01 微服务
了解微服务之前我们先了解什么叫单体应用，早在MVC（Spring + iBatis/Hibernate + Tomcat）作为主流术栈的时候，单体应用的概念随之诞生，因为MVC架构就是为单体应用设计的，开发人员将写好的WAR包通过tomcat的启动和加载，对外提供服务。MVC架构适用业务规模不大、开发团队较小的场景。
但是随着IT的不断发展，数字化项目承载的业务越来越多，单体应用弊端显现出来，如：开发团队多人协作时，将代码提交后一起打包部署进行测试，测试阶段一旦有一个功能模块出问题，必须重新编译打包部署再进行测试，所有相关的开发人员不得不参与其中，导致开发成本提高，开发效率低下、部署效率低下。
传统的MVC架构将所有功能部署在同个war包，运行在同一个tomcat容器，会出现一毁毁所有的现象，导致JVM进程中的所有服务都不可用。
基于以上，微服务应运而生。
2014年，以Docker为代表的容器化技术的成熟，以及DevOps文化的兴起，慢慢演变为今天我们所熟知的微服务。
微服务的特点：服务独立部署，比如一台物理机可部多个Docker实例，可细化到一个子模块，可独立形成一个微服务，独立维护。
微服务可以在“自己的程序”中运行，在微服务架构中，只需要在特定的服务中增加所需功能，而不会影响整体进程架构。随着移动互联网规模不断扩大，敏捷开发、持续交付、DevOps理论的发展和实践，以及基于Docker容器化技术逐渐成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。
02 容器化
讲到容器化我们从docker入手来讲，docker是一个开源容器化平台，Docker的特点“一次创建或配置，可以在任意地方正常运行”，即软件带环境安装，安装时将原始环境一模一样的复制过来一份，也就消除了不同机器运行结果不同的问题。
Docker的基本组件包含：容器、镜像、仓库
镜像：镜像基于分层实现，作为一个只读模板，每层都可添加、删除文件。
镜像可以创建docker容器，且可以创造多个容器。
容器：可以理解为docker利用容器独立运行的应用。镜像创建的运行实例就是容器。容器与镜像的关系：镜像负责存储和分发，容器负责运行，就像Java中的类和实例，通过类可以实例化具体对象，通过具体的对象可以调用类中的方法。
仓库：在docker中，仓库是集中存放镜像的地方，是一个集中的存储、分发镜像的服务；每个仓库可以包含多个标签，每个标签对应一个镜像。通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。
Docker的优势有很多，Docker容器对比虚拟机如下：
高校利用系统资源、启动时间更快、运行环境一致、devops持续交付、持续部署、低耦合、维护拓展更轻松。
03 Devops
DevOps包含development和operations，是开发和运营维护的总称，为巩固软件设计与开发结果，将开发、运维与测试结合一起，形成了DevOps软件开发管理模式。
04 持续交付
在不影响用户使用服务的前提下频繁将新功能发布给用户使用，传统的开发和交付做到这点很难，频繁发版上线会给不同的用户造成不同程度影响。而现在主流的云原生技术通过微服务+容器化+devops，完全可以做到持续交付且不影响用户的使用。
立足云原生原理
打造云原生安全RASP应用
云原生是指建立在云上多种提升技术及效率的结合，摆脱物理存储，实现应用专业优化和效率提升。了解了云原生原理后，再回头看云原生安全就可以知道我们的发力点，云原生安全可包括软件开发安全、镜像安全、宿主机安全、软件运行时安全。
开源网安应用安全防护平台（RASP），采用插桩技术实现无需人工干预、无感知的攻击检测和防护。针对互联网企业和分布式应用项目，RASP平台的部署效率与防护效果更加明显。
RASP在云原生场景下的安全应用：
RASP主要功能是应用运行时的安全防护，除了上图的应用运行时的漏洞检测、应用加固、0day防御、安全弱点防护、安全基线检测，RASP还有很多其他功能。
