企业容器云平台的安全性设计建设方案参考指引

企业容器云平台的安全性设计建设方案参考指引

导读本文主要从容器云平台云平台运行时，管理平台、应用镜像构建、应用部署运行监控、租户管理、4A管理、行业规范、最佳实践方面讲述容器云平台的安全设计，突出容器安全设计与建设是系统工程，是需要从下层到上层，从平台到应用，从理论到实践都要仔细考虑的，通过本文的介绍用户可以得到如下收益：第一，安全建设的概览图；第二，安全建设的实施建设方案，可以能比较好的给同业在容器安全实施建设上从哪些方面进行设计以及如何实施参考。第三，获得安全建设的工作指引，起到授之以渔的目的。一、容器云平台概述近年来，云计算的模式逐渐被业界认可和接受。在国内，包括政府、金融、运营商、能源等众多行业以及中小企业，均将其业务进行不同程度的云化。PaaS平台服务作为云计算三大服务之一，是近几年市场份额同比增长最快的云计算服务。近年兴起的容器技术凭借其弹性敏捷的特性和活跃强大的社区支持成为了推动PaaS发展的核心技术。基于容器技术构建的PaaS平台也称为容器云平台。容器技术在操作系统层面实现了对计算机系统资源的虚拟化，在操作系统中，通过对CPU、内存和文件系统等资源的隔离、划分和控制，实现进程之间透明的资源使用。容器云平台是通过容器编排引擎及容器运行时等技术提供应用运行平台，从而实现运维自动化、快速部署应用、弹性伸缩和动态调整应用环境资源，进而提高研发运营的效率，目前市场上主流的容器云平台是基于GoogleKubernetes（简称k8s）容器编排引擎和容器引擎建立。本文中介绍内容也是针对此类的容器云平台。说明：1、容器云平台本身的单点故障是一大安全隐患，但本文不涉及如何设计一个高可用的容器云平台。2、RedhatOpenShift方案是RedHat的企业级增强发行版本，是一个很好的部署版本，核心原理和开源版本相同，但本文不刻意针对OpenShift发行版本进行介绍。本文主要从容器云平台云平台运行时，管理平台，应用镜像构建，应用部署运行监控，租户管理，4A管理，行业规范，最佳实践方面讲述容器云平台的安全设计，突出容器安全设计与建设是系统工程，是需要从下层到上层，从平台到应用，从理论到实践都要仔细考虑的，通过本文的介绍用户可以得到如下收益：第一，安全建设的概览图；第二，安全建设的实施建设方案，可以能比较好的给同业在容器安全实施建设上从哪些方面进行设计以及如何实施参考。第三，获得安全建设的工作指引，起到授之以渔的目的。

二、容器云平台风险及挑战举例作为平台级的容器环境，比以往任何的基础架构平台更加的接近业务，同时也包含了更多的层级和组件，因此也带来了更多的风险；目前容器安全也是一个信息安全的新兴领域，该领域的技术和产品也在不断完善中，下面我们先从风险的角度列举几个常见的例子，让大家对容器平台安全有个感性认识：-软件漏洞风险容器的设计虽然实现了良好的操作系统级隔离，但同时也存在很多安全隐患，比如容器是运行在宿主机上的一种特殊的进程，那么多个容器之间使用的就还是同一个宿主机的操作系统内核，其次在Linux内核中，有很多资源和对象是不能被Namespace化的，最典型的例子是：时间，即如果某个容器修改了时间，那整个宿主机的时间都会随之修改，非计划内的修改系统时间，对于时间敏感的应用可能引起数据错误甚至进程crash，老版本Oracle数据库就存在这样的问题。Kubernetes作为容器编排引擎，如果在规划和部署架构方面存在缺陷，同样会和传统环境一样容易受到外部攻击者和具有恶意的内部人员的攻击。因此，需要保障大型容器云环境具有正确的安全部署体系结构，并为应用上云提供安全最佳实践。根据国家信息安全漏洞库的统计，截止2019年1月2日，Docker相关的漏洞共40个，其中包括Apache、RedHat、hyper、boot2docker、Jenkins等厂商产品或开源项目。2018年，Kubernetes生态系统因发现Kubernetes的第一个主要安全漏洞（Kubernetes特权升级漏洞CVE-2018-1002105）而动摇。该漏洞使攻击者能够通过k8sapiserver实现提升k8s普通用户到k8sapiserver的最高权限，然后运行代码来安装恶意软件，进而破坏k8s集群。除此之外还有CVE-2019-11245Kuberneteskubeletv1.13.6andv1.14.2提权漏洞，实现了在通常情况下以容器Dockerfile中指定的USER运行的容器，有时可以以root身份运行（在容器重启时，或者如果镜像先前被拉到节点）。这种情况的出现违反了容器禁止以root（容器内进程运行用户是root）运行的最佳实践。-API安全风险此部分集中关注容器云平台基础组件提供的api服务的安全问题，比如k8sapiserver，如果在构建容器云平台时扩展或者封装了平台管理api，也需要关注并进行加固。Docker很多服务默认监听在UnixSocket上，比如unix:///var/run/docker.sock，为了实现集群管理，还提供了一个远程管理接口的RESTAPI，允许通过TCP远程访问服务。开启没有任何加密和访问控制的DockerRemoteAPI服务是非常危险的。尤其是将默认的2375端口暴露到互联网中，一旦被攻击者发现，攻击者无需认证即可访问到容器数据，从而导致敏感信息泄露，也可以恶意删除容器上的数据，或可进一步利用容器自身特性，直接访问主机上的敏感信息，获取服务器root权限，对敏感文件进行修改并最终完全控制服务器。在容器编排引擎kubernetes通过apiserver服务提供以下能力：1)提供了容器平台管理的RESTAPI接口；2)提供其他模块之间的数据交互和通信的枢纽;3)资源配额控制的入口；4)应用部署的接口。通俗来讲，apiserver就是整个容器平台的入口，任何用户和程序对集群资源的增删改查操作都可以通过apiserver实现。因此，为了保证集群的安全，API-server需要提供完备的安全机制。-镜像安全风险开发者通常会在公共仓库下载镜像，这些镜像一部分来源于开发镜像相应软件的官方厂商，但还有大量镜像来自第三方组织甚至个人。比如一些自由软件，由于开源和自由获取等特性在大量使用，同时由于没有固定商业组织进行支持，此类软件的镜像多数是社区维护，镜像的质量参差不齐，更有甚者，可能镜像就是不怀好意的黑客制作，如果一旦此类镜像在生产环境使用，势必造成安全隐患。此外，在整个应用开发生命周期中，开发人员、测试人员和运维人员都有可能根据不同需求下载并运行第三方镜像，所以在容器运行前进行镜像检查非常重要。-网络安全风险企业内部容器云平台一般在边界上有很强的安全保障措施，但是在容器云平台内部，基于默认的网络模型，比如flannel，各个容器pod节点是扁平的，在横向网络访问隔离方面缺少必要的安全保障，基于flannel方案在容器云平台构建实践中是较普遍采用的网络模型，优势是成熟，简单，但却缺乏访问控制，。企业需要在构建容器云平台时考虑如何增强网络访问控制，进而提升网络安全。容器云平台安全设计典型容器云平台，参照上面平台架构设计，包括如下几部分，从下到上包括分别是：●基础设施●容器云平台基础组件部分●容器云管理平台部分●业务应用部分●平台支持系统部分其中，基础设施部分是容器云平台的基石，提供了容器云平台的运行基础计算、网络、存储资源。此部分和原来传统数据中心运行的情况一致，安全要求也没有明显变化，因此相关安全设计要求参照原来数据中心设计规范进行设计以及实现，不作为容器云平安全设计的重点；容器云平台基础组件部分提供容器云基础功能，主要包括容器运行时实现和编排引擎，其中运行部分包括虚拟化，软件定义网络，软件定义存储，编排引擎主要是kubernetes软件；容器云管理平台部分主要实现了容器平台的核心功能，比如容器调度功能，账户功能（也称租户功能），镜像管理功能，持续集成持续交付部分，此外还包括图形化和命令行管理接口以及方便第三方对接的平台API接口。容器平台基础组件部分和容器云管理平台部分是容器云平台安全设计的关键；业务应用部分，主要是容器平台上部署的业务应用，有些容器云平台也提供了应用市场功能。根据云平台责任分担模型，此部分安全是业务功能实现方提供，云平台给出一定的安全最佳实践指导。平台支持系统部分主要是容器平台自建或者对接的第三方系统，比如日志、监控、告警，代码管理，账户管理等。此部分系统对于容器云平台运行至关重要，但是相关系统的安全设计不在本次重点考虑范围内。容器云平台是一个多模块组成的复杂系统，各个组合模块的安全需要独立设计以及实现，结合上面容器平台的架构，给出容器云平台安全设计架构图，如下：三、基础安全设计1）容器运行时安全容器运行时通常会给管理员提供多种配置选项。容器运行时配置不当会降低系统的相对安全性。例如，在Linux容器主机上，经允许的系统调用集合通常默认仅限于容器安全运行所必需的调用。如果该列表被扩大，则被入侵的容器会让其它容器和主机操作系统面临更大风险。同样，如果容器在特权模式下运行，则可以访问主机上的所有设备，从而让其本质上成为主机操作系统的一部分，并影响在主机操作系统上运行的所有其它容器。运行时配置不安全的一个示例是允许容器在主机上挂载敏感目录。容器通常很少会对主机操作系统的文件系统进行更改，而且几乎不应该更改控制主机操作系统基本功能的位置(例如，Linux容器的/boot或/etc、Windows容器的C:Windows)。如果允许遭到入侵的容器更改这些路径，那么，也可以被用来提权并攻击主机本身以及主机上运行的其它容器。（1)安全基线容器运行时安全需要满足必要的配置基线，关于基线建设包括：建设安全基线（参照附件5和6）持续改进建设安全基线检测自动化工具建设容器资产清单工具，实时洞察容器运行状况。（2)容器运行风格选择容器运行风格方面，其实有多种选择，采用何种容器运行风格也是安全考虑的问题之一：常见运行风格：瘦容器(ThinContainer):单进程应用的封装，在镜像中打包应用。这非常适于微服务架构应用的服务交付。胖容器(FatContainer):多进程应用的封装，在镜像中打包应用。容器引擎对进程管理的特殊性，我们会利用init.d/systemd或者supervisor等来启动管理进程。但是容器应该尽可能是单一目的，容器中的进程应该是紧耦合的，并有一致的生命周期。比如可以将“nginx”和“php-fpm”打包在一个容器镜像中。VM容器(VMContainer):是利用容器模拟轻量级虚拟机:镜像本身不包含应用，需要利用在容器启动后动态安装和配置应用。这是不建议的方案，会造成容器中应用配置管理和更新的复杂性。如业务应用暂时无法改造，需要制定过渡方案。一般而言，不建议选择VM容器风格。2）Kubernetes运行时安全目前主流的容器云管理平台一般基于kubernetes构建，kubernetes平台采用分布式架构方式构建，根据平台功能由多个组件组成，如下图。典型的组件包括apiserver，etcd，sheduler，controllermanager，kubelet，kube-proxy，cAdvisor，Pluginnetworks（比如flannel）等。

以上组件是容器云平台的控制（管理）平面，是容器云平台的大脑，全面洞察集群上的每一个容器和pod，并且调度新的pod，读取和存储集群中的所有私密信息，因此在通讯和数据存储和传输方面均需要严格安全包括，主要措施包括：-组件安全基线Kubernetes安全运行需要满足必要的配置基线，关于基线建设包括：建设安全基线（参照NIST规范，CISbenchmark）持续改进建设安全基线检测自动化工具-组件之间通信加密为了实现组件之间的安全，设计要求组件之间应该启用TLS，支持TLS以防止流量嗅探、验证服务器身份以及（对于相互TLS而言）验证客户端身份。需要开启的TLS通讯包括：APIServer和etcd之间APIServer和ControllerManager之间APIServer和Scheduler之间APIServer和Kubelet之间平台管理用户和APIServer之间Kubelet和容器之间业务用户和业务pod之间（可选）参考下图：3）网络安全-网络隔离K8s的网络策略应用于通过常用标签标识的pod组。然后，使用标签来模拟传统的分段网络，这些网络通常用于在多层应用程序中隔离层：例如，可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。简单路由网络或常用的flannel网络程序本身不能应用网络策略。目前Kubernetes只有几个支持网络策略的网络组件：Romana，Calico和Canal；其中Weave在不久的将来指示支持，RedHat的OpenShift包括了网络策略功能。因此如何容器云平台基于OpenShift构建会获得OOTB的网络策略功能。从网络模型的流行度来看，flannel的网络方案最流行，市场占有率较大，基于calico+networkpolicy的方案逐步成熟中，可以持续跟进，在容器云构建中可以在测试环境中进行验证。在一些落地的方案中，容器云平台建设过程中采用flannel的方案，但是通过为不同安全级别的应用（租户）建设不同的集群而实现应用（租户）网络隔离。-南北向流量的安全对于南北向的流量，应该引入传统的网络流量分析控制设备，例如IPS/IDS/审计/NGFW/WAF等。-东西向流量的安全东西向流量的安全也是非常关键的，目前可以采用的技术和产品比较少，但这个方面却是非常关键的安全控制点，在没有合适的产品可以替代的情况下，应该尽量：1、采用MiniKnernel的容器化操作系统；2、非特权用户运行容器；3、采用强制访问控制技术；4、监控宿主机文件系统的变更；5、保持系统和组件的安全补丁为最新。四、管理安全设计1）管理平台安全建设-建立专属CA中心，定期替换密钥在组件TLS加密通讯的关键因素是证书的安全，默认情况下，kubernetes集群搭建使用的私有CA，并且生成临时的证书进行TLS加密通讯，但是为了保障TLS的有效性，保障CA更证书的私密以及以及降低组件证书的泄漏风险，因此建议集群的专属CA中心，并且设置组件证书的有效期，在组件证书快到期的时候进行替换。2）用户权限安全管理容器云平台的4A（即认证Authentication、账号Account、授权Authorization、审计Audit）管理功能设计。-构建统一账户管理平台（UIMS）容器平台是一个多组件组成的平台系统，每个组件自成系统，比如镜像管理，CI/CD平台，日志系统，监控系统等，每个系统单独管理各自的用户数据容易行成信息孤岛，分散的用户管理模式阻碍了平台的协调工作，因此构建统一的标准化账户管理体系将是必不可少的。统一账户系统平台可带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件。基于『统一身份治理』的概念，可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类，个人实体从属于组织实体，也可以不从属任何组织实体，且个人实体可同时从属于多个组织实体；基础权限模块将各业务系统的资源权限进行统一管理和授权；基础信息模块用于描述组织实体和个人实体的基本信息，如组织实体名称、地址、法人，个人实体姓名、电话号码、性别等基础信息。此外统一账户系统提供统一的API与其他系统对接。对于账户的口令需要建立严格的管理机制，因为一个好的口令策略是防止未授权访问的一个最重要的安全屏障，减少弱口令风险是提升系统安全性的投入产出比最高的方式。建设过程中需要对容器云平台，组织实体，个人实体等账户的口令进行分类，建立平台超级管理员口令，组织管理员口令，个人实体口令管理办法，典型的云平台超级管理员口令的安全性要求最高，组织管理员次之，个人实体口令要求相对低一些，因此口令的管理措施也不同，比如云平台超级管理员需要建设基于硬件的一次性密码或者双要素密码认证机制，组织管理员密码需要建立一次性密码或者双要素密码认证机制，个人实体密码需要满足一定密码复杂度要求。典型口令策略，举例：密码至少由8个字符组成，应该混合数字、大写字母、小写字母，以及特殊字符等；所有系统管理员级别的密码必需每三个月更换一次，并依照规定进行存档备份。普通个人密码六个月更换一次。用户所使用的任何具备系统超级用户权限账号密码必需和这个用户其他账号的密码均不相同。重要的系统密码比如云平台超级管理员，组织管理员采用一次性密码或者双要素密码认证。UIMS系统支持完备口令使用，变更，修改，注销等生命周期管理能力。另外需要通过管理规定，严格要求密码使用时注意保护，比如不要把自己密码共享给他人，不要在email中写密码，不要给你上司密码等。技术实现方案方面，可以通过MicrosoftAD，OracleIdentityManagement，OpenLdap等软件实现。在一个成熟企业内部基本上已经具备类似系统并且稳定运行。因此此对于容器云平台建设来说主要是统一对接，统一纳管，统一管理的问题。如果企业内部没有需要单独设立子项目建设UIMS系统。-构建统一身份认证平台SSO容器云平台实现统一身份认证和传统应用原理一样，区别在于kubenetes支持的身份严重方式有不同要求，常见的统一身份认证方式归纳为以下两类：传统的Cookie+Session解决方案，有状态会话模式；基于令牌/票据的解决方案，无状态交互模式。具体有：分布式SessionOAuth2.0JWTCAS上述方案各有利弊：分布式Session是老牌的成熟解决方案，但因其状态化通信的特性与服务提倡的API导向无状态通信相互违背，且共享式存储存在安全隐患，因此微服务一般不太采用。OAuth2.0是业内成熟的授权登录解决方案，然而OA2.0提供了4种授权模式，能够适应多种场景，作为基于令牌的安全系统，可以广泛用于需要统一身份认证和授权的场景。JWT（JSONWebToken）是一种简洁的自包含的JSON声明规范，因其分散存储的特点而归属于客户端授权模式，广泛用于短期授权和单点登录。由于JWT信息是经过签名的，可以确保发送方的真实性，确保信息未经篡改和伪造。但由于其自包含的客户端验签特性，令牌一经签发，即无法撤销，因此单纯采用JWT作为统一身份认证和授权方案无法满足帐号统一登出和销毁、帐号封禁和解除这几种类型的需求。CAS是时下最成熟的开源单点登录方案，包含CASServer和CASClient两部分。CASServer是一个war包需要独立部署，负责用户认证；CASClient负责处理对客户端受保护资源的访问请求，需要认证时，重定向到CASServer。值得注意的是，CAS是一个认证框架，其本身定义了一套灵活完整的认证流程，但其兼容主流的认证和授权协议如OAuth2、SAML、OpenID等，因此一般采用CAS+OAuth2的方案实现SSO和授权登录。Kubernetes有三种主要的身份验证方法，用于和API进行交互。官网列出了更多的认证方法，但以下三种是用户认证常见的方法。静态密码X.509客户端证书OpenIDConnect（OIDC）其中，OpenIDConnect基于OAuth2.0协议。结合kubernetes的支持能力以及常见的方案，容器云平台SSO参照实现方案可以采纳Dex或者Keycloak。-构建最小权限授权管理机制所有对容器云的访问均通过kubernetesapiserver实现，其中访问控制的规则也是在apiserver进行设置，在最新的Kubernetes中ABAC（基于属性的访问控制）已被RBAC取代，ABAC不建议apiserver上启用，需要使用RBAC，启用方式是：除此之外还有以下模式：--authorization_mode=AlwaysDeny--authorization_mode=AlwaysAllow--authorization_mode=ABAC--authorization_mode=Webhook--authorization_mode=Node容器云平台RBAC授权管理机制涉及的概念包括：a)访问对象定义：K8s对集群内部的对象以及对象上有的操作进行了规范，比如对象包括（不含CRD对象）：PodsConfigMapsDeploymentsNodesSecretsNamespacesb)对象操作定义：资源对象的可能存在的操作有：creategetdeletelistupdateeditwatchexecc)角色/集群角色定义：角色是针对以上资源上的一组操作的集合k8s对于role进行了区分，分为角色（Role）和集群角色（ClusterRole），其中在角色Role中，定义的规则只适用于单个命名空间，也就是和namespace关联的，而ClusterRole是集群范围内的，因此定义的规则不受命名空间的约束。d)用户/服务账户/组定义：在Kubernetes集群中有存在两类用户：serviceaccounts：由Kubernetes进行管理的特殊用户；user（普通用户）：普通用户是由外部应用进行管理的用户。Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin对于普通用户，Kubernetes管理员只负责为其分配私钥。普通用户可能来自于Keystone或ldap中，或者甚至是存储在文件中的用户名和密码列表。在Kubernetes中，没有表达普通用户的对象，因此，也就不能通过API将普通用户添加到集群中。而ServiceAccount是由KubernetesAPI管理的用户，它们被绑定到特定的命名空间中，并由API服务器自动创建或通过API调用手动创建。ServiceAccount与存储在Secrets的一组证书相关联，这些凭据被挂载到pod中，以允许集群中进程与KubernetesAPI进行通信。API请求要么来自于普通用户或ServiceAccount，或来自于匿名请求。这就意味着集群内外部的所有进程（从来自于用户使用kubectl输入的请求，或来自于Nodes中kubelet的请求，或来自控制板的成员的请求）都需要进行认证才能与APIserver进行交互。e)角色绑定/集群角色绑定定义：RoleBinding和ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的Subject和我们的Role进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding只会影响到当前namespace下面的资源操作权限，而ClusterRoleBinding会影响到所有的namespace。在有以上定义的基础上，容器云平台的基于rbac管理模型下的权限管理方式：某一用户（serviceaccount或者User）通过角色绑定定义了该用户具有哪些角色，该角色详细记录具有对哪些对象的那些操作，即改用户具有了对哪些对象进行哪些操作的能力。在容器云平台授权管理部分还是和传统应用一样，一定授权秉承最小权限原则，对于用户的权限进行最小化设置，并且对于用户的权限进行周期性review、及时清理比不必要的用户和权限定义。小提示：关于如何实为集群服务设置RBAC策略的最佳实践，以及归纳典型设置可以使用audit2rbac，从审计日志提取细粒度的RBAC策略。-开启审计功能（非强制）审计功能主要包括两部分内容，一个是k8sapi调用审计，一个是管理平台页面操作审计，审计记录均以日志的形式上收到日志平台统一管理，其中api审计日志通过开启k8saudit功能实现，管理平台的审计日志通过管理平台的实现方自定义实现。其中apiserver（kube-apiserver.yaml）开启audit日志的方式是：

审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的审计级别。已知的审计级别有：None-符合这条规则的日志将不会记录。Metadata-记录请求的metadata（请求的用户、timestamp、resource、verb等等），但是不记录请求或者响应的消息体。Request-记录事件的metadata和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。RequestResponse-记录事件的metadata，请求和响应的消息体。这不适用于非资源类型的请求。目前对于容器云上的APIServer审计日志的支持，推荐的日志采集的方式是通过日志采集平台将数据采集到日志中心，通常日志中心是基于大数据理念建设的海量数据存储平台，审计日志的查询配合特定索引进行根据关键字的查询，审计日志保存内容以及保存时间需要遵从相关行业规定，通常日志内容需包含时间、用户、操作模块、操作行为等信息，同时建议在线日志保存一个月以上，此外定期对审计日志进行备份存档（三级系统归档日志至少保存3个月）；3）租户资源访问安全根据上面容器平台的架构图，我们可以发现容器底层资源是以池化的方式供上层应用进行消费使用的，通过云平台支持多租户模型，提供了多个业务主体应用并行运行的能力，其实这也是云平台的关键特征之一。共享的现状为业务的运行提供弹性伸缩的能力，可以实现对多个业务压力削峰填谷的效果，最大限度的提升了资源的利用率。但是共享也带了来一定的隐患，比如恶意访问，资源恶意抢占等，因此容器平台需要实现容器资源隔离的能力，目前kubernetes提供的能力包括：（1）资源的访问隔离通过namespace机制对容器云平台进行多租户资源隔离，租户内基于RBAC模式的授权模式进行资源的访问控制。（2）对于资源请求量方面，admissioncontrol是一种多维度可扩展的资源管理机制，每个维度通过一个admissioncontrol插件实现。与Kubernetes用户认证与授权模块一样，对admissioncontrol的调用也是由apiserver来完成的。目前支持的admissioncontrol插件，分别是NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,RuntimeClass,ResourceQuota以上插件按需激活使用，比如：（3）Nodeselector机制此设置是资源隔离的一种方式，但此方式并不是平台构建层面需要考虑的措施，需要以规范或者最佳实践的方式通知应用部署人员，按照规范部署实施。此功能原理是让kubernetes集群调度器根据nodeselector的设置为pod资源选择某个节点（如果未设置，默认是调度考虑的是资源足够，并且load尽量平均）。（4）网络隔离网络资源在集群层面也是共享的，相关的隔离措施见前面部分。-单集群和多集群在某些行业中比如金融业，监管部门要求一个业务的前端，后端需要部署在不同的网络区域中，因此容器云平台在建设过程中，需要考虑集群跨网断或者多集群部署的问题，此外随着一个集群的业务不断增加，也需要在容量上做对集群拆分。因此在构建容器云平台时建议规划好集群的部署形式。建议：不同环境部署多个集群，比如UAT测试，SIT测试，性能测试。不同网络区域部署多个集群，比如DMZ区域，业务后台区域。不同地域部署多个集群，比如生产区域和灾备区域。不同业务安全级别的应用部署在不同集群。单个集群不能太小，同时也不能太多，建议不超过128台物理主机（48c/256G）。4）组件安全Kubernetes平台本身是一个可扩展的平台，通过CNI支持不同的网络组件，通过CSI支持不同的存储组件，此外通过CRD能力支持不同的客户化资源定义，常见的功能扩展比如CI/CD，日志，监控，告警。以上组件通过CRD的方式部署在kubernetes集群内，扩展了容器云平台的能力，此外在应用层面，微服务运行组件也以组件的方式部署在容器云平台上。比如SpringCloud，istio等微服务框架，因此以上组件的安全需要进行相关的设计，鉴于容器云平台的建设规模，各个容器云平台的组件也不相同，本文中以最基本的CI/CD组件为例介绍组件的安全设计要求：（1）数据与环境隔离：不同项目、不同团队的数据要保证隔离，一个项目的多套环境，多套介质同样要保证隔离，比如介质库，首先各项目的介质库要隔离，一个项目的开发库、测试库、投产库同样要隔离，测试通过的介质，则通过可控的同步手段发到投产库。另外比如部署引擎，什么引擎可针对什么环境进行部署操作，也是严格控制的，防止环境操作越权。（2）UI与API的权限控制：对界面的菜单、按钮进行权限控制，对后台api的访问权限进行权限控制，其中账户部分需要对接统一的LDAP系统。（3）可审计：对于什么人在什么时候在平台上做了什么，在动作前后资源产生了这样的变更，比如部署的操作，什么人审批还是可自动执行，部署完成后由谁确认（亦或是通过自动化测试确认），这些关键事项，需要结合不同团队的实际情况进行不同的个性化配置。（4）平滑升级：组件的升级应该不影响容器云平台的影响。五、应用安全1）容器镜像安全众所周知，应用在容器云平台存在的形式时镜像，因此容器镜像的安全是应用安全的基础，对于容器镜像安全主要包括两部分内容，镜像介质安全和镜像运行（策略）安全。镜像介质安全每个容器镜像都是由一系列的“镜像层”组成的，为了保障使用的镜像是纯净的、未被污染的，需要对其解包后安全分析扫描以发现安全漏洞。从CVE漏洞、NVD漏洞，木马病毒、可疑历史操作、敏感信息泄露以及是否是可信任镜像等多个维度对镜像文件进行深度分析。因此镜像安全必须构建一套完整的镜像安全扫描设施。另外镜像作为应用的存在形式，镜像需要在开发环境，测试环境，生产环境间进行传递，并且根据镜像的不同生命阶段，镜像会存在镜像库中和下载运行宿主机上。因此在镜像传递和镜像保存方面需要考虑镜像的一致性问题，需要有必要的手段防止镜像被篡改。镜像运行（策略）安全容器云平台应需要支持在容器启动过程中，当发现有安全问题的容器镜像时，通过禁止容器运行来达到系统安全运行的能力，容器平台需要支持的安全策略如下（部分）:发现镜像以root用户运行禁止运行发现镜像有指定的安全级别的漏洞禁止运行发现镜像内有指定某CVE漏洞禁止运行发现镜像内有木马病毒禁止运行发现镜像内有特定的软件包版本禁止运行发现镜像内有非信任镜像禁止运行发现镜像内有私有证书禁止运行以上能力需要在基础容器云平台能力的基础上进行增强实现，另外可以通过采购业内相关产品实现，如果构建容器云平台有厂商支持，此部分也可以作为POC的关注点。-镜像库建设对于镜像库建设方案包括：1）采用商用的镜像仓库，并且启用镜像漏洞扫描功能。2）自建镜像仓库，但是构建一套完整的镜像扫描工具，对于镜像进行离线扫描，并且形成整改措施。镜像仓库对于容器云平台来说至关重要，因此镜像库安全需要从以下方面进行考虑：（1）与容器云平实现统一账户管理，支持多租户管理。（2）支持TLS加密访问，访问权限控制以保证镜像安全。（3）冗余、高可用的架构，数据持久性，支持全链路数据加密，保障数据安全。（4）拥有海量的存储能力，随时随地可以实现对容器镜像的下载、管理。-镜像签名对于镜像一致性保障方面，一般的方案建立镜像签名机制。容器镜像签名允许用户添加数字指纹到镜像中。这个指纹随后可被加密算法测试验证。这使得容器镜像的用户可以验证其来源，进而防止了镜像的恶意篡改，可行的方案有DTR（DockerTrustRepository）/DCT（DockerContentTrust）方案和harbor/notary方案。DTR/DCT方案中，镜像校验和用来保证镜像的完整性，以预防可能出现的镜像破坏。registry下的每一个镜像都对应拥有自己的manifest文件以及该文件本身的签名。其中的信息包括镜像所在的命名空间、镜像在此仓库下对应的标签、镜像校验方法及校验和、镜像形成时的运行信息以及manifest文件本身的签名。2）应用配置安全Secret应用启动过程中可能需要一些敏感信息，比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥，Kubernetes提供的解决方案是Secret。Secret会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret会以Volume的形式被mount到Pod，容器可通过文件的方式使用Secret中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。常见敏感信息包括关键的环境变量，比如数据链接密码信息，TLS证书信息，镜像库认证信息等。Vault众所周知，即使使用了k8ssecret进行敏感信息的保存，其实默认情况secret的信息只是做了base64编码，通过k8sapi还是可以获得secret存储的敏感信息的，Vault产品作为企业级的secret管理工具，满足了客户在业务上云过程中的安全强需求。因此建议在容器云平台建设中进行采用。其主要的应用场景：1、作为部署在Kubernetes集群中的应用对外提供秘钥管理服务，支持与多家主流云厂商秘钥服务以及多种secrets形式的对接，支持多种数据库服务的存储对接，同时支持多种认证形式的对接。2、作为一个公共的加密服务（EncryptionasaService）而不做后端存储的对接，帮助用户应用剥离繁琐的加密加解密逻辑。3、面向政府、金融等对数据安全规格有很高要求的客户，Vault支持基于Two-man原则利用私钥分割算法对后端服务进行加解封，并结合k8s的高可用部署形态为企业提供更加安全可靠的secret管理能力。Vault作为一个在Kubernetes集群上直接运行的安全应用，任何一个面向k8s的应用工具都可以利用其安全能力。3）容器服务访问安全业务应用在容器云平台中Service的方式存在。Service是Kubernetes最核心的资源对象之一，通过它可以为一组具备相同功能的容器应用提供一个统一的访问入口地址，并将请求负载分发到后端的各个容器应用上。这一点与传统IT基础架构中F5等负载均衡设备将访问请求负载分发到后端功能相同的应用上类似，Kubernetes集群中每个节点上运行的kube-proxy其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个pod实例上，并在内部实现服务的负载均衡与会话保持机制。Kubernetes提供了三种主要方案，分别是NodePort、LoadBalancer、Ingress。NodePortNodePort的实现方式是在每个节点上为需要外部访问的Service开启一个对应的TCP监听端口，外部系统用<NodeIP>:<NodePort>可以从集群外部访问一个NodePort服务，NodePort服务会路由到ClusterIP，通过kube-proxy转发至后端的容器，完成对服务的访问。LoadBalancerLoadBalancer是Kubernetes深度结合云平台的一个组件，使用它构建服务时，实际上是向底层IaaS申请创建一个负载均衡来实现。IaaS网络和容器网络在不同云平台的融合方案不同，因此LoadBalancer和云平台的网络方案深度耦合，只能在特定的云平台上使用，局限性较大。IngressIngress可以很好的解决LoadBalancer和NodePort的限制。它由3个组件组成：Ingress策略集、IngressController和反向代理负载均衡器（如Nginx）。Ingress策略集定义了集群外的流量到达集群内的Service的规则。IngressController与Kubernetes的API交互，实时感知后端Service、pod的变化，再结合Ingress策略集生成配置，然后更新反向代理负载均衡器的配置，实现动态服务发现与更新。反向代理负载均衡器对集群外流量进行负载分发。现有的Kubernetes版本已将Nginx与IngressController合并为一个组件Nginx-Ingress-Controller，无需单独部署Nginx。但Kubernetes原生Ingress是一个七层负载均衡技术，仅适用于http服务。另外，其并未解决Kubernetes环境下，不同租户的服务隔离问题。F5CC+VE方案除了k8s原生支持方案以外，F5公司提供了另外一种方案。该解决方案包含2个组件，VE（VirtualEdition）和CC（ContainerConnector）。VE是F5LTM的软件化商业产品，可以安装在虚拟机或者物理机上，其功能与硬件设备完全一致。CC是F5解决方案的一个关键组件，为用户提供了企业级支撑，同时也是开源产品，用户可以根据自己的需要对CC进行功能扩展。该方案利用CC与Kubernetes进行API交互，实现与容器平台的联动，满足容器应用的灵活性需求；配置上采用ConfigMap进行负载均衡策略下发，实现在Kubernetes层面进行F5策略配置工作；网络架构上采用VE直接对集群中的pod进行负载分发，减少网络层次，提升负载均衡性能；同时，通过将Kubernetes的namespace与VE的partition映射，实现不同容器租户负载均衡资源的隔离，此方案架构如下图：以上方案中，F5方案中实现了基于api的TLS证书管理能力以及F5商用产品的负载均衡处理能力，是一种不错的应用安全入访访问控制方案。4）应用证书管理随着零信任安全模型的普及，业务系统实现全站HTTPS化，加密用户与业务间的交互访问已经成为安全的必选项，为了提供业务快速安全的上云的需要，需要在容器云平台上提供一站式SSL证书解决方案，支持包括云上