如何从 9 个层次保障容器云平台的安全？

安全是一个非常非常重要但又是一个比较大的命题，涉及到方方面面。采用了容器云平台，主要涉及什么样的安全问题？容器云安全该怎么做？基于我们容器云平台的层次架构，我考虑从容器云的不同层次来看下容器云涉及的安全问题。

容器云的底层是基础设施资源层，包括主机计算节点、网络、存储等资源共同构建容器云集群；基础设施资源层上运行的是容器和容器调度管理组件，比如Kubernetes、Mesos、DockerSwarm等；容器引擎运行在主机节点上，通过容器调度管理组件来实现容器的资源分配、限额、调度管理等能力；业务服务运行在容器中，每个服务可能对应着若干个服务实例（Pods或容器），所有的服务共同构成了服务层；这些业务服务通过服务编排成为业务应用，为客户提供相应的应用服务。应用服务可以投放到不同的渠道，比如手机app、WEB浏览器、PC应用等。容器云平台涉及这些层次，有很多个组件，每一个地方都涉及安全问题，所以安全其实是一个非常难handle的问题。人的思维总是会有局限、有漏洞，要想绝对的安全真的是比登天都难，不过我们尝试来力所能及的通过对这些层次分析来考虑安全问题，可能这也是比较容易理解和简化容器云的安全问题，更容易采取相应的措施以加强安全。

容器云平台层次（借用网上图片）

一、基础设施资源层安全

基础设施资源层为容器云平台供给资源。理论上基础设施资源层资源应该由IaaS来提供，但目前还存在一些技术难题，暂时还不能完全满足容器云的资源需求能力。所以大多数情况下我们基于虚拟化层之上或者直接使用物理机来搭建容器云集群。虚拟化做了一层隔离，多一层安全保证，但性能损失比较大。但从安全角度考虑，性能好的物理机可以考虑做一层虚拟化，有所得有所失，可以根据实际情况选择。

除了容器节点，这一层的安全涉及网络安全和存储安全。Kubernetes提供了一种网络策略，不过目前只是支持Calico、Romana、Weave Net等，网络策略说明一组 Pod 之间是如何被允许互相通信，以及如何与其它网络 Endpoint 进行通信。网络策略资源使用标签来选择 Pod，并定义了一些规则，这些规则指明允许什么流量进入到选中的 Pod 上。默认情况下，所有Pod之间是全通的。每个Namespace可以配置独立的网络策略，来隔离Pod之间的流量。网络策略通过使用标签选择器（包括namespaceSelector和podSelector）来控制Pod之间的流量，比如创建一个可以选择所有 Pod 但不允许任何流量的隔离策略，这确保了即使是没有被任何网络策略选中的 Pod，将仍然是被隔离的。（详细内容请查看Kubernetes文档 Network Policies）

其他网络模式目前还不支持网络策略。Kubernetes集群网络模式跟Docker Swarm不一样。Kubernetes在创建集群时需要安装Pod网络插件，一个集群只能安装一种Pod网络；Docker Swarm网络可以在使用时创建。从容器云平台来说，不管通过网络策略或者其他方式能实现一层网络隔离，安全性会更高。当然，按需而定。

对于容器云存储安全，和使用具体的存储技术有关。数据安全对任何一家企业都是重大的事情。所以一般考虑数据不能放在容器内存储上，包括日志数据。数据需要及时备份、采集到节点存储或共享存储或外部数据中心。

二、容器管理调度层安全

容器管理调度层安全主要涉及容器调度、容器生命周期管理等。容器调度可以采用亲和性、反亲和性策略等，确保容器调度到合适的节点上。这特别在弹性伸缩的时候，确保容器实例均匀分布于不同节点上。避免容器集中而导致节点资源耗尽或紧张，这也可以通过对节点资源使用情况和服务的响应时间等的实时监控来及时自动调整。

容器云弹性伸缩我们也讨论过，“伸”相对容易，“缩”就要确保业务请求被处理完毕才能收回资源。这可能需要结合负载均衡策略，确保没有新的请求的到来，等待所有请求被处理完毕之后回收容器资源。

除非容器异常，容器的迁移、删除、重启也面临着这样的问题。特别金融行业涉及资金的问题，需要确保数据不丢失、不重复。当然，不能只依赖于容器，也需要考虑业务逻辑和事务机制来保证安全。容器异常导致请求处理中断，需要有相应的措施保证请求能被处理并且不被重复处理。

容器的操作可以通过API来实现，Kubernetes支持多种API安全访问策略，Node、ARAC、BRAC、Webhook等。提供授权、认证、准入机制。但需要明白的是，Kubernetes这些访问控制机制不等于容器云平台的访问控制机制，只是容器云平台一个组件的访问控制机制，所以容器云平台必须有建立自己的权限、认证、访问控制能力。Kubernetes的访问控制如何映射到容器云平台的访问控制能力，是容器云平台需要考虑并解决的问题。

三、容器引擎和容器安全

容器引擎通过Linux系统安全策略来实现。不同的容器引擎实现的能力不同。Docker支持Namespace隔离性，Cgroup配额资源限制，Capability权限划分，SELinux/AppArmor访问控制权限。Kubernetes通过API可以实现Namespace隔离性、资源分配和资源限额。相当于重新做了一次虚拟化，确保资源不会被某一容器耗尽。

有朋友问到过一个问题，客户私有代码在容器中运行，安全性如何保证？这个我想首先要保证容器资源分配时有配额，在客户的容器中它可以自由折腾，但不能越界，不能逃逸。我们知道Docker等容器引擎需要访问系统资源，有root权限才方便。我们PoC测试时每家厂商都要求root用户权限，这让我们感觉很不靠谱。root用户权限太大，开放root权限可能带来致命威胁。所以我们要求梳理出容器云平台需要root用户权限的所有指令，赋予普通用户身份执行这些指令的权限。为了整个系统的安全，必须严格控制访问权限。所以对于客户私有代码的问题，就不能给它root权限，划分给它一块区域与其他容器和资源隔离，同时配以容器和资源实时监控，确保容器运行安全。

四、服务层安全

服务层就是实现的微服务。微服务的安全包含数据的安全，这里涉及数据治理的问题。我们也一直强调，数据治理能力直接影响着微服务的实现。数据的分类分级、分库分表、存储方式、数据体量、数据质量等都关系着微服务的设计实现及部署方式以及所能提供的服务质量。

微服务接口和通信安全也是重点。通常我们需要部署服务网关来实现对服务接口的管理和访问控制，服务接口也需要实现安全的通信机制，比如SSL/TSL加密。服务网关是一个关键的安全组件，通常这一层需要实现路由、过滤、映射、转换、限流、熔断、容错、服务优先级设置等机制。通过这些机制来保证服务安全和容器云平台的安全。不过需要注意的是服务网关是所有请求应答的出入口，所以其可能会成为一个瓶颈，这一则需要选择合适的产品，二则需要考虑部署服务网关集群或者多集群方式来满足需求。

目前容器云厂商基本都把容器终端console开放给用户。通过容器云平台可以直接打开容器终端，通过命令行操作容器系统指令。这也是非常危险的地方。可能考虑的角度不同，容器云厂商从开发人员角度考虑，有这个终端对开发人员来说比较方便，可以登录查看日志、运行情况等。但是对我们来说这是留了个安全隐患。所以我们要求对容器云租户用户需要关闭这个功能，但需要把容器的日志、容器内应用的日志、容器资源使用、应用运行状况等信息要采集并展示出来，在出现异常的时候能够顺利定位问题并有助于解决问题。当然这个终端可以对容器云平台管理员开放，毕竟特殊情况下是需要登录特定容器。

五、应用层安全

我们在交流的时候跟厂商说过，应用管理和安全是我们考虑的重点。这是容器云平台提供给用户的关键能力。在容器云生产环境不可能使用流水线或CI再去构建镜像，所以需要明确开发测试和生产环境的能力划分。我们建议镜像仓库作为开发测试和UAT/生产的媒介，开发CI流程止步于镜像仓库，镜像仓库保证镜像的安全。

微服务通过服务编排来构建业务应用。企业内应用和外部应用安全机制可能是不一样的。企业内相对安全，服务间通信可以不通过服务网关，不需要太多认证加密，采用消息机制，可以方便的实现异步处理、优先级设置、消息负载均衡等，结合容器的弹性伸缩机制，可以更好的满足业务需求。这样通过技术架构保障，应用多实例部署，实现负载均衡机制，相当于实现了应用的双活/多活部署。

多租户是容器云平台实现权限管理和服务治理的一个重要方面。我们也谈过容器云多租户权限中心设计及容器云多租户服务治理。服务和应用需要按租户进行管理和运维，这既是不同业务条线的要求，也是化繁为间的需求。把服务和应用作为资源，利用租户权限管理来实现服务和应用的访问控制准入机制，是实现应用安全的重要方面。

应用不同的投放渠道，安全要求也不尽相同。面向企业内部使用的和面向客户的，手机应用、PC 端应用、Web浏览器等，采用的措施也要因需而定。兵无定式、水无定形，因时而动，因势而动。这也超出了我们的能力，需要咨询专业的安全团队人员。不过配置API 网关，通常是一个不错的选择。

六、基础组件

容器云平台需要考虑实现统一认证中心和权限中心等基础组件，这是建立企业级微服务平台和微服务生态系统的要求，也是实现单点登录、基于角色的权限管理、授权认证、访问控制等安全能力的要求。

这里需要说明的是，容器云平台的统一认证和对客户的统一认证是两个层次的需求，不能混为一谈。目前由于建设容器云平台微服务生态涉及很多开源组件，大多数组件都有自己的权限管理认证体系，为了统一便利管理，平台各组件权限最好全部打通，成为一个完整的云平台，更好的管理和运维服务。

前面提到的API服务网关也是容器云平台重要的基础安全组件。另外，服务注册发现组件、日志组件、监控组件、告警组件、任务调度组件甚至计费组件等都需要保证部署和访问控制安全。

密码安全，这是避不开的一个话题。集成应用系统、使用中间件服务等都可能需要提供账户密码，密码如何存放？我们尝试使用服务配置中心来管理所有这些配置项，密码加密存放于内存，落地于文件或数据库中是加密后的格式，服务使用密码时通过解密函数来从内存中获取。

七、中间件安全

容器云上业务服务用到的中间件可能会很多。比如消息中间件Kafka、应用服务器Tomcat、数据库中间件MySQL等，在使用这些中间件时，一方面需要考虑中间件本身的安全措施，另一方面也要考虑容器镜像等安全。在使用这些中间件时，要确认中间件版本，避免使用默认配置，特别是生产环境，不同的版本可能需要构建不同的镜像做备用。这些工作可以和厂商共同维护，在公共镜像仓库中提供。
另外可能涉及中间件部署的问题，是部属于容器？还是物理机或虚拟机？我们觉得物理机或虚拟机更好些，我们将在容器云部署一文中详细讨论。

八、镜像安全

容器是镜像的运行时，镜像安全直接影响着容器的安全。病从口入，如果镜像存在安全隐患，容器云平台就面临着威胁。所以镜像仓库的镜像安全扫描能力就显得尤为重要。Docker Cloud和DockerHub提供在线漏洞扫描，CoreOS也提供了Clair开源项目对接CVE库进行镜像的漏洞扫描。目前镜像仓库有多种选择，能力也有些差别。听说DTR是最强的，不过没有比较过。

服务镜像都构建于基础镜像，基础镜像安全涉及镜像、系统、容器运行时三部分安全。系统安全则面临着系统补丁、升级的问题。基础镜像的补丁、升级等可能会带来重新生成镜像的任务。在有很多镜像的情况下，如何管理维护这些镜像也是一个需要考虑的问题。也许通过自动化工具来全部重新打包生成新的镜像，自动实现测试环境部署测试，保证版本一致可能会好些。可能需要在DevOps流程中去保证，但这个度怎么把握我们也没考虑好。

九、DevOps流程安全

持续集成代码安全，不仅指安全的代码存储，也包括编码的安全，预防编码中潜在的漏洞和Sql注入等。实现自动的代码质量检查和代码漏洞检查，自动化测试等能力。这可能也需要结合API Gateway实现过滤等机制。