私有云安全由于其合规性和独立性，不同于公有云和混合云，需要单独定制落地的流程和规划，这里跟大家简单聊聊关于容器安全设计的相关问题。
容器安全综述
容器安全架构设计，可以在其三大关键生命周期阶段进行实施，其中包括镜像安全、配置安全、运行安全。
镜像安全：
在初始阶段对镜像本身做把控，从供应链进行核查，在日常会对镜像做验证和校验，最后会在构建时进行阻断或者检测。
配置安全：
对于构建好的初始镜像，需要遵从行CIS、NIST最佳安全实践。在构建好系统后，需要检查相应的Docker配置、Kubernetes配置、以及操作系统本身。
运行安全：
在容器运行的时候，我们会对里面的系统运行状态进行监控，还会对CMDB资产图谱状态进行对比核查。
镜像安全
嵌入流程检测
这部分工作可以结合CICD流水线进行，一般有两种建议。
CI构建阻断：
日常构建新镜像时，接入配置扫描和白盒扫描流程，如果核查出错会直接阻断，这种做法稍显粗暴，而且会影响业务，但这样可以减少镜像出现风险的可能性，后续重构建的工作也会相应减少。
旁路分析：
复制需要检测的镜像，进行模拟构建，出问题直接阻断。这样的好处是不会影响业务进程，但脆弱的镜像可能会被构建到生产环境，存在潜在风险。
出现问题后，研发运维人员需要根据镜像标签去做追踪，剔除脆弱镜像或者排期重新构建。
这种一般是在构建时，不会直接阻断流程，而是旁路提供鉴定报告，后续再供给安全运维人员进行分析。
当然如果需要得到即时结果，则构建扫描可以提供API攻击给Docker CI平台，作为结果自动化处理的参考。
镜像初始安全
镜像库内控
首先，对于镜像本身，由于企业自用的镜像大部分是规范定制化的，纯私有云落地的话不建议使用公网镜像库，可以看看harbor之类的，这也是为保障供应链风险可控。
由于私有云合规性的特殊要求，一般是要求不能接入专线（与混合云不同），这样能在减少诸如水坑攻击，或者防止被黑客大规模挂马之类攻击误伤。
镜像仓库核查
对于初始镜像，需要定期核查软件镜像库，查看镜像是否被植入木马。如果私有镜像仓库由于配置不当而开启了2357端口，将会导致私有仓库暴露在公网中。
这样的话，攻击者可以直接访问私有仓库并篡改镜像内容，存在仓库镜像被污染的隐患。
镜像扫描核查
镜像核查，主要会做两方面的工作：
-
第一，是进行常规漏洞检测，根据CVE漏洞库进行清单核查式扫描。
-
第二，是对系统进行基线检查，把潜在的风险扼杀在摇篮里。
这部分核查结果，需要分布走进行治理，首先更新初始镜像，把相关镜像的缺陷统一修复。 然后，会根据线上业务和系统本身的稳定性和适配度，在测试环境调试回归并灰度完毕，再统一进行替换。
镜像数字签名
Docker的内容信任（Content Trust）机制，可保护镜像在镜像仓库与用户之间传输过程中的完整性。目前。目前Docker的内容信任机制是默认关闭的，需要手动开启。
内容信任机制启用后，镜像发布者可对镜像进行签名，而镜像使用者可以对镜像签名进行验证。
镜像构建者在通过docker build命令运行Dockerfile文件前，需要通过手动或脚本方式将DOCKER_CONTENT_TRUST环境变量置为1进行启用。
在内容信任机制开启后，push、build、create、pull、run等命令均与内容信任机制绑定，只有通过内容信任验证的镜像才可成功运行这些操作。例如，Dockerfile中如果包含未签名的基础镜像，将无法成功通过docker build进行镜像构建。
（命令示例：export DOCKER_CONTENT_TRUST = 1）
供应链核查
对于代码中使用的公共组件包，需要对来源进行核查。在私有云的落地实践中，最好是建立私有包的仓库，这样即使镜像被进行植入性攻击，也在可溯源和可控制的范围内。
顺便提一下，企业日常使用的代码编译器，也需要在企业核准控制范围内。最好通过统一采购源，在内网提供正版的下载，以及提供内网激活API等方式。
但是，在目前大环境下，由于版权和虚拟资产购置价格过高的问题，不少互联网大厂也很难统一解决这一点。
配置安全
内部核查
Dockerfile核查
如果Dockerfile存在漏洞或被插入恶意脚本，那么生成的容器也可能产生漏洞或被恶意利用。例如，攻击者可构造特殊的Dockerfile压缩文件，在编译时触发漏洞获取执行任意代码的权限。
如果在Dockerfile中没有指定USER，Docker将默认以root用户的身份运行该Dockerfile创建的容器，如果该容器遭到攻击，那么宿主机的root访问权限也可能会被获取。
如果在Dockerfile文件中存储了固定密码等敏感信息，并对外进行发布，则可能导致数据泄露的风险。
如果在Dockerfile的编写中添加了不必要的应用，如SSH、Telnet等，则会产生攻击面扩大的风险。
Metadata安全监控
本身私有云环境是相对隔离的，但如果其中的数据访问鉴权方式不当，或者意外造成了安全密钥泄露的话，黑客可以比较容易的获取到敏感元数据。
所以在安全配置和访问控制上，我们仍旧需要在日常做好监控工作。
攻击面核查
强制访问控制
强制访问控制（Mandatory Access Control, MAC）是指每一个主体（包括用户和程序）和客体都拥有固定的安全标记，主体能否对客体进行相关操作，取决于主体和客体所拥有安全标记的关系。
在Docker容器应用环境下，可通过强制访问控制机制限制容器的访问资源。Linux内核的强制访问控制机制包括SELinux、AppArmor等。
内容信任机制
Linux内核能力表示进程所拥有的系统调用权限，决定了程序的系统调用能力。
因此，不当的容器能力配置可能会扩大攻击面，增加容器与宿主机面临的安全风险。
在执行docker run命令运行Docker容器时可根据实际需求通过–cap-add或–cap-drop配置接口对容器的能力进行增删，或者尝试通过配置文件进行统一调整。
构建资管图谱
枚举初始镜像内的软件包、端口、服务，构建初始清单列表。
如果私有云安全架构体系中，本身可以考虑构建类似于CMDB资产管理的系统，也可以考虑搭配像Dependency-track等工具，核查对于第三方的依赖。
否则的话，可以通过灰盒扫描和流量agent方式，对资产数据库进行补充检查。
同时，一旦出现异常，通过自动化对比初始状态数据，我们也能较快地发现风险。
运行安全
敏感信息检查
核查运行的镜像系统的代码中，是否存在敏感信息泄露：密码、秘钥、token等。
这个问题比较微妙，可能更偏向普适性的安全问题，但作为系统运行时安全，还是要提一下的。
黑盒扫描
在容器中系统的运行时，可能会无意中暴露一些攻击面，因此我们需要选择适当的扫描器进行定期核查。
这里简单例举几个黑盒扫描引擎：
- nessus（网络主机漏洞扫描器）
- awvs（web爬虫扫描器）
- appscan（IBM重量级web扫描器）
- dirscan（web路径扫描器）
- docker-bench-security（官方基线核查脚本）
- anchore（针对容器Docker的CVE扫描）
白盒扫描
白盒扫描的话，同样也可以嵌入CICD流水线进行检查，如果出现问题，对比实际情况（比如命中率）进行阻断和漏洞上报。
当然，如果误报率较高的话，可以仅从旁路记录，等待安全人员审核漏洞是否存在后，再督促业务方修复迭代。
如果扫描规则有更新，也可以日常对代码库进行扫描，匹配筛选出可能存在缺陷的分支进行告警，以便及时更新镜像系统中的代码。
简单例举几类白盒扫描引擎：
- SonarQube（定制安全规则）
- BlackDuck（开源组件检查）
- Findsecbug（开源的findbug安全插件，可作用于编译器和平台）
- Coverity（可以定制安全规则）
- Fortify（误报较多，但覆盖面较全，pj版本多）
- Semmle QL（官方有分析平台lgtm.com）
- KunLun-M（404实验室的开源产品）
安全监控
资产图谱核查
对于在配置阶段获取的清单图谱，需要在系统运行阶段，进行资产定期巡检对比核查。
如果容器中的系统，开放了异常端口和服务，或者安装了异常的软件包，应该对该镜像构建的相关容器系统，通过核实后尽快进行冻结处理。
HIDS监控
在容器系统运行的过程中，如果出现被入侵或者污染的情况，仅凭日常的扫描和事前事中检查，不一定能及时精确的定位溯源。
这时就需要对文件变更进行监控，以及对异常进程及时发现，还有记录异常行为和疑似的后门留存等等。
云厂商们的技术各有千秋，无论是宿主机级别，还是能植入容器的HIDS，都能一定程度上提升容器的安全兜底能力。
容器进程安全审计
在安全审计方面，对于运行Docker容器的宿主机而言，除需对主机Linux文件系统等进行审计外，还需对Docker守护进程的活动进行审计。
由于系统默认不会对Docker守护进程进行审计，需要通过主动添加审计规则或修改规则文件进行。
除Docker守护进程之外，还需对与Docker的运行相关的文件和目录进行审计，同时需要配置审计规则文件（/etc/audit/audit.rules）。
命令示例：
auditctl -w /usr/bin/docker -k docker
容器网络安全
由于Docker容器默认的网桥模式，不会对网络流量进行控制和限制。所以为了防止网络被DoS攻击的风险，需要根据实际需求对网络流量进行相应的控制。
针对openstack的网络：
在同一主机内相同子网中的不同容器之间，可以通过建立的虚拟化集群，通过vlan对不同租户进行子网隔离不同，基于overlay网络的容器集群，默认可以直接访问。
如需控制宿主机外部到内部容器应用的访问，可通过在宿主机iptables中的DOCKER-INGRESS链，手动添加ACL访问控制规则，以控制宿主机的eth0到容器的访问，或者在宿主机外部部署防火墙等方法实现。
针对k8s的网络：
策略可以应用于通过常用标签标识的pod组。然后，可以使用标签来模拟传统的分段网络，这些网络通常用于在多层应用程序中隔离层：例如，您可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。
由于存在频繁的微服务动态变化更新，通过手动的方式配置iptables或更新防火墙是不现实的。因此，可通过微分段（Micro-Segmentation）实现面向容器云环境中的容器防火墙。
微分段是一种细粒度的网络分段隔离机制，与传统的以网络地址为基本单位的网络分段机制不同，微分段可以以单个容器、同网段容器、容器应用为粒度实现分段隔离，并通过容器防火墙对实现微分段间的网络访问控制。
容器认证安全
我们在进行集群的控制时，需要注意做好访问控制，而k8s恰好自带了一套完整的认证授权机制。
-
基于属性的访问控制(ABAC)，基于属性的访问控制(ABAC)定义了一种访问控制范式，通过将属性组合在一起的策略将访问权限授予用户。策略可以使用任何类型的属性(用户属性、资源属性、对象、环境属性等)。
-
基于角色的访问控制(RBAC)是一种基于企业中单个用户的角色来调节对计算机或网络资源的访问的方法。在此上下文中，访问是单个用户执行特定任务的能力，例如查看、创建或修改文件。
-
NODE 授权——一个特殊用途的授权器，根据调度到kubelet所在节点的pod向kubelet授予权限。有关使用节点授权模式的更多信息，请参见节点授权。
-
WEBHOOK 授权——WebHook是当某个事件发生时触发一个HTTP POST的回调;实现webhook的web应用程序将向URL发送一条消息。有关使用Webhook模式的更多信息，请参见Webhook模式。
在进行访问控制时，k8s采用的是链式认证, 每个请求被认证插件验证时，插件会试图将请求与以下属性进行关联：
- api server 认证方式(k8s 的所有访问都是通过 api server)
- https 证书认证: 基于CA根证书签名的双向数字证书认证方式
- http token 认证: 通过一个token来识别合法用户
- http basic 认证: 通过用户名密码的方式认证
- authenticating proxy: 第三方授权协议
当启用多个验证器模块时，第一个模块将成功地验证 “请求短路评估” (request short-circuits evaluation)，如果验证失败，则进行断路操作，api服务器不保证运行验证器的执行顺序。
所有通过验证的用户都会被添加进system:authenticated组。
可以使用authenticating proxy 或authentication webhook与其他身份验证协议(LDAP、SAML、Kerberos、备用x509方案等)集成。
容器及平台日志分析
Kubernetes本身没有提供集群级别的日志管理功能，如想实现集群级别的日志管理有三种方案：
- 在每个Node中运行日志采集代理，将日志收集到集中的日志管理平台。这种方案对应用没有侵入性，是优选方案。
- 在前一种方案的基础上，在每个应用Pod中增加Sidecar容器来实现日志的分离。
- 应用直接将日志输出到统一的日志管理平台，不在本地落地，这种方案对于应用的侵入性较大。
实践过的方式是第一种，一般k8s集群的容器日志都存储在/var/lib/docker/。所以简单来说，本方式就是在每个node上各运行一个日志代理容器，对各个节点/var/log和/var/lib/docker/containers/两个目录下的日志进行采集，然后汇总到elasticsearch集群，最后通过kibana展示。
至于中间流程的规则筛选和检测策略，可以借助自定义或者Sisdig之类工具的规则来配置。
市场方案调研
当然，大家如果预算足够的话，可以直接采购整套云管平台和配套资源。 我前面所描述的东西，在大点的云服务厂商那里，基本是都可以满足的。
国内厂商部署方案
近期由于接洽项目的需要，对接触过的几家国内的厂商容器安全方案进行过调研。
其中包含云厂商，也有传统安全厂商，笔者对其中部分指标进行了简要统计，这里暂不讨论未接触过的其他优秀厂商。
这里仅针对公开信息披露进行展示，不做具体的优劣评价，可能存在错漏和沟通失误的情况，欢迎各路大佬斧正。
另外，这里给个小建议，如果公司预算比较充裕，可以入手头部云厂商的产品进行环境自建。否则可以考虑采购二线云厂商+传统安全厂商，也能达到既定的大部分效果。
如果收尾的架构设计中，还剩下一些低性价比，但是不得不上的资源。届时手中的业务方研发能力足够作为补充的话，可以二改和对接开源的系统，逐步推进实施落地。
另外，需要特别注意业务方的需求，云环境的要求是否必须纯粹，是否需要等保等级规划，不同的需求成本差别可能会很大。
这里附上调研过的几家厂商能力矩阵，不代表本人观点，如有错漏欢迎指出：
| 安全能力 | 阿里 | 腾讯 | 华为 | 深信服 |
|---|---|---|---|---|
| 隔离沙箱 | ACK安全隔离沙箱 | 未知 | 仅数据沙箱 | 未知 |
| 基线检查 | 安骑士 | 未知 | HSS | BVT |
| 漏洞检查 | CSS | VSS | VSS | 传统漏扫 |
| 资产核查 | 资产管理（专有云）+指纹核查（企业版） | 云资产管理中心 | ROMA资产中心 | 未知 |
| 主机安全 | 安骑士 | CWP | HSS | EDR |
| 密钥管理KMS | KMS | HSM | HSM | 未知 |
| 是否支持纯私有云 | 不支持 | 支持 | 不支持 | 可配合采购 |