作者z778899·2022-11-28 16:07

系统架构师·某股份制银行

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

字数 20505阅读 4673评论 2赞 8

> 本文为云原生应用创新实践联盟—— 容器云安全方向课题组线上交流活动总结，相关协作专家如下所示， 更多内容可[**点击此处进入云原生应用创新实践联盟**](https://cnaipa.talkwithtrend.com/?action-topic-id-403) 进行查看。

> **执笔专家：**  
**圆白菜 课题组特邀外部专家**
twt社区云原生应用创新实践联盟—— 容器云安全方向课题组特邀外部专家 。目前就职银行负责容器安全相关架构师岗位，对容器具有 丰富的实践经验，容器云职业技能大赛百位专家委员会成员。

> **顾问专家：**  
**[社区ID:rechen  容器云安全用户委员会委员](https://www.talkwithtrend.com/home/space.php?uid=1213893 "rechen 容器云安全用户委员会委员")**  
twt社区云原生应用创新实践联盟——容器云安全方向课题组组长，云计算架构师，当前从事银行私有云和公有云基础设施、以及混合云架构的建设，参与包括容器云等相关云服务的规划、技术选型、架构设计和实施，以及业务连续性等保障体系的建设工作。  
**[孙洪轩 容器云安全用户委员会委员](https://www.talkwithtrend.com/home/space.php?uid=1251743 "孙洪轩 容器云安全用户委员会委员")**
twt社区云原生应用创新实践联盟—— 容器云安全方向课题组专家。 多年IT研发经验，近几年一直深耕区块链，云原生等前沿技术领域。先后为集团设计并建设了区块链云服务平台，容器云PaaS平台等中大型项目。具备丰富的软件架构设计，项目落地经验

# 一、容器云平台概述
近年来，云计算的模式逐渐被业界认可和接受。在国内，包括政府、金融、运营商、能源等众多行业以及中小企业，均将其业务进行不同程度的云化。PaaS平台服务作为云计算三大服务之一，是近几年市场份额同比增长最快的云计算服务。近年兴起的容器技术凭借其弹性敏捷的特性和活跃强大的社区支持成为了推动PaaS发展的核心技术。基于容器技术构建的PaaS平台也称为容器云平台。

容器技术在操作系统层面实现了对计算机系统资源的虚拟化，在操作系统中，通过对 CPU、内存和文件系统等资源的隔离、划分和控制，实现进程之间透明的资源使用。

容器云平台是通过容器编排引擎及容器运行时等技术提供应用运行平台，从而实现运维自动化、快速部署应用、弹性伸缩和动态调整应用环境资源，进而提高研发运营的效率，目前市场上主流的容器云平台是基于Google Kubernetes（简称k8s）容器编排引擎和容器引擎建立。本文中介绍内容也是针对此类的容器云平台。

**说明**
1、 容器云平台本身的单点故障是一大安全隐患，但本文不涉及如何设计一个高可用的容器云平台，此部分将在高可用章节介绍。
2、 Redhat OpenShift方案是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）而动摇。该漏洞使攻击者能够通过k8s api server实现提升k8s普通用户到k8s api server的最高权限，然后运行代码来安装恶意软

件，进而破坏k8s集群。除此之外还有CVE-2019-11245 Kubernetes kubelet v1.13.6 and v1.14.2提权漏洞，实现了在通常情况下以容器Dockerfile中指定的USER运行的容器，有时可以以root身份运行（在容器重启时，或者如果镜像先前被拉到节点）。这种情况的出现违反了容器禁止以root（容器内进程运行用户是root）运行的最佳实践。

## - API安全风险
此部分集中关注容器云平台基础组件提供的api服务的安全问题，比如k8s api server，如果在构建容器云平台时扩展或者封装了平台管理api，也需要关注并进行加固。

Docker很多服务默认监听在Unix Socket上，比如 unix:///var/run/docker.sock， 为了实现集群管理，还提供了一个远程管理接口的 REST API，允许通过 TCP 远程访问 服务。开启没有任何加密和访问控制的 Docker Remote API服务是非常危险的。尤其是将默认的2375端口暴露到互联网中，一旦被攻击者发现，攻击者无需认证即可访问到容器数据，从而导致敏感信息泄露，也可以恶意删除容器上的数据，或可进一步利用容器自身特性，直接访问主机上的敏感信息，获取服务器 root 权限，对敏感文件进行修改并最终完全控制服务器。

在容器编排引擎kubernetes通过api server服务提供以下能力：
1)   提供了容器平台管理的REST API接口；
2)   提供其他模块之间的数据交互和通信的枢纽;
3)   资源配额控制的入口；
4)   应用部署的接口；

通俗来讲，api server就是整个容器平台的入口，任何用户和程序对集群资源的增删改查操作都可以通过api server实现。因此，为了保证集群的安全，API-server需要提供完备的安全机制。

## - 镜像安全风险
开发者通常会在公共仓库下载镜像，这些镜像一部分来源于开发镜像相应软件的官方厂商，但还有大量镜像来自第三方组织甚至个人。比如一些自由软件，由于开源和自由获取等特性在大量使用，同时由于没有固定商业组织进行支持，此类软件的镜像多数是社区维护，镜像的质量参差不齐，更有甚者，可能镜像就是不怀好意的黑客制作，如果一旦此类镜像在生产环境使用，势必造成安全隐患。

此外，在整个应用开发生命周期中，开发人员、测试人员和运维人员都有可能根据不同需求下载并运行第三方镜像，所以在容器运行前进行镜像检查非常重要。

## - 网络安全风险
企业内部容器云平台一般在边界上有很强的安全保障措施，但是在容器云平台内部，基于默认的网络模型，比如flannel，各个容器pod节点是扁平的，在横向网络访问隔离方面缺少必要的安全保障，基于flannel方案在容器云平台构建实践中是较普遍采用的网络模型，优势是成熟，简单，但却缺乏访问控制，。

企业需要在构建容器云平台时考虑如何增强网络访问控制，进而提升网络安全。

# 容器云平台安全设计
![](/home/attachment/202211/28/1210417_166962108297975.png)

典型容器云平台，参照上面平台架构设计，包括如下几部分，从下到上包括分别是：
●        基础设施，
●        容器云平台基础组件部分，
●        容器云管理平台部分，
●        业务应用部分，
●        平台支持系统部分。

其中，基础设施部分是容器云平台的基石，提供了容器云平台的运行基础计算、网络、存储资源。此部分和原来传统数据中心运行的情况一致，安全要求也没有明显变化，因此相关安全设计要求参照原来数据中心设计规范进行设计以及实现，不作为容器云平安全设计的重点；容器云平台基础组件部分提供容器云基础功能，主要包括容器运行时实现和编排引擎，其中运行部分包括虚拟化，软件定义网络，软件定义存储，编排引擎主要是kubernetes软件；容器云管理平台部分主要实现了容器平台的核心功能，比如容器调度功能，账户功能（也称租户功能），镜像管理功能，持续集成持续交付部分，此外还包括图形化和命令行管理接口以及方便第三方对接的平台API接口。容器平台基础组件部分和容器云管理平台部分是容器云平台安全设计的关键；业务应用部分，主要是容器平台上部署的业务应用，有些容器云平台也提供了应用市场功能。根据云平台责任分担模型，此部分安全是业务功能实现方提供，云平台给出一定的安全最佳实践指导。平台支持系统部分主要是容器平台自建或者对接的第三方系统，比如日志、监控、告警，代码管理，账户管理等。此部分系统对于容器云平台运行至关重要，但是相关系统的安全设计不在本次重点考虑范围内。

容器云平台是一个多模块组成的复杂系统，各个组合模块的安全需要独立设计以及实现，结合上面容器平台的架构，给出容器云平台安全设计架构图，如下：
![](/home/attachment/202211/28/1210417_166962111817705.png)

# 三、基础安全设计
## 1）容器运行时安全
容器运行时通常会给管理员提供多种配置选项。容器运行时配置不当会降低系统的相对 安全性。例如，在Linux容器主机上，经允许的系统调用集合通常默认仅限于容器安全运行所必需的调用。如果该列表被扩大，则被入侵的容器会让其它容器和主机操作系统面临更大风险。同样，如果容器在特权模式下运行，则可以访问主机上的所有设备，从而让其本质上成为主机操作系统的一部分，并影响在主机操作系统上运行的所有其它容器。

运行时配置不安全的一个示例是允许容器在主机上挂载敏感目录。容器通常很少会对主机操作系统的文件系统进行更改，而且几乎不应该更改控制主机操作系统基本功能的位置(例如，Linux 容器的/boot 或/etc、Windows 容器的 C:\\Windows)。如果允许遭到入侵的容器更改这些路径，那么，也可以被用来提权并攻击主机本身以及主机上运行的其它容器。

**1)   安全基线**
容器运行时安全需要满足必要的配置基线，关于基线建设包括：

●        建设安全基线（参照附件5和6）持续改进
●        建设安全基线检测自动化工具
●        建设容器资产清单工具，实时洞察容器运行状况。

**2)   容器运行风格选择**
容器运行风格方面，其实有多种选择，采用何种容器运行风格也是安全考虑的问题之一：

常见运行风格：
●        瘦容器(Thin Container): 单进程应用的封装，在镜像中打包应用。这非常适于微服务架构应用的服务交付。
●        胖容器(Fat Container): 多进程应用的封装，在镜像中打包应用。容器引擎对进程 管理的特殊性，我们会利用init.d/systemd或者supervisor等来启动管理进程。但是容器应该尽可能是单一目的，容器中的进程应该是紧耦合的，并有一致的生命周期。比如可以将“nginx”和“php-fpm”打包在一个容器镜像中。
●        VM容器 (VM Container): 是利用容器模拟轻量级虚拟机:镜像本身不包含应用，需要利用在容器启动后动态安装和配置应用。这是不建议的方案，会造成容器中应用配置管理和更新的复杂性。如业务应用暂时无法改造，需要制定过渡方案。一般而言，不建议选择VM容器风格。

## 2）Kubernetes运行时安全
目前主流的容器云管理平台一般基于kubernetes构建，kubernetes平台采用分布式架构方式构建，根据平台功能由多个组件组成，如下图。典型的组件包括api server，etcd，sheduler，controller manager，kubelet，kube-proxy，cAdvisor，Plugin networks（比如flannel）等。
![](/home/attachment/202211/28/1210417_166962116794701.png)

以上组件是容器云平台的控制（管理）平面，是容器云平台的大脑，全面洞察集群上的每一个容器和pod，并且调度新的pod，读取和存储集群中的所有私密信息，因此在通讯和数据存储和传输方面均需要严格安全包括，主要措施包括：

## - 组件安全基线
Kubernetes安全运行需要满足必要的配置基线，关于基线建设包括：
●        建设安全基线（参照NIST规范，CIS benchmark）持续改进
●        建设安全基线检测自动化工具

## - 组件之间通信加密
为了实现组件之间的安全，设计要求组件之间应该启用 TLS，支持 TLS 以防止流量嗅探、验证服务器身份以及（对于相互 TLS 而言）验证客户端身份。

需要开启的TLS通讯包括：
1.   API Server和etcd之间
2.   API Server和Controller Manager之间
3.   API Server和Scheduler之间
4.   API Server和Kubelet之间
5.   平台管理用户和API Server之间
6.   Kubelet和容器之间
7.   业务用户和业务pod之间（可选）

**参考下图：**
![](/home/attachment/202211/28/1210417_166962119765532.png)

## 3）网络安全
**- 网络隔离**
K8s的网络策略应用于通过常用标签标识的pod组。然后，使用标签来模拟传统的分段网络，这些网络通常用于在多层应用程序中隔离层：例如，可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。

简单路由网络或常用的flannel网络程序本身不能应用网络策略。

目前Kubernetes只有几个支持网络策略的网络组件：Romana，Calico和Canal；其中Weave在不久的将来指示支持，Red Hat的OpenShift包括了网络策略功能。因此如何容器云平台基于OpenShift构建会获得OOTB的网络策略功能。

从网络模型的流行度来看，flannel的网络方案最流行，市场占有率较大，基于calico + network policy的方案逐步成熟中，可以持续跟进，在容器云构建中可以在测试环境中进行验证。

在一些落地的方案中，容器云平台建设过程中采用flannel的方案，但是通过为不同安全级别的应用（租户）建设不同的集群而实现应用（租户）网络隔离。

**- 南北向流量的安全**
对于南北向的流量，应该引入传统的网络流量分析控制设备，例如IPS/IDS/审计/NGFW/WAF等。

**- 东西向流量的安全**
东西向流量的安全也是非常关键的，目前可以采用的技术和产品比较少，但这个方面却是非常关键的安全控制点，在没有合适的产品可以替代的情况下，应该尽量：
1、采用Mini Knernel的容器化操作系统；
2、非特权用户运行容器；
3、采用强制访问控制技术；
4、监控宿主机文件系统的变更；
5、保持系统和组件的安全补丁为最新。

# 四、管理安全设计
## 1）管理平台安全建设
**- 建立专属CA中心，定期替换密钥**
在组件TLS加密通讯的关键因素是证书的安全，默认情况下，kubernetes集群搭建使用的私有CA，并且生成临时的证书进行TLS加密通讯，但是为了保障TLS的有效性，保障CA更证书的私密以及以及降低组件证书的泄漏风险，因此建议集群的专属CA中心，并且设置组件证书的有效期，在组件证书快到期的时候进行替换。
![](/home/attachment/202211/28/1210417_166962122468326.png)

## 2）用户权限安全管理
容器云平台的4A（即认证Authentication、账号Account、授权Authorization、审计Audit）管理功能设计。

**- 构建统一账户管理平台（UIMS）**
容器平台是一个多组件组成的平台系统，每个组件自成系统，比如镜像管理，CI/CD平台，日志系统，监控系统等，每个系统单独管理各自的用户数据容易行成信息孤岛，分散的用户管理模式阻碍了平台的协调工作，因此构建统一的标准化账户管理体系将是必不可少的。

统一账户系统平台可带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件。

基于『统一身份治理』的概念，可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类，个人实体从属于组织实体，也可以不从属任何组织实体，且个人实体可同时从属于多个组织实体；基础权限模块将各业务系统的资源权限进行统一管理和授权；基础信息模块用于描述组织实体和个人实体的基本信息，如组织实体名称、地址、法人，个人实体姓名、电话号码、性别等基础信息。此外统一账户系统提供统一的API与其他系统对接。

对于账户的口令需要建立严格的管理机制，因为一个好的口令策略是防止未授权访问的一个最重要的安全屏障，减少弱口令风险是提升系统安全性的投入产出比最高的方式。

建设过程中需要对容器云平台，组织实体，个人实体等账户的口令进行分类，建立平台超级管理员口令，组织管理员口令，个人实体口令管理办法，典型的云平台超级管理员口令的安全性要求最高，组织管理员次之，个人实体口令要求相对低一些，因此口令的管理措施也不同，比如云平台超级管理员需要建设基于硬件的一次性密码或者双要素密码认证机制，组织管理员密码需要建立一次性密码或者双要素密码认证机制，个人实体密码需要满足一定密码复杂度要求。

**典型口令策略，举例：**
- 密码至少由8个字符组成，应该混合数字、大写字母、小写字母，以及特殊字符等；
- 所有系统管理员级别的密码必需每三个月更换一次，并依照规定进行存档备份。普通个人密码六个月更换一次。
- 用户所使用的任何具备系统超级用户权限账号密码必需和这个用户其他账号的密码均不相同。
- 重要的系统密码比如云平台超级管理员，组织管理员采用一次性密码或者双要素密码认证。

UIMS系统支持完备口令使用，变更，修改，注销等生命周期管理能力。

另外需要通过管理规定，严格要求密码使用时注意保护，比如不要把自己密码共享给他人，不要在email中写密码，不要给你上司密码等。

技术实现方案方面，可以通过Microsoft AD， Oracle Identity Management，OpenLdap等软件实现。在一个成熟企业内部基本上已经具备类似系统并且稳定运行。因此此对于容器云平台建设来说主要是统一对接，统一纳管，统一管理的问题。如果企业内部没有需要单独设立子项目建设UIMS系统。

**- 构建统一身份认证平台SSO**
容器云平台实现统一身份认证和传统应用原理一样，区别在于kubenetes支持的身份严重方式有不同要求，常见的统一身份认证方式归纳为以下两类：
●        传统的 Cookie + Session 解决方案，有状态会话模式；
●        基于令牌/票据的解决方案，无状态交互模式。

**具体有：**
●        分布式 Session
●        OAuth2.0
●        JWT
●        CAS

**上述方案各有利弊：**
分布式 Session 是老牌的成熟解决方案，但因其状态化通信的特性与服务提倡的API导向无状态通信相互违背，且共享式存储存在安全隐患，因此微服务一般不太采用。

OAuth2.0 是业内成熟的授权登录解决方案，然而 OA2.0 提供了4种授权模式，能够适应多种场景，作为基于令牌的安全系统，可以广泛用于需要统一身份认证和授权的场景。

JWT（JSON Web Token）是一种简洁的自包含的 JSON 声明规范，因其分散存储的特点而归属于客户端授权模式，广泛用于短期授权和单点登录。由于 JWT 信息是经过签名的，可以确保发送方的真实性，确保信息未经篡改和伪造。但由于其自包含的客户端验签特性，令牌一经签发，即无法撤销，因此单纯采用 JWT 作为统一身份认证和授权方案无法满足帐号统一登出和销毁、帐号封禁和解除这几种类型的需求。

CAS 是时下最成熟的开源单点登录方案，包含 CAS Server 和 CAS Client 两部分。CAS Server 是一个 war 包需要独立部署，负责用户认证；CAS Client 负责处理对客户端受保护资源的访问请求，需要认证时，重定向到 CAS Server。值得注意的是，CAS 是一个认证框架，其本身定义了一套灵活完整的认证流程，但其兼容主流的认证和授权协议如 OAuth2、SAML、OpenID 等，因此一般采用 CAS + OAuth2 的方案实现 SSO 和授权登录。

Kubernetes有三种主要的身份验证方法，用于和API进行交互。官网列出了更多的认证方法，但以下三种是用户认证常见的方法。

●        静态密码
●        X.509客户端证书
●        OpenID Connect（OIDC）

其中，OpenID Connect基于OAuth 2.0协议。

结合kubernetes的支持能力以及常见的方案，容器云平台SSO参照实现方案可以采纳Dex或者Keycloak。

**- 构建最小权限授权管理机制**
所有对容器云的访问均通过kubernetes api server实现，其中访问控制的规则也是在api server进行设置，在最新的Kubernetes 中ABAC（基于属性的访问控制）已被 RBAC 取代，ABAC不建议api server上启用，需要使用RBAC，启用方式是：
![](/home/attachment/202211/28/1210417_166962126017855.png)

除此之外还有以下模式：
--authorization_mode=AlwaysDeny

--authorization_mode=AlwaysAllow

--authorization_mode=ABAC

--authorization_mode=Webhook

--authorization_mode=Node

容器云平台RBAC授权管理机制涉及的概念包括：
**a)     访问对象定义：**
K8s对集群内部的对象以及对象上有的操作进行了规范，比如对象包括（不含CRD对象）：
●        Pods
●        ConfigMaps
●        Deployments
●        Nodes
●        Secrets
●        Namespaces

**b)     对象操作定义：**

资源对象的可能存在的操作有：
●        create
●        get
●        delete
●        list
●        update
●        edit
●        watch
●        exec

**c)      角色/集群角色定义：**
角色是针对以上资源上的一组操作的集合

k8s对于role进行了区分，分为角色（Role）和集群角色（ClusterRole），其中在 角色Role 中，定义的规则只适用于单个命名空间，也就是和 namespace 关联的，而 ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。

**d)     用户/服务账户/组定义：**
在Kubernetes集群中有存在两类用户：

service accounts：由Kubernetes进行管理的特殊用户；

user（普通用户）：普通用户是由外部应用进行管理的用户。

Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin

对于普通用户，Kubernetes管理员只负责为其分配私钥。普通用户可能来自于Keystone或ldap中，或者甚至是存储在文件中的用户名和密码列表。在Kubernetes中，没有表达普通用户的对象，因此，也就不能通过API将普通用户添加到集群中。

而Service Account是由Kubernetes API管理的用户，它们被绑定到特定的命名空间中，并由API服务器自动创建或通过API调用手动创建。Service Account与存储在Secrets的一组证书相关联，这些凭据被挂载到pod中，以允许集群中进程与Kubernetes API进行通信。

API请求要么来自于普通用户或Service Account，或来自于匿名请求。这就意味着集群内外部的所有进程（从来自于用户使用kubectl输入的请求，或来自于Nodes中kubelet的请求，或来自控制板的成员的请求）都需要进行认证才能与API server进行交互。

**e)     角色绑定/集群角色绑定定义：**
RoleBinding 和 ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和我们的 Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding 只会影响到当前 namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的 namespace。

在有以上定义的基础上，容器云平台的基于rbac管理模型下的权限管理方式：某一用户（service account或者User）通过角色绑定定义了该用户具有哪些角色，该角色详细记录具有对哪些对象的那些操作，即改用户具有了对哪些对象进行哪些操作的能力。

在容器云平台授权管理部分还是和传统应用一样，一定授权秉承最小权限原则，对于用户的权限进行最小化设置，并且对于用户的权限进行周期性review、及时清理比不必要的用户和权限定义。

小提示：关于如何实为集群服务设置RBAC策略的最佳实践，以及归纳典型设置可以使用 audit2rbac，从审计日志提取细粒度的RBAC 策略。

**- 开启审计功能（非强制）**
审计功能主要包括两部分内容，一个是k8s api调用审计，一个是管理平台页面操作审计，审计记录均以日志的形式上收到日志平台统一管理，其中api审计日志通过开启k8s audit功能实现，管理平台的审计日志通过管理平台的实现方自定义实现。

其中api server（kube-apiserver.yaml）开启audit日志的方式是：
![](/home/attachment/202211/28/1210417_166962130287307.png)
![](/home/attachment/202211/28/1210417_166962132167409.png)

审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 [审计级别][auditing-level]。已知的审计级别有：

None -符合这条规则的日志将不会记录。

Metadata -记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。

Request -记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。

RequestResponse -记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。

目前对于容器云上的API Server审计日志的支持，推荐的日志采集的方式是通过日志采集平台将数据采集到日志中心，通常日志中心是基于大数据理念建设的海量数据存储平台，审计日志的查询配合特定索引进行根据关键字的查询，审计日志保存内容以及保存时间需要遵从相关行业规定，通常日志内容需包含时间、用户、操作模块、操作行为等信息，同时建议在线日志保存一个月以上，此外定期对审计日志进行备份存档（三级系统归档日志至少保存3个月）；

**3）租户资源访问安全**
根据上面容器平台的架构图，我们可以发现容器底层资源是以池化的方式供上层应用进行消费使用的，通过云平台支持多租户模型，提供了多个业务主体应用并行运行的能力，其实这也是云平台的关键特征之一。

共享的现状为业务的运行提供弹性伸缩的能力，可以实现对多个业务压力削峰填谷的效果，最大限度的提升了资源的利用率。

但是共享也带了来一定的隐患，比如恶意访问，资源恶意抢占等，因此容器平台需要实现容器资源隔离的能力，目前kubernetes提供的能力包括：
1）资源的访问隔离通过namespace机制对容器云平台进行多租户资源隔离，租户内基于RBAC模式的授权模式进行资源的访问控制。
2）对于资源请求量方面，admission control是一种多维度可扩展的资源管理机制，每个维度通过一个admission control插件实现。 与Kubernetes用户认证与授权模块一样，对admission control的调用也是由api server来完成的。

目前支持的admission control插件，分别是

NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, RuntimeClass, ResourceQuota

以上插件按需激活使用，比如：
![](/home/attachment/202211/28/1210417_166962134443073.png)

3）Node selector机制
此设置是资源隔离的一种方式，但此方式并不是平台构建层面需要考虑的措施，需要以规范或者最佳实践的方式通知应用部署人员，按照规范部署实施。

此功能原理是让 kubernetes 集群调度器根据node selector的设置为 pod 资源选择某个节点（如果未设置，默认是调度考虑的是资源足够，并且 load 尽量平均）。

4）网络隔离
网络资源在集群层面也是共享的，相关的隔离措施见前面部分。

**- 单集群和多集群**
在某些行业中比如金融业，监管部门要求一个业务的前端，后端需要部署在不同的网络区域中，因此容器云平台在建设过程中，需要考虑集群跨网断或者多集群部署的问题，此外随着一个集群的业务不断增加，也需要在容量上做对集群拆分。因此在构建容器云平台时建议规划好集群的部署形式。

建议：
●        不同环境部署多个集群，比如UAT测试，SIT测试，性能测试。
●        不同网络区域部署多个集群，比如DMZ区域，业务后台区域。
●        不同地域部署多个集群，比如生产区域和灾备区域
●        不同业务安全级别的应用部署在不同集群。
●        单个集群不能太小，同时也不能太多，建议不超过128台物理主机（48c/256G）。

**4）组件安全**
Kubernetes平台本身是一个可扩展的平台，通过CNI支持不同的网络组件，通过CSI支持不同的存储组件，此外通过CRD能力支持不同的客户化资源定义，常见的功能扩展比如CI/CD，日志，监控，告警。以上组件通过CRD的方式部署在kubernetes集群内，扩展了容器云平台的能力，此外在应用层面，微服务运行组件也以组件的方式部署在容器云平台上。比如Spring Cloud，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（Docker Trust Repository）/DCT（Docker Content Trust）方案和harbor/notary方案。

DTR/DCT方案中，镜像校验和用来保证镜像的完整性，以预防可能出现的镜像破坏。registry下的每一个镜像都对应拥有自己的manifest文件以及该文件本身的签名。其中的信息包括镜像所在的命名空间、镜像在此仓库下对应的标签、镜像校验方法及校验和、镜像形成时的运行信息以及manifest文件本身的签名。

**2）应用配置安全**
**Secret**
应用启动过程中可能需要一些敏感信息，比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥，Kubernetes 提供的解决方案是 Secret。

Secret 会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret会以 Volume的形式被mount到Pod，容器可通过文件的方式使用Secret中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。

常见敏感信息包括关键的环境变量，比如数据链接密码信息，TLS证书信息，镜像库认证信息等。

**Vault**
众所周知，即使使用了k8s secret进行敏感信息的保存，其实默认情况secret的信息只是做了base64编码，通过k8s api还是可以获得secret存储的敏感信息的，Vault产品作为企业级的secret管理工具，满足了客户在业务上云过程中的安全强需求。因此建议在容器云平台建设中进行采用。

其主要的应用场景：
1、作为部署在Kubernetes集群中的应用对外提供秘钥管理服务，支持与多家主流云厂商秘钥服务以及多种secrets形式的对接，支持多种数据库服务的存储对接，同时支持多种认证形式的对接。
2、作为一个公共的加密服务（Encryption as a Service）而不做后端存储的对接，帮助用户应用剥离繁琐的加密加解密逻辑。
3、面向政府、金融等对数据安全规格有很高要求的客户，Vault支持基于Two-man原则利用私钥分割算法对后端服务进行加解封，并结合k8s的高可用部署形态为企业提供更加安全可靠的secret管理能力。

Vault作为一个在Kubernetes集群上直接运行的安全应用，任何一个面向k8s的应用工具都可以利用其安全能力。

**3）容器服务访问安全**
业务应用在容器云平台中Service的方式存在。Service是 Kubernetes 最核心的资源对象之一，通过它可以为一组具备相同功能的容器应用提供一个统一的访问入口地址，并将请求负载分发到后端的各个容器应用上。这一点与传统 IT 基础架构中 F5 等负载均衡设备将访问请求负载分发到后端功能相同的应用上类似，Kubernetes 集群中每个节点上运行的 kube-proxy 其实就是一个智能的软件负载均衡器，它负责把对 Service 的请求转发到后端的某个 pod 实例上，并在内部实现服务的负载均衡与会话保持机制。Kubernetes 提供了三种主要方案，分别是 NodePort 、LoadBalancer 、Ingress。

●        NodePort
NodePort 的实现方式是在每个节点上为需要外部访问的 Service 开启一个对应的 TCP 监听端口，外部系统用 <NodeIP>:<NodePort> 可以从集群外部访问一个 NodePort 服务，NodePort 服务会路由到 ClusterIP，通过 kube-proxy 转发至后端的容器，完成对服务的访问。

●        LoadBalancer
LoadBalancer 是 Kubernetes 深度结合云平台的一个组件，使用它构建服务时，实际上是向底层 IaaS 申请创建一个负载均衡来实现。IaaS 网络和容器网络在不同云平台的融合方案不同，因此 LoadBalancer 和云平台的网络方案深度耦合，只能在特定的云平台上使用，局限性较大。

●        Ingress
Ingress 可以很好的解决 LoadBalancer 和 NodePort 的限制。它由 3 个组件组成：Ingress 策略集、Ingress Controller 和反向代理负载均衡器（如 Nginx）。Ingress 策略集定义了集群外的流量到达集群内的 Service 的规则。Ingress Controller 与 Kubernetes 的 API 交互，实时感知后端 Service、pod 的变化，再结合 Ingress 策略集生成配置，然后更新反向代理负载均衡器的配置，实现动态服务发现与更新。反向代理负载均衡器对集群外流量进行负载分发。现有的 Kubernetes 版本已将 Nginx 与 Ingress Controller 合并为一个组件 Nginx-Ingress-Controller，无需单独部署 Nginx。但 Kubernetes 原生 Ingress 是一个七层负载均衡技术，仅适用于 http 服务。另外，其并未解决 Kubernetes 环境下，不同租户的服务隔离问题。

**除了k8s原生支持方案以外，F5公司提供了另外一种方案：**

●        F5 CC+VE 方案
该解决方案包含 2 个组件，VE（Virtual Edition）和 CC（Container Connector）。VE 是 F5LTM 的软件化商业产品，可以安装在虚拟机或者物理机上，其功能与硬件设备完全一致。CC 是 F5 解决方案的一个关键组件，为用户提供了企业级支撑，同时也是开源产品，用户可以根据自己的需要对 CC 进行功能扩展。该方案利用 CC 与 Kubernetes 进行 API 交互，实现与容器平台的联动，满足容器应用的灵活性需求；配置上采用 ConfigMap 进行负载均衡策略下发，实现在 Kubernetes 层面进行 F5 策略配置工作；网络架构上采用 VE 直接对集群中的 pod 进行负载分发，减少网络层次，提升负载均衡性能；同时，通过将 Kubernetes 的 namespace 与 VE 的 partition 映射，实现不同容器租户负载均衡资源的隔离，此方案架构如下图：
![](/home/attachment/202211/28/1210417_166962137928732.png)

以上方案中，F5方案中实现了基于api的TLS证书管理能力以及F5商用产品的负载均衡处理能力，是一种不错的应用安全入访访问控制方案。

**4）应用证书管理**
随着零信任安全模型的普及，业务系统实现全站HTTPS化，加密用户与业务间的交互访问已经成为安全的必选项，为了提供业务快速安全的上云的需要，需要在容器云平台上提供一站式SSL证书解决方案，支持包括云上客户自己上传任意机构签发的SSL证书，统一管理不同渠道证书，以及将证书一键部署到入防负载均衡服务的能力。

**5）WEB应用入侵检测**
WEB应用入侵检测在容器云环境下，依然很重要，应用入侵防御主要的考虑点如下：
●        Iptables隔离，通过在宿主机侧对网络集群外部做基于Iptables的隔离策略，可以限制攻击者对“容器在宿主机所映射端口”的访问，缩小受攻击面。
●        部署软WAF，通过在网络集群的流量入口处做软WAF的部署（形态可以是宿主机软件或者容器），可以在此处阻断、发现部分恶意流量。
●        部署RASP，通过在Java、PHP服务器容器内部部署RASP产品，可以用之作为保护的最后一环，作为网络治理的一个补充小点。
●        Webshell扫描，通过在宿主机侧通过Webshell扫描引擎扫描来自Docker容器的“Web应用程序文件”（这些文件可通过“docker cp”命令或者“动态挂载”机制获得），有助于发现攻击者植入的Webshell。
●        日志分析，通过在宿主机侧通过ELK等日志分析分析来自容器的日志文件（这些日志文件同样可通过“docker cp”或“动态挂载”等方式获得）。此外，单独运行Sidekick日志容器等做法有助于发现安全威胁。
●        识别中间人攻击，通过在网络集群内部通过网络隔离是防止此类基于网络的攻击的有效方法，此方法可使得攻击者无法操纵或窃听主机及其他容器的网络流量；在这种情况下，OpenVPN(开放虚拟专用网络)提供了一种通过TLS(传输层安全协议)加密实现虚拟专用网络(VPN)的方法。
●        识别、阻断流向异常的流量，通过在网络集群内部依据实际的网络拓扑图对网络进行“微分段”隔离（在“微服务架构”下，IP地址可能变换频繁，但是预先划分的网段不会变换频繁），或者对指定的网桥、网卡进行流量的DPI分析，有助于识别、阻断流向异常的流量。
●        识别拒绝服务攻击，通过在宿主机侧读取和容器对应的cgroup文件系统相关文件的实时内容（网络、CPU、内存、磁盘），可以识别出拒绝服务攻击。
●        网络流量可视化，“网络流量可视化”是现有的“容器安全产品”的常见附加功能。该功能的功能可能依托于“对指定的网桥、网卡进行流量的DPI分析”。

实现容器云环境下的WEB应用入侵检测能力，业内有两种方式，一种是基于对宿主机进程进行入侵检测的方式，一种方式是利用安全容器进行入侵检测的方式，其中第一种方式一般是传统的主机安全厂商向容器云安全扩展的最佳方式，充分利用了容器是宿主机上特殊的进程的特性，在宿主机上进行web应用防护，最大限度的利用了在主机层面的安全能力的积累，典型案例国内厂商青藤云安全的方案。另外一种方式基于类似sidecar的方式通过安全容器进行业务容器的安全防护，利用容器间资源共享的特性，安全容器对业务容器进行入侵检测，此种方式可以说是充分利用容器的原生特性，一般专注容器云的厂商相对倾向于这种方式，比如国内小佑科技的容器云安全的方案。

# 五、容器云平台建设指引
** - 继往开来**
纵观云市场上顶尖的几家厂商，均推出了相关的容器云产品，因此建设自己的容器云平台，建议先吸收一下各大厂商的经验，并且根据自己的实际情况进行落地建设，此外可以参考目前已知行业安全规范标准以及可能的落地指引等，相关材料如下：

●      GBT22239-2019信息安全技术网络安全等级保护基本要求
●      容器安全标准（NIST.SP.800-190)
●      容器CIS合规检查项目，参照https://www.cisecurity.org/benchmark/docker/
●      集群CIS合规检查项目，参照https://www.cisecurity.org/benchmark/kubernetes/
●      《中国金融行业容器技术和平台应用研究》白皮书
●      中国开源云联盟容器工作组-容器技术及其应用白皮书v1.0
●      https://www.docker.com/blog/understanding-kubernetes-security-docker-enterprise/

** - 以终为始**
过度建设是一种浪费，过度安全建设更是如此，因此安全设计需要考虑实际需求，以终为始，建议在构建容器云时，首先分析云上业务的类型（数据敏感性，安全等级等），工作模式（内网/互联网，自用/出售），等保要求，行业监管要求，然后再梳理安全需求，进行逆向分析，评估需求，惊喜设计，然后再进行的容器云平台安全功能建设。

**- 螺旋上升**
制定完备的漏洞整改措施，特别是平台关键组件的漏洞。

制定容器云平台本身的DevOps流程，实现 需求-〉开发-〉测试-〉生产-〉需求的版本迭代。

容器云安全设计容器云平台安全设计

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论2 条评论

menglunyang

系统工程师中国银行
2022-11-30 21:08

数字化转型下云原生对it产生了重要影响。在弹性it架构及敏态应用、开发运维一体化方面对企业提出了较高的要求。容器安全随着K8S在企业中的落地显得越来越重要。如何构建全栈的云原生应用安全防护能力是我们都要考虑的方面。本文深入浅出，从容器制品安全、集群配置安全、容器运行安全、容器安全管理平台等方面提供了完善的介绍，使我们对容器安全有了深入思考和整体收获。

小肉鸡信息安全岗郑州银行
2022-11-29 14:35

该文章从容器PaaS平台兴起的背景入手，剖析容器云平台建设中遇到的安全问题，其中每个安全问题都给出了清晰易懂的举例。根据容器云主流架构规划出安全建设的推荐架构，并逐步分析此架构中需包含哪些安全能力、如何落地、解决了什么问题。逻辑清晰，观点明确，可以在写容器安全建设方案中作为有效参考。

Ctrl+Enter 发表

匿名评论

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

添加新评论2 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料