金融云原生漫谈（六）｜你在用的云原生平台真的安全吗？

在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的进程。

如果以容器云上生产为目标，那么整个容器云平台的设计、建设和优化对于银行来说是一个巨大的挑战。如何更好地利用云原生技术，帮助银行实现敏捷、轻量、快速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的发展，是个长期课题。

本期金融云原生漫谈，将和您聊一聊如何构建安全的云原生平台。

---

以容器和微服务为代表的云原生技术，对于金融行业来说，既是机遇，也是挑战。机遇在于，云原生技术正在助力银行通过差异化业务进行创新，快速获得更多用户的青睐；挑战在于，比任何行业都要强调安全稳定的金融业，如何在飞速更迭的技术环境下，保持稳态业务持续发展的同时，做到既稳又快。

金融行业云原生平台的安全性近年来得到越来越多的关注，为了满足容器的高可靠、高性能的基本保障，安全建设至关重要，但又非常宏观，涉及到方方面面。不仅仅是被动的防御和事后的查漏补缺，也包括态势感知，主动防御等内容，应该作为一个整体去考量和规划。

• 容器安全包括哪几个层面？
• 容器安全防护实践从何入手？
• 如何从全生命周期规避容器化改造过程中的安全问题？

希望本篇文章能带给您启发。

容器安全包括哪几个层面？

Docker和K8s会不可避免地存在漏洞，每次漏洞修复都要大规模升级集群，每次升级有可能对上面运行的容器造成影响，对K8s的运维是非常大的压力。那么我们如何保证容器平台安全呢？

基于云原生平台的层次架构，我们可以从以下4个层面来看待这个问题：

• 在容器及K8s层面，通常需要保证镜像安全、容器运行时安全、容器网络安全、权限安全等问题。另外，可以进一步关注K8s的Pod安全策略PSP。

• 在平台层面，集群隔离、租户安全、用户隔离、网络ACL、审计、DevSecOps、NetworkPolicy、平台高可用、HTTPS接入安全等都是平台从平台层面提供的安全能力。平台自身的漏洞扫描、组件漏洞等问题需要厂商发版前做严格的漏扫，做到有效的处理。很多客户在采购过程中，都会要求厂商提供未来每个版本的安全检测报告。

• 在应用层面，可以通过DevSecOps在开发过程中为应用提供安全保障。另外，平台会提供应用高可用保障、应用安全接入、跨域策略、数据高可用等能力，为应用进一步提供安全保障。通常，我们建议针对面向的互联网应用，可以叠加上前端安全设备的WAF、DDos、防Sql注入等能力将进一步提升应用的安全性。

• 在运维层面，可以采用业务高峰期的重保服务作为保障平台正常运行的另一个策略。

容器安全防护实践从何入手？

云原生安全离不开容器安全，容器的安全防护建议从以下方面开始着手评估和实践：

一、基础设施层

• 操作系统安全：首先需要明确一点，涉及容器云工作节点的操作系统要使用遵循安全准则的操作系统。使用防火墙，端口阻止等安全措施。系统常规安全更新和修补程序在可用后必须立即应用，防止黑客和入侵者利用已知漏洞。使用最小化操作系统，同时精简和平台不相关的预置组件，从而降低系统的攻击面。使用第三方安全加固工具，定义了系统上的应用程序，进程和文件的访问控制等。建立审核和日志记录流程，确保构建平台的所用的操作系统是安全合规的。
• 网络层安全：实现管理平面业务平面流量隔离、最少的端口暴露。
• 存储安全：定时快照和备份并对敏感数据进行加密。

二、平台层安全

• 安全扫描：对容器调度和管理平台本身，需要先实现安全基线测试，平台安全扫描；
• 审计：对平台层用户操作进行审计，同时也需要项目层面的资源和操作审计；
• 授权：对平台实行权限控制，能基于角色/项目/功能等不同维度进行授权；
• 备份：定期备份平台数据；
• 巡检：选用具备自动化巡检能力的平台产品。

三、容器安全

• 镜像安全：容器使用非root用户运行，使用安全的基础镜像，定时对镜像进行安全漏洞扫描；
• 运行时安全：主要是对容器在容器平台上运行过程中的对于宿主机系统以内安全设置，例如容器特权、提升权限、主机PID、主机IPC、主机网络、只读文件系统等安全限制。同时建议具备限制容器对于底层宿主机目录的访问限制。 限制容器对于外部网络端口暴露的范围限制。用户限定某些敏感项目独占宿主机，实现业务隔离；
• 容器网络安全：可以通过Networkpolicy模板，对于所有Pod之间、Namespace和Pod之间等进行IP、端口、标签等细颗粒度的容器安全策略，同时在集群内部为Namespace划分子网、并且对于不同的namespace之间的子网设置白名单，进行访问控制。

如何从全生命周期规避容器化改造过程中的安全问题？

众所周知，容器化改造过程中的安全问题也不容小觑。我们通过观察发现，在过去三年业界也有一些容器失败的案例，基本问题就是：测试业务系统迁移到容器平台过程中，出问题运维团队不能及时处理，导致业务开发人员对容器平台的稳定性、可靠性产生质疑，最终导致项目失败。

因此，为了尽可能地规避这类安全问题，建议在容器化项目实施过程中，先对接现有的运维体系、安全体系和相关工具平台，在整体纳入到现有IT保障体系的基础上，将有限资源聚焦于容器平台的保障上。

再者，因为容器运维与传统运维之间有很大的技术门槛，所以也可以考虑购置专业技术厂商的驻场服务，解决平台的安全加固和平台运维问题。金融企业自己聚焦于容器平台的培训、应用推广等产生IT价值的工作。

综上，云原生平台的安全建设并非一蹴而就，而是一个需要不断完善、迭代积累的过程，后期还会涉及到功能规划、平台运维、升级实施、安全重保、应用迁移、服务改造、流程设计等一系列相关问题，建议金融企业在采购产品的同时，重视服务，采用甲乙双方更加紧密配合的项目建设/服务模式，从金融企业的自身情况出发，有针对性地规避容器化改造过程中的安全问题，平稳且高效地实现金融级云原生平台的安全构建。

我们相信，容器作为云原生的重要组成部分，必将紧跟云原生的发展热潮，向更加安全、可信的方向发展。