KubeEdge发布云原生边缘计算威胁模型及安全防护技术白皮书
作者:互联网
摘要:本文将基于KubeEdge项目详细分析云原生边缘计算业务过程的威胁模型并给出对应的安全加固建议。
本文分享自华为云社区《KubeEdge发布云原生边缘计算威胁模型及安全防护技术白皮书》,作者: 云容器大未来。
KubeEdge社区已完成了对KubeEdge项目的全面安全威胁模型分析。云原生边缘计算的安全性问题一直备受用户关注,但是目前业界缺乏关于云原生边缘计算的安全威胁模型分析,用户很难对其边缘系统进行有效的安全加固。针对以上现状,作为业界首个云原生边缘计算项目,我们将进行系统分析并发布安全威胁模型及分析报告,这对于用户或vendors有着重要的安全实践指导意义。本文将基于KubeEdge项目详细分析云原生边缘计算业务过程的威胁模型并给出对应的安全加固建议。
背景
随着越来越多的用户将KubeEdge项目用于生产环境中,KubeEdge社区把安全问题放在优先地位。KubeEdge社区十分关注项目的安全,并成立Sig Security安全团队:(https://github.com/kubeedge/community/tree/master/security-team),负责KubeEdge的系统安全设计,并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估,KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会(CNCF)对KubeEdge项目进行安全评估并输出安全评估报告,分析和总结KubeEdge项目的安全威胁模型及相关安全问题。感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski对KubeEdge项目专业、全面的评估,该评估对KubeEdge项目的安全防护有重要的指导意义。感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会,他们对这次合作提供了很大帮助。对于安全报告中发现的安全问题,KubeEdge社区已根据社区的漏洞处理策略第一时间修复,并发布release版本,版本号为v1.11.1、v1.10.2和v1.9.4,漏洞公告已发布在:https://github.com/kubeedge/kubeedge/security/advisories。
本文将分析KubeEdge的威胁模型,并给出相应的安全防护方案。
目标人群
以下人群在使用KubeEdge过程中,了解本文分析的KubeEdge威胁风险和可能的缓解措施将对他们的工作发挥很大作用:
- KubeEdge的贡献者。 一个通用的威胁模型可能对开发KubeEdge的人很有用,他们可以从整体角度考虑并加固他们的系统。
- 部署KubeEdge的组织。 对于在集群中使用KubeEdge的组织来说,了解常见的攻击和可能的弱点是很有用的,这样他们就可以检查和评估自己的配置。
- 安全评估员,负责评估使用KubeEdge的Kubernetes集群(已有或新建的集群)的安全性。
- 开发人员需要了解KubeEdge的更新和攻击,以主动避免未来可能发生的安全风险。
KubeEdge威胁模型分析
KubeEdge安全审计报告中指出,KubeEdge潜在的攻击者包括以下三部分:
- 外部攻击者,从系统外部发起攻击。
- 内部攻击者,包括系统内部操作人员不合规操作导致的安全问题。
- 供应链攻击者,破坏KubeEdge软件供应链组件的攻击者。
KubeEdge社区运用ASTRIDE Low Level威胁建模方法并结合KubeEdge安全审计报告,对KubeEdge进行系统的安全分析,旨在帮助开发者或用户理解系统中潜在的安全威胁,明确风险并列举出目前KubeEdge社区已有的相应的消减机制和安全加固建议。
外部攻击分析
KubeEdge数据流图如下:
如上述数据流图所示,当数据流穿越不同的信任级别(区域)时,就存在信任边界,已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界(引用自KubeEdge第三方安全报告)、社区已有的消减措施并给出安全加固建议:
Threat ID 1:云端CloudCore组件与EdgeCore组件之间的连接
描述
边缘EdgeCore发起到CloudCore组件的连接。该数据流中,较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。EdgeCore在整个系统中有一个单独的权限级别,因此控制EdgeCore的攻击者不应该能够对其他边缘节点产生负面影响,例如通过攻击和操控CloudCore来攻击其他节点(该漏洞描述引用自安全评估报告)。
影响
攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文,导致通信过程存在仿冒和篡改的威胁风险。
消减措施
- CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性,安全加密协议使用TLS 1.2,使用安全加密算法为TLSECDHEECDSAWITHAES128GCM_SHA256,且加密算法套件白名单中默认只支持该算法,防止客户端使用不在白名单中的不安全算法进行通信造成安全风险;
- 证书默认有效期为一年,过期后失效,防止证书被攻击者利用。用户基于kubeedge项目已有的证书轮转机制,可以实现证书过期自动更换,保障业务连续性。
安全加固建议:
- Recommendation ID 1:使用安全长度的私钥加密,并加密保存私钥
- Recommendation ID 2:使用可信来源的CA证书
Threat ID 2:边缘组件ServiceBus在本机范围内提供HTTP服务
描述
边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中,较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击,不应该使攻击者能够将影响范围扩大到云端控制面(该漏洞描述引用自安全评估报告)。
影响
ServiceBus组件收到的数据往往是不受管理面控制的,攻击者能够对ServiceBus组件发起恶意报文攻击,导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障,不会导致整个KubeEdge系统崩溃。
消减措施
- ServiceBus组件仅监听本地local host端口,已限制服务范围,只允许本机进程访问,通过对本机用户访问权限的限制保障本组件安全;
- 服务端接收客户端连接时记录连接访问的日志,可作为审计日志,可以让管理员及时发现攻击的发生,并及时停止ServiceBus服务,阻止攻击继续进行;
- ServiceBus服务默认关闭,遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务,则存在上述风险。
安全加固建议
- Recommendation ID 3:严格限制边缘节点的用户登录权限
- Recommendation ID 4:严格限制应用部署的权限
- Recommendation ID 5:严格校验应用镜像的合法性
Threat ID 3:边缘端Device通过MQTT Broker连接到EdgeCore。
描述
边缘device设备通过MQTT Broker(集成在EventBus组件中)连接到EdgeCore。该数据流中,较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问(该漏洞描述引用自安全评估报告)。
影响
EdgeCore组件收到的数据往往是不受管理面控制的,攻击者能够对MQTT Broker发起恶意报文攻击,存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常,异常仅影响单个边缘节点服务故障,不会导致整个KubeEdge系统崩溃。
消减措施
- MQTT Broker仅监听在本机端口,已限制服务范围,只允许本机进程访问,通过对本机用户访问权限的限制保障本组件安全;同时,EventBus组件可作为客户端,对接外置第三方MQTT Broker,如果用户使用第三方MQTT Broker,详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。
- EventBus仅对MQTT Broker中的特定Topic进行处理,用户无法通过该通道对EdgeCore任意访问。
安全加固建议
- Recommendation ID 3:严格限制边缘节点的用户登录权限
- Recommendation ID 4:严格限制应用部署的权限
- Recommendation ID 5:严格校验应用镜像的合法性
- Recommendation ID 6:严格限制边缘Device设备的接入
Threat ID 4:Edged管理和监控Pods及其他K8s资源
描述
Edged管理和监控Pods及其他K8s资源。该数据流中,较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时,被恶意服务器攻击,不应该使攻击者能够将影响范围扩大到云端控制面(该漏洞描述引用自安全评估报告)。
影响
如果Edged访问的CRI插件被攻击者恶意伪造,则存在CRI插件仿冒和篡改的威胁风险,导致本地业务异常。
消减措施
- Edged与CRI插件通信时,只在本地访问受信任路径,由管理员控制访问路径,最小化Unix domain sockets文件描述符的权限,避免被仿冒者恶意替换。
安全加固建议
- Recommendation ID 3:严格限制边缘节点的用户登录权限
- Recommendation ID 7:严格审查边缘节点上CRI插件的配置
Threat ID 5:MetaServer在边缘节点提供HTTP服务
描述
MetaServer作为边缘“api-server”,对边缘插件提供HTTP服务。该数据流中,较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问(该漏洞描述引用自安全评估报告)。
影响
MetaServer组件收到的数据往往是不受管理面控制的,攻击者能够对MetaServer组件发起恶意报文攻击,导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障,不会导致整个KubeEdge系统崩溃。
消减措施
- MetaServer组件仅监听本地local host端口,已限制服务范围,只允许本机进程访问,通过对本机用户访问权限的限制保障本组件安全;
- MetaServer服务默认关闭,遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务,则存在上述风险。
安全加固建议
- Recommendation ID 3:严格限制边缘节点的用户登录权限
- Recommendation ID 4:严格限制应用部署的权限
- Recommendation ID 5:严格校验应用镜像的合法性
内部攻击分析
对于内部管理员或操作人员,可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。
消减措施
- KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ,指导系统管理员或操作人员正确操作,减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代,该文档也将持续更新并完善。
安全加固建议
- Recommendation ID 3:严格限制边缘节点的用户登录权限
- Recommendation ID 4:严格限制应用部署的权限
- Recommendation ID 8:严格划分系统中各个角色权限
- Recommendation ID 9:及时跟进并更新KubeEdge版本
供应链攻击分析
攻击可能发生在典型软件供应链的每一个环节,而且在当今环境中,这些类型的攻击越来越公开,破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。
消减措施
- 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估,并引入SLSA软件供应链安全评估框架,包括对源代码、构建流程、依赖库等进行安全评估,防止针对软件供应链的攻击,从源头上保障软件供应链的安全。详细SLSA框架描述请参考https://slsa.dev/spec/v0.1/#supply-chain-threats;
- KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能,及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新,降低被攻击的风险;
- KubeEdge security team已具备完整漏洞处理机制,包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程,可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。
- 社区将根据SLSA软件供应链安全评估框架持续改进软件供应链安全。
安全加固建议
- Recommendation ID 10:根据社区发布的校验文件严格校验二进制文件
- Recommendation ID 11:在用户或vendors的软件供应链中引入SLSA软件供应链安全评估框架
安全加固建议列表
Recommendation ID 1 - 使用安全长度的私钥加密,并加密保存私钥
描述
建议用户生成至少为2048位私钥,且在本地加密存储私钥,存储私钥的文件设置最小化的访问权限,仅属主可读。
Recommendation ID 2 - 使用可信来源的CA证书
描述
从可信的CA获取数字证书,不使用自签名证书。
Recommendation ID 3 - 严格限制边缘节点的用户登录权限
严格限制边缘节点的本机权限,限制外部用户的用户登录权限,减少非必要的授权。
Recommendation ID 4 - 严格限制应用部署的权限
描述
严格限制边缘节点应用部署的权限,只有系统服务和管理员才能拥有部署特权容器的权限;
Recommendation ID 5 - 严格校验应用镜像的合法性
描述
在边缘节点部署应用时,严格校验应用镜像的合法性,防止部署恶意应用。
Recommendation ID 6 - 严格限制边缘Device设备的接入
描述
对于接入边缘节点的Device设备进行严格审核,避免非必要设备接入。
Recommendation ID 7 - 严格审查边缘节点上CRI插件的配置
描述
严格审查CRI插件的配置,使用CRI对应插件的官方推荐配置。
Recommendation ID 8 - 严格划分系统中各个角色权限
描述
严格划分系统中各个角色权限,通过RBAC、OPA等方式实现系统角色权限的细粒度控制。
Recommendation ID 9 - 及时跟进并更新KubeEdge版本
描述
社区发现漏洞后将在最近的3个minor release版本中合入解决,用户可以关注社区security advisory 获取漏洞披露信息,并及时跟进并更新KubeEdge版本。
Recommendation ID 10 - 根据社区发布的校验文件严格校验二进制文件
描述
用户使用社区发布的二进制文件前,应该根据社区发布的校验文件(校验文件格式:checksum_组件二进制包名称.txt)严格校验二进制文件,防止二进制被仿冒和篡改。社区release软件包发布地址https://github.com/kubeedge/kubeedge/releases。
Recommendation ID 11 - 在用户或vendors的软件供应链中引入SLSA软件供应链安全评估框架
描述
用户或vendors在使用源代码构建过程中,应该参考SLSA软件供应链安全评估框架,对源代码、构建流程、依赖库等进行安全加固。
附录:相关链接
• 社区漏洞处理机制: https://github.com/kubeedge/kubeedge/security/policy
• 社区security advisory链接: https://github.com/kubeedge/kubeedge/security/advisories
• KubeEdge威胁模型及安全防护分析(本文档): https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md
• 社区用户文档链接: https://kubeedge.io/en/docs
• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats
• release链接地址: https://github.com/kubeedge/kubeedge/releases
标签:原生,KubeEdge,白皮书,安全,Recommendation,组件,权限,ID 来源: https://www.cnblogs.com/huaweiyun/p/16528606.html