多云管理平台Rancher与安全最佳实践

 bt0sea 嘶吼专业版 

0x00、前言

4月中旬发表的"多云管理与安全架构迁移"，获得了安全圈小伙伴超出预期的阅读量，那么打算具体细化相关多云战略以及安全最佳实践。

在开源圈中，目前与多云战略最贴近的开源项目是：Rancher，14.2k的star，是当之无愧No.1。谈安全需要先了解其寄生的数字平台。

2020年4月份中旬，Rancher 2.4版本发布，其新特性中包含边缘计算部署场景的支持、零宕机升级集群、安全性增强。其中安全性增强中包含了通过CIS基准扫描增强安全性，集群安全性对于成功的Kubernetes策略至关重要。然而，AimPoint的最新研究显示，44%的公司正是由于对Kubernetes容器安全的顾虑，用户可以根据互联网安全中心发布的100多个CIS安全基准，结合Kubernetes集群安全的实际定义，对RKE集群进行点对点（ac-hoc）安全扫描。用户可以创建自定义测试配置，设置扫描完成/扫描失败的通知告警，并根据这些信息采取纠正措施，以确保这些集群满足所有的安全要求。

0x01、rancher基础架构

要聊架构安全问题，首先需要了解Rancher基础架构组成，架构本身帮助我们解决了哪些安全问题，在这基础上，我们还能做什么安全防御的事情。

1）Rancher基础架构解析

1、资源管理

· 2.4.0 支持管理 2000 个集群和 10 万个节点

· 满足多“分支机构”，“数据中心”和“边缘集群”部署场景

· 以减少 Rancher 管理面中管理每个集群所需的内存和CPU资源

· Rancher Server 暴露更多性能相关的指标例如 websocket连接数等

2、K8S和K3S版本管理

集群版本升级是整个多云管理版本维护的刚性需求，rancher已经做到了零宕机升级整个k8s集群。减少了运维成本，提升运营效率。

@1、零宕机升级

· 先升级etcd，然后control plane节点，最后升级 Worker节点

· 升级 K8s 集群过程中，保证Etcd、kubernetes API可用、工作负载可用

· 可手工调整Etcd、control、worker升级次序，保证整个集群在升级过程当中，应用可用性。

@2、升级状态可监控

@3、支持集群回滚

• 支持仅恢复etcd (已有功能) • 支持恢复etcd和k8s • 支持恢复etcd，k8s和cluster配置

3、身份认证与RBAC策略

· 支持 Shibboleth 认证支持

· Shibboleth 认证支持配置 OpenLDAP 进行用户和组搜索

  · Shibboleth 负责身份验证，OpenLDAP 负责搜索用户和组。

  · Rancher 用户可以通过 LDAP 搜索用户和组，而且还可以搜索到非当前用户所在的组。

· 支持创建自定义全局角色

· 支持将组关联到 Rancher 全局角色

4、CIS benchmark扫描

· 定时执行集群安全扫描

· 设置告警，扫描完成发送通知 • 设置告警，扫描失败发送通知

5、Istio

Istio，以及整个Service Mesh技术，是近一两年来Kubernetes生态系统中最亮眼的明星之一。Istio增加了容错、金丝雀部署、A/B测试、监控、跟踪和可观察性、身份认证和授权，开发人员无需再测试或编写特定代码，即可实现上述功能。如此一来，开发人员可以只专注于他们的业务逻辑，将剩下的工作交给Kubernetes和Istio。

6、Pod&network配置强制

OPA Gatekeeper 支持

· Open Policy Agent Gatekeeper operator

  · OPA 使用了K8s的Admission Controllers功能

  · Gatekeeper 封装了一层 OPA，允许通过CRD的形式使用OPA

· 使用 OPA Gatekeeper 可以做什么?

  · 校验资源是不是有特定的label

  · 校验容器的镜像是否来自合规的镜像仓库

  · 强制Pod必须设置预留值和限制值

  · 强制Deployment配置nodeSelector

  · 强制Istio Policy使用双向TLS

2）架构安全

Rancher已经帮助企业解决了身份认证、k8s安全基线检查、pod和network方面的强制性策略方案的工作。但是这些就完全满足我们的要求么？

中大型企业入口流量部署架构如图

Ingress 规则定义了对七层网关的要求，包括URL分发规则，基于不同域名的虚拟主机，SSL证书等。Kubernetes使用Ingress Controller 来监控Ingress规则，并通过一个七层网关来实现这些要求，一般可以使用Nginx，HAProxy，Envoy等。虽然Ingress Controller通过七层网关为后端的多个Service提供了统一的入口，但由于其部署在集群中，因此并不能直接对外提供服务。实际上Ingress需要配合NodePort和LoadBalancer才能提供对外的流量入口，采用Ingress配合NodePort和Load Balancer为集群提供外部流量入口，从该拓扑图中可以看到该架构的伸缩性非常好，在NodePort，Ingress，Pod等不同的接入层面都可以对系统进行水平扩展，以应对不同的外部流量要求。

在此基础上，我们需要集成纵深防御体系，包括恶意流量清洗（Ant-DDoS服务）、恶意流量监控（NIDS服务）、Web***防护（WAF服务）、主机安全与容器安全防御系统（HIDS/EDR服务）。

1、Anti-DDOS服务，检测引擎需要发现4层DDOS和7层CC***，清洗引擎需要尽量清洗掉恶意流量，最后提供LB熔断规则联动，流量超过系统负载，需要阻断其对多云系统内部的进一步伤害。

2、WAF建议控制细粒度到服务级别，可以提升部分SLA。

3、NIDS建议部署到流量入口与LB服务结合，内部横向流量建议使用主机安全获取。

4、主机安全部分，需要部署HIDS引擎和EDR引擎，保证基础架构的物理/云主机的安全。

5、容器安全部分，需要通过主机层面获取对Pod安全防护能力。

0x02、总结

基于多云时代的安全架构迁移，应该是2020年安全产品工作重点，期待更好的多云安全产品出现。