KubeEdge 在边缘计算领域的安全防护及洞察
本文分享自华为云社区《KubeEdge在边缘计算领域的安全防护及洞察》，作者：华为云云原生团队。
随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在 2020 年 Linux 基金会与多家硬件和软件厂商合作创立了开源软件安全基金会 OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。
作为业界首个云原生边缘计算项目，KubeEdge 社区致力于提升 KubeEdge 在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于 2022 年 7 月完成了对 KubeEdge 项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge 社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍 Kubeedge 在安全防护方面的实践，并介绍 OpenSSF 在开源软件安全方面的计划与目标。
KubeEdge 安全防护
安全防护背景
KubeEdge 在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN 等行业提供一体化的边端云协同解决方案。随着越来越多的用户将 KubeEdge 项目用于生产环境中， KubeEdge 社区把安全问题放在优先地位，并成立Sig- Security 和安全团队 ，负责 KubeEdge 的系统安全设计，并快速响应和处理安全漏洞。为了对 KubeEdge 项目进行更加全面的安全评估，KubeEdge 社区联合 ADA LOGICS 公司、OSTIF 及云原生计算基金会（CNCF）对 KubeEdge 项目进行安全评估并输出安全评估报告，分析和总结 KubeEdge 项目的安全威胁模型及相关安全问题。
该评估对 KubeEdge 项目的安全防护有重要的指导意义，感谢 ADA LOGICS 公司的专家 Adam Korczynski 和 David Korczynski 在该项工作中的巨大贡献，同时，感谢 OSTIF 的 Amir Montazery 和 Derek Zimmer 以及 CNCF 基金会，他们对这次评估提供了很大帮助。
对于安全报告中发现的安全问题，KubeEdge 社区已根据社区的漏洞处理策略第一时间完成修复，并针对 v1.11、v1.10、v1.9 三个版本发布了安全补丁，版本号分别为 v1.11.1、v1.10.2 和 v1.9.4，漏洞公告已发布在https://github.com/kubeedge/kubeedge/security/advisories。
接下来将通过解读 KubeEdge 威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。
威胁模型分析
KubeEdge 的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用 STRIDE 威胁建模方法，结合安全审计报告对 KubeEdge 进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前 KubeEdge 社区已有的消减机制和安全加固建议。
以下人群使用 KubeEdge 过程中，了解 KubeEdge 的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：
• KubeEdge 的贡献者：一个通用的威胁模型对 KubeEdge 贡献者很有用，他们可以从整体角度考虑并加固他们的系统。
• 部署 KubeEdge 的组织：对于在集群中使用 KubeEdge 的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。
• 安全评估员：负责评估 KubeEdge 及所属 Kubernetes 集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。
• KubeEdge 的用户及其开发人员：需要了解 KubeEdge 的更新和攻击，以主动避免未来可能发生的安全风险。
外部攻击分析
根据 STRIDE 威胁建模方法对 KubeEdge 潜在的外部攻击进行分析，对应的数据流图如下。
如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析 KubeEdge 系统架构中的信任边界（引用自 KubeEdge 第三方安全报告）、社区已有的消减措施并给出安全加固建议。
威胁一：云端 CloudCore 组件与 EdgeCore 组件之间的连接
描述：该威胁涉及边缘 EdgeCore 与云端 CloudCore 之间的连接。在这个数据流中，较低信任级别组件 EdgeCore 向较高信任级别组件 CloudCore 发起访问。由于 EdgeCore 在系统中拥有独立的权限级别，攻击者控制 EdgeCore 后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控 CloudCore 来攻击其他节点（该漏洞描述引用自安全评估报告）。
影响：攻击者恶意修改 CloudCore 与 EdgeCore 组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。
消减措施：
• CloudCore 与 EdgeCore 之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用 TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；
• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于 KubeEdge 项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。
针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的 Recommendation ID 1 和 2）。
威胁二：边缘组件 ServiceBus 在本机范围内提供 HTTP 服务
描述：边缘组件 ServiceBus 监听本地 local host 端口并在本机范围内提供 HTTP 服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件 ServiceBus 发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。
影响：ServiceBus 组件收到的数据往往是不受管理面控制的，攻击者能够对 ServiceBus 组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus 组件异常仅影响单个边缘节点服务故障，不会导致整个 KubeEdge 系统崩溃。
消减措施：
• ServiceBus 组件仅监听本地 local host 端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；
• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止 ServiceBus 服务，阻止攻击继续进行；
• ServiceBus 服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。
针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的 Recommendation ID 3、4 和 5）。
威胁三：边缘端 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、4、5 和 6）。
威胁四：Edged 管理和监控 Pods 及其他 K8s 资源
描述：Edged 管理和监控 Pods 及其他 K8s 资源。该数据流中，较低信任级别的应用容器与较高信任级别组件 EdgeCore 之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。
影响：如果 Edged 访问的 CRI 插件被攻击者恶意伪造，则存在 CRI 插件仿冒和篡改的威胁风险，导致本地业务异常。
消减措施：
• Edged 与 CRI 插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化 Unix domain sockets 文件描述符的权限，避免被仿冒者恶意替换。
针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的 Recommendation ID 3 和 7）。
威胁五：MetaServer 在边缘节点提供 HTTP 服务
描述：MetaServer 作为边缘“api-server”，对边缘插件提供 HTTP 服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件 MetaServer 发起访问（该漏洞描述引用自安全评估报告）。
影响：MetaServer 组件收到的数据往往是不受管理面控制的，攻击者能够对 MetaServer 组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer 组件异常仅影响单个边缘节点服务故障，不会导致整个 KubeEdge 系统崩溃。
消减措施：
• MetaServer 组件仅监听本地 local host 端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；
• MetaServer 服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。
针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的 Recommendation ID 3、4 和 5）。
内部攻击分析
对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。
消减措施：
• KubeEdge 用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于 KubeEdge 的持续迭代，该文档也将持续更新并完善。
针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的 Recommendation ID 3、4、8 和 9）。
供应链攻击分析
攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。
消减措施：
• 社区联合安全公司对 KubeEdge 软件供应链流程已进行 SLSA 等级评估，并引入 SLSA 软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。
值得一提的是，在 2023 年 1 月 18 日发布的 v1.13.0 版本中，KubeEdge 项目已达到 SLSA L3 等级（包括二进制和容器镜像构件），成为 CNCF 社区首个达到 SLSA L3 等级的项目，并加入 Sigstore 生态系统，实现更高等级的安全标准。
• KubeEdge 仓库 CI/CD 流水线中已开启 dependence bot 第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在 KubeEdge 版本中同步更新，降低被攻击的风险；
• KubeEdge security team 已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。
针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的 Recommendation ID 10 和 11）。
安全加固建议列表
开源安全洞察
本章节通过对 OpenSSF 社区的战略规划、OpenSSF 工作组内容及开放源代码软件安全动员 10 个 TOP 计划进行介绍，为相关从业人员、开源生态产业提供参考。
1) OpenSSF 介绍
社区工作组
为了更好的提升开源软件安全，OpenSSF 目前已成立了 8 个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。
相关项目
1. OpenSSF 最佳实践徽章（OpenSSF Best Practices Badge Program）
开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过 OpenSSF 最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。
2. 积分卡（Scorecards）
通过 Scorecards 积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出 0-10 分数，帮助项目 maintainer 改进项目安全。
3. 安全知识框架（Security Knowledge Framework）
SKF 是一个完全开源的 Python-Flask / Angular 网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。
4. 安全开发指南
提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了 OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check 等。
5. 教育与培训课程
提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期 2 年。
6. 软件构建供应链级别（SLSA）
软件构建的供应链级别 SLSA 由 Google 贡献给 OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards 是 SLSA 度量的工具组成部分。
7. 令牌分发项目
Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。
8. 包管理最佳实践
提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。
当前文档还不完善，只重点介绍了 npm，其它的包管理器待建设中。
9. C/C++编译选项
制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。
10. 开源社区安全教育 SIG
当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。
OpenSSF 安全工具链
安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。
覆盖范围：涵盖整个 DevSecOps 的各环节工具链，并支撑开源软件开发的最佳实践章节，如：
linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。提供方：部分来自公司捐赠，部分来自 OpenSSF 基金会自主规划，部分在规划阶段待建设。
2) 开源软件安全动员计划及目标
2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：
• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞
• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复
• 缩短补丁响应时间：缩短漏洞披露和修复时间
在 2022 年 5 月第二届开源软件安全峰会上，Linux 基金会、OpenSSF 及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下 10 个方向进行投资和安全改善，项目投资 1.5 亿美元，分为两年规划。
备注：动员计划和 OpenSSF 工作组是相辅相成的，其动员计划的能力会融入到工作组中。
总结
本文通过从外部攻击面、内部攻击面及软件供应链三个维度对 KubeEdge 项目进行安全威胁建模，实现对 KubeEdge 项目的系统性安全评估，帮助社区 maintainer 及时发现和修复安全风险。同时，对业界 OpenSSF 社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge 社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。
附录
相关链接
• 社区漏洞处理机制: 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
• KubeEdge 实现 SLSA L3 分析: https://kubeedge.io/en/blog/reach-slsa-l3/
• Release 版本发布链接: https://github.com/kubeedge/kubeedge/releases
• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c
• OpenSSF 最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en
• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/5d5365026ef7af426ce61d1c5】。文章转载请联系作者。
提供全面深入的云计算技术干货 2020-07-14 加入
生于云，长于云，让开发者成为决定性力量
评论