私有云安全由于其合规性和独立性，不同于公有云和混合云，需要单独定制落地的流程和规划，这里跟大家简单聊聊关于容器安全设计的相关问题。

容器安全综述

容器安全架构设计，可以在其三大关键生命周期阶段进行实施，其中包括镜像安全、配置安全、运行安全。

镜像安全：

在初始阶段对镜像本身做把控，从供应链进行核查，在日常会对镜像做验证和校验，最后会在构建时进行阻断或者检测。

配置安全：

对于构建好的初始镜像，需要遵从行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扫描