应用层的测试和漏洞扫描相当于对应用整体安全的一个检测机制，在安全问题引入之后，通过安全测试和漏洞扫描发现这些问题，推进修改。在安全管理维护方面，最经常处理的是CVE漏洞，CVE漏洞通常是一些隐藏较深、有一定修复难度的问题。对负责业务开发和业务运维的工程师来说，由于接触应用层安全问题的机会不多，仅有的几次机会也是对CVE漏洞的修复，修复的方案往往也是通过版本及第三方库的升级来完成的。长时间的操作过程造成了对应用安全处理机制的两个错误理解，一是认为安全问题是由外部安全防护机制来处理的，二是认为安全问题不太容易引入。

对安全问题的这两个印象实际上是不对的，特别是在云原生环境下，由于疏忽很容易引入安全漏洞。拿一个例子来看，一个容器中的进程如果以root身份运行，那么这个进程在主机操作系统内部也是root身份的，这个程序容易被利用并通过SUID扩大入侵范围；或者有些时候，由于错误地配置了网络策略，业务接口向平台中的所有业务应用开放，破坏了业务的隔离性。这些问题在实际应用中经常发生。

由于云原生业务应用的运行环境已经不同于传统业务应用场景，在传统业务应用场景下，安全管控主要依赖网络边界设备，比如防火墙、IDS/IPS、WAF等。云原生业务系统运行在云化的环境中，网络边界普遍已经虚拟化和模糊化。另外，云原生环境有大量的多租户共享以及多业务应用共用的情况，各业务系统需要在代码、配置和技术选型使用上注意安全问题。如果不遵守一个好的安全规范，日积月累的小安全问题会让业务系统漏洞百出。在常规情况下也许业务系统能够稳定运行，在扩展性和性能等方面表现良好，但是一旦遇到入侵，很容易就会出现严重的安全事故，比如数据泄露、资源泄露或者遭受网络欺诈，造成严重后果。所以云原生应用在开发流程执行过程中就需要确立好安全规范，并把安全规范的执行检查嵌入到DevOps流程中。

安全规范需要考虑平台安全使用规范、容器镜像安全规范、云原生应用安全规范、安全审计规范这四个领域。这四个领域中安全规范的作用和目的如下。

1）平台安全使用规范：规定平台层（包括主机、Kubernetes集群）的配置和使用规则。

云原生平台是应用运行的基础，安全工程师的一个重要职责是维护平台的安全。平台安全建设的约束和规范在应用开发流程中可以体现的点并不多，主要是在用户和文件权限及Kubernetes平台配置。

2）容器镜像安全规范：规定应用镜像打包规范，约束使用的基础镜像以及基础镜像的使用方法。

  • 只能使用指定的容器基础镜像（如alpine的固定版本）。
  • Dockerfile中不能包含敏感信息（比如密码等）。
  • 需通过USER命令指定容器进程的启动用户，不能以默认的root身份启动。
  • 镜像不能挂载包括/etc、/bin、/root等路径在内的系统关键路径。
  • 发布的镜像需通过镜像扫描平台进行安全扫描。
  • 非特殊情况，不允许在基础镜像的基础上再下载扩展软件包。
  • 某些情况下，安装扩展软件包时，需通过安全工程师来操作，安全的软件包需精简，去除无用的附属文件（如debug工具、帮助文件等）。

3）云原生应用安全规范：规定Pod的定义规则、namespace的隔离规则以及各应用之间的访问规则；还包括应用在架构上的安全定义规则。

云原生应用安全规范的内容较多，包括应用中间件的选型和使用、应用Pod声明文件包含的必要配置、应用Pod之间的隔离策略、Security Context和Pod Security Policy的使用规范以及平台服务账号及其角色绑定的配置规范等

4）安全审计规范：规定应用的操作日志、与安全相关的应用运行日志的打印规范。

安全审计规范中定义了应用操作日志、与安全相关的运行日志及运行事件的输出规范，主要包括以下内容。

  • 用户对资源的操作和管理需记录操作日志，操作日志的信息字段需记录操作源IP等关键字段。
  • Web层接口的调用入口及出口需记录调用日志，调用日志的级别需为WARN。调用日志需标记出调用时间、输入参数和能够标记调用用户的字段信息。
  • 应用日志中不能输出用户的隐私信息（比如用户密码等）。
  • 应用日志需对应用异常情况进行捕获，并输出应用运行的整体情况日志，如在线程池满的时候，输出线程总数及请求队列的统计信息。
  • 需开启kube-apiserver审计，记录平台的事件信息。

平台以及应用层规范的制定主体是安全工程师。安全工程师除了提出和制定安全流程规范外，还负责在DevSecOps流水线中配置自动化的安全规范检查机制，将安全的检查工作融入日常的开发流程中，利用云平台的自动化机制来实现自动化的持续安全。