跳到主要内容

29 篇博文 含有标签「KubeEdge」

查看所有标签

· 阅读需 15 分钟

北京时间2024年1月23日,KubeEdge发布1.16版本。新版本新增多个增强功能,在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。

KubeEdge v1.16 新增特性:

新特性概览

集群升级:支持云边组件自动化升级

随着KubeEdge社区的持续发展,社区版本不断迭代;用户环境版本升级的诉求亟需解决。针对升级步骤难度大,边缘节点重复工作多的问题,v1.16.0版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过Keadm工具一键化升级云端,并且可以通过创建相应的Kubernetes API,批量升级边缘节点。

  • 云端升级

    云端升级指令使用了三级命令与边端升级进行了区分,指令提供了让用户使用更便捷的方式来对云端的KubeEdge组件进行升级。当前版本升级完成后会打印ConfigMap历史配置,如果用户手动修改过ConfigMap,用户可以选择通过历史配置信息来还原配置文件。我们可以通过help参数查看指令的指导信息:

    keadm upgrade cloud --help
    Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components

    Usage:
    keadm upgrade cloud [flags]

    Flags:
    --advertise-address string Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79
    -d, --dry-run Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode
    --external-helm-root string Add external helm root path to keadm
    --force Forced upgrading the cloud components without waiting
    -h, --help help for cloud
    --kube-config string Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config")
    --kubeedge-version string Use this key to set the upgrade image tag
    --print-final-values Print the final values configuration for debuging
    --profile string Sets profile on the command line. If '--values' is specified, this is ignored
    --reuse-values reuse the last release's values and merge in any overrides from the command line via --set and -f.
    --set stringArray Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
    --values stringArray specify values in a YAML file (can specify multiple)

    升级指令样例:

    keadm upgrade cloud --advertise-address=<init时设置的值> --kubeedge-version=v1.16.0
  • 边端升级

    v1.16.0版本的KubeEdge支持通过NodeUpgradeJob的Kubernetes API进行边缘节点的一键化、批量升级。API支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此,KubeEdge支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现,只需聚焦云边任务功能本身。

    升级API样例:

    apiVersion: operations.kubeedge.io/v1alpha1
    kind: NodeUpgradeJob
    metadata:
    name: upgrade-example
    labels:
    description: upgrade-label
    spec:
    version: "v1.16.0"
    checkItems:
    - "cpu"
    - "mem"
    - "disk"
    failureTolerate: "0.3"
    concurrency: 2
    timeoutSeconds: 180
    labelSelector:
    matchLabels:
    "node-role.kubernetes.io/edge": ""
    node-role.kubernetes.io/agent: ""
  • 兼容测试

    KubeEdge社区提供了完备了版本兼容性测试,用户在升级时仅需要保证云边版本差异不超过2个版本,就可以避免升级期间云边版本不一致带来的问题。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5330 https://github.com/kubeedge/kubeedge/pull/5229 https://github.com/kubeedge/kubeedge/pull/5289

支持边缘节点的镜像预下载

新版本引入了镜像预下载新特性,用户可以通过ImagePrePullJob的Kubernetes API提前在边缘节点上加载镜像,该特性支持在批量边缘节点或节点组中预下载多个镜像,帮助减少加载镜像在应用部署或更新过程,尤其是大规模场景中,带来的失败率高、效率低下等问题。

镜像预下载API示例:

apiVersion: operations.kubeedge.io/v1alpha1
kind: ImagePrePullJob
metadata:
name: imageprepull-example
labels:
description:ImagePrePullLabel
spec:
imagePrePullTemplate:
images:
- image1
- image2
nodes:
- edgenode1
- edgenode2
checkItems:
- "disk"
failureTolerate: "0.3"
concurrency: 2
timeoutSeconds: 180
retryTimes: 1

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5310 https://github.com/kubeedge/kubeedge/pull/5331

支持使用Keadm安装Windows边缘节点

KubeEdge 1.15版本实现了在Windows上运行边缘节点,在新版本中,我们支持使用安装工具Keadm直接安装Windows边缘节点,操作命令与Linux边缘节点相同,简化了边缘节点的安装步骤。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/4968

增加多种容器运行时的兼容性测试

新版本中新增了多种容器运行时的兼容性测试,目前已集成了containerddockerisuladcri-o 4种主流容器运行时,保障KubeEdge版本发布质量,用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5321

EdgeApplication中支持更多Deployment对象字段的Override

在新版本中,我们扩展了EdgeApplication中的差异化配置项(overriders),主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时,就可以使用环境变量(env)或者命令参数(command, args)去重写中间件的链接信息。或者当您不同区域的节点资源不一致时,也可以使用资源配置(resources)去重写cpu和内存的配置。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5262 https://github.com/kubeedge/kubeedge/pull/5370

支持基于Mapper-Framework的Mapper升级

1.16版本中,基于Mapper开发框架Mapper-Framework构建了Mapper组件的升级能力。新框架生成的Mapper工程以依赖引用的方式导入原有Mapper-Framework的部分功能,在需要升级时,用户能够以升级依赖版本的方式完成,简化Mapper升级流程。

  • Mapper-Framework代码解耦:

    1.16版本中将Mapper-Framework中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力,仍会随Mapper-Framework生成在用户Mapper工程中,用户可根据实际情况修改。业务层功能包括Mapper向云端注册、云端下发Device列表等能力,会存放在kubeedge/mapper-framework子库中。

  • Mapper升级框架:

    1.16版本Mapper-Framework生成的用户Mapper工程通过依赖引用的方式使用kubeedge/mapper-framework子库中业务层功能,实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级Mapper的目的,不再需要手动修改大范围代码。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5308 https://github.com/kubeedge/kubeedge/pull/5326

DMI数据面内置集成Redis与TDEngine数据库

1.16版本中进一步增强DMI数据面中向用户数据库推送数据的能力,增加Redis与TDengine数据库作为内置数据库。用户能够直接在device-instance配置文件中定义相关字段,实现Mapper自动向Redis与TDengine数据库推送设备数据的功能,相关数据库字段定义为:

type DBMethodRedis struct {
// RedisClientConfig of redis database
// +optional
RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"`
}
type RedisClientConfig struct {
// Addr of Redis database
// +optional
Addr string `json:"addr,omitempty"`
// Db of Redis database
// +optional
DB int `json:"db,omitempty"`
// Poolsize of Redis database
// +optional
Poolsize int `json:"poolsize,omitempty"`
// MinIdleConns of Redis database
// +optional
MinIdleConns int `json:"minIdleConns,omitempty"`
}
type DBMethodTDEngine struct {
// tdengineClientConfig of tdengine database
// +optional
TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"`
}
type TDEngineClientConfig struct {
// addr of tdEngine database
// +optional
Addr string `json:"addr,omitempty"`
// dbname of tdEngine database
// +optional
DBName string `json:"dbName,omitempty"`
}

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5064

基于Mapper-Framework的USB-Camera Mapper实现

基于KubeEdge的Mapper-Framework,新版本提供了USB-Camera的Mapper样例,该Mapper根据USB协议的Camera开发,用户可根据该样例和Mapper-Framework更轻松地开发具体业务相关的Mapper。

在样例中提供了helm chart包,用户可以通过修改usbmapper-chart/values.yaml部署UBS-Camera Mapper,主要添加USB-Camera的设备文件, nodeName, USB-Camera的副本数,其余配置修改可根据具体情况而定,通过样例目录中的Dockerfile制作Mapper镜像。

global:
replicaCounts:
......
cameraUsbMapper:
replicaCount: 2 #USB-Camera的副本数
namespace: default
......
nodeSelectorAndDevPath:
mapper:
- edgeNode: "edgenode02" #USB-Camera连接的缘节点nodeName
devPath: "/dev/video0" #USB-Camera的设备文件
- edgeNode: "edgenode1"
devPath: "/dev/video17"
......

USB-Camera Mapper的部署命令如下:

helm install usbmapper-chart ./usbmapper-chart

更多信息可参考:

https://github.com/kubeedge/mappers-go/pull/122

易用性提升:基于Keadm的部署能力增强

  • 添加云边通信协议配置参数

    在KubeEdge v1.16.0中,使用keadm join边缘节点时,支持使用--hub-protocol配置云边通信协议。目前KubeEdge支持websocket和quic两种通信协议,默认为websocket协议。

    命令示例:

    keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx

    说明:当--hub-protocol设置为quic时,需要将--cloudcore-ipport的端口设置为10001,并需在CloudCore的ConfigMap中打开quic开关,即设置modules.quic.enable为true。

    操作示例:使用kubectl edit cm -n kubeedge cloudcore,将quic的enable属性设置成true,保存修改后重启CloudCore的pod。

    modules:
    ......
    quic:
    address: 0.0.0.0
    enable: true #quic协议开关
    maxIncomingStreams: 10000
    port: 10001

    更多信息可参考:

    https://github.com/kubeedge/kubeedge/pull/5156

  • keadm join与CNI插件解耦

    在新版本中,keadm join边缘节点时,不需要再提前安装CNI插件,已将边缘节点的部署与CNI插件解耦。同时该功能已同步到v1.12及更高版本,欢迎用户使用新版本或升级老版本。

    说明:如果部署在边缘节点上的应用程序需要使用容器网络,则在部署完edgecore后仍然需要安装CNI插件。

    更多信息可参考:

    https://github.com/kubeedge/kubeedge/pull/5196

升级K8s依赖到v1.27

新版本将依赖的Kubernetes版本升级到v1.27.7,您可以在云和边缘使用新版本的特性。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5121

版本升级注意事项

新版本我们使用DaemonSet来管理边端的MQTT服务Eclipse Mosquitto了,我们能够通过云端Helm Values配置来设置是否要开启MQTT服务。使用DaemonSet管理MQTT后,我们可以方便的对边端MQTT进行统一管理,比如我们可以通过修改DaemonSet的配置将边端MQTT替换成EMQX。

但是如果您是从老版本升级到最新版本,则需要考虑版本兼容问题,同时使用原本由静态Pod管理的MQTT和使用新的DaemonSet管理的MQTT会产生端口冲突。兼容操作步骤参考:

  1. 您可以在云端执行命令,将旧的边缘节点都打上自定义标签
kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""
  1. 您可以修改MQTT DaemonSet的节点亲和性
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- ...
- key: without-mqtt-daemonset
operator: Exists
  1. 将节点MQTT改为由DaemonSet管理
# ------ 边端 ------
# 修改/lib/systemd/system/edgecore.service,将环境变量DEPLOY_MQTT_CONTAINER设置成false
# 这步可以放在更新EdgeCore前修改,这样就不用重启EdgeCore了
sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service

# 停止EdgeCore
systemctl daemon-reload && systemctl stop edgecore

# 删除MQTT容器,Containerd可以使用nerdctl替换docker
docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f

# 启动EdgeCore
systemctl start edgecore

# ------ 云端 ------
# 删除节点标签
kubectl label nodes <NODE_NAME> without-mqtt-daemonset

新版本的keadm join命令会隐藏with-mqtt参数,并且将默认值设置成false,如果您还想使用静态Pod管理MQTT,您仍然可以设置参数--with-mqtt来使其生效。with-mqtt参数在v1.18版本中将会被移除。

· 阅读需 4 分钟

On Oct 13, 2023, KubeEdge released v1.15. The new version introduces several enhanced features, significantly improving support for Windows-based edge nodes, device management, and data plane capabilities.

v1.15 What's New

Release Highlights

Support Windows-based Edge Nodes

Edge computing involves various types of devices, including sensors, cameras, and industrial control devices, some of which may run on the Windows OS. In order to support these devices and use cases, supporting Windows Server nodes is necessary for KubeEdge.

In this release, KubeEdge supports the edge node running on Windows Server 2019, and supports Windows container running on edge node, thereby extending KubeEdge to the Windows ecosystem and expanding its use cases and ecosystem.

Refer to the link for more details. (#4914, #4967)

New v1beta1 version of Device API

The device API is updated from v1alpha2 to v1beta1, in v1beta1 API updates include:

  • The built-in protocols incude Modbus, Opc-UA and Bluetooth are removed in device instance, and the built-in mappers for these proytocols still exists and will be maintained and updated to latest verison.

  • Users must define the protocol config through CustomizedValue in ProtocolConfig.

  • DMI date plane related fields are added, users can config the collection and reporting frequency of device data, and the destination to whcih(such as database, httpserver) data is pushed.

  • Controls whether to report device data to cloud.

Refer to the link for more details. (#4983)

Support Alpha version of DMI DatePlane and Mapper-Framework

Alpha version of DMI date plane is supported, DMI date plane is mainly implemented in mapper, providing interface for pushing data, pulling data, and storing data in database.

To make writing mapper easier, a mapper development framework subproject Mapper-Framework is provided in this release. Mapper-Framework provides mapper runtime libs and tools for scaffolding and code generation to bootstrap a new mapper project. Users only need to run a command make generate to generate a mapper project, then add protocol related code to mapper.

Refer to the link for more details. (#5023)

Support Kubernetes native Static Pod on Edge Nodes

Kubernetes native Static Pod is supported on edge node in this release. Users can create pods on edge nodes by place pod manifests in /etc/kubeedge/manifests, same as that on the Kubernetes node.

Refer to the link for more details. (#4825)

Support more Kubernetes Native Plugin Running on Edge Node

Kubernetes non-resource kind request /version is supported from edge node, users now can do /version requests in edge node from metaserver. In addition, it can easily support other non-resource kind of requests like /healthz in edge node with the curent framework. Many kubernetes plugins like cilium/calico which depend on these non-resource kind of requests, now can run on edge nodes.

Refer to the link for more details. (#4904)

Upgrade Kubernetes Dependency to v1.26.7

Upgrade the vendered kubernetes version to v1.26.7, users are now able to use the feature of new version on the cloud and on the edge side.

Refer to the link for more details. (#4929)

Important Steps before Upgrading

  • In KubeEdge v1.15, new v1beta1 version of device API is incompatible with earlier versions of v1alpha1, users need to update the device API yamls to v1bata1 if you want to use v1.15.

  • In KubeEdge v1.15, users need to upgrade the containerd to v1.6.0 or later. Containerd minor version 1.5 and older will not be supported in KubeEdge v1.15.
    Ref: https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal

  • In KubeEdge v1.14, EdgeCore has removed the dockeshim support, so users can only use remote type runtime, and uses containerd runtime by default. If you want to use docker runtime in v1.15, you also need to first set edged.containerRuntime=remote and corresponding docker configuration like RemoteRuntimeEndpoint and RemoteImageEndpoint in EdgeCore, then install the cri-dockerd tools as docs below: https://github.com/kubeedge/kubeedge/issues/4843

· 阅读需 3 分钟

On July 1, 2023, KubeEdge released v1.14. The new version introduces several enhanced features, significantly improving security, reliability, and user experience.

v1.14 What's New

Release Highlights

Support Authentication and Authorization for Kube-API Endpoint for Applications On Edge Nodes

The Kube-API endpoint for edge applications is implemented through MetaServer in edegcore. However, in previous versions, the authentication and authorization of Kube-API endpoint are performed in the cloud, which prevents authentication and authorization especially in offline scenarios on the edge node.

In this release, the authentication and authorization functionalities are implemented within the MetaServer at edge, which allows for limiting the access permissions of edge applications when accessing Kube-API endpoint at edge.

Refer to the link for more details. (#4802)

Support Cluster Scope Resource Reliable Delivery to Edge Node

The cluster scope resource can guarantee deliver to the edge side reliably since this release, especially include using list-watch global resources, the cluster scope resource can be delivered to the edge side reliably, and the edge applications can work normally.

Refer to the link for more details. (#4758)

Upgrade Kubernetes Dependency to v1.24.14

Upgrade the vendered kubernetes version to v1.24.14, users are now able to use the feature of new version on the cloud and on the edge side.

备注

The dockershim has been removed, which means users can't use docker runtime directly in this release.

Refer to the link for more details. (#4789)

Support Kubectl Attach to Container Running on Edge Node

KubeEdge already support kubectl logs/exe command, kubectl attach is supported in this release. kubectl attach command can attach to a running container at edge node. Users can execute these commands in the cloud and no need to operate on the edge nodes.

Refer to the link for more details. (#4734)

Alpha version of KubeEdge Dashboard

KubeEdge dashboard provides a graphical user interface (GUI) for managing and monitoring your KubeEdge clusters. It allows users to manage edge applications running in the cluster and troubleshoot them.

Refer to the link for more details. (https://github.com/kubeedge/dashboard)

Important Steps before Upgrading

  • On KubeEdge v1.14, EdgeCore has removed the dockeshim support, so users can only use remote type runtime, and uses containerd runtime by default. If you want to use docker runtime, you must first set edged.containerRuntime=remote and corresponding docker configuration like RemoteRuntimeEndpoint and RemoteImageEndpoint in EdgeCore, then install the cri-dockerd tools as docs below: https://github.com/kubeedge/kubeedge/issues/4843

· 阅读需 14 分钟
Vincent Lin

KubeEdge 社区已于 2022 年 7 月份完成整个 KubeEdge 项目的第三方安全审计,已发布云原生边缘计算安全威胁分析和防护白皮书,并根据安全威胁模型和安全审计的建议,对 KubeEdge 软件供应链进行持续安全加固。经过社区的不断努力,我们很兴奋地宣布,在 2023 年 1 月 18 日发布的 v1.13.0 版本中,KubeEdge 项目已达到 SLSA L3 等级(包括二进制和容器镜像构件),成为 CNCF 社区首个达到 SLSA L3 等级的项目。

为什么说达到 SLSA L3 等级对 KubeEdge 项目十分重要

软件供应链完整性攻击(对软件包的未经授权的修改)在过去三年中呈上升趋势,KubeEdge 实现 SLSA L3 等级标准后,可以端到端的从源码构建到发布流程进行安全加固,保障用户获取到的二进制或容器镜像产物不被恶意篡改。基于 SLSA 安全框架,可以潜在地加强软件构件的完整性。SLSA 提供端到端的指导原则,可以作为软件的一组防御措施,并防止对组成软件产品的软件包的篡改或任何类型的未经授权的修改。采用 SLSA 框架可以保护项目软件免受常见的供应链攻击。

关于 SLSA

什么是 SLSA(Supply chain Levels for Software Artifacts 软件构件的供应链级别):

Google 提出的用于保证整个软件供应链完整性的框架 SLSA,是一套基于行业共识的安全准则,也是一个安全框架、一份标准和控制清单,用于防止篡改、提高完整性以及保护项目、业务或企业中的软件包和基础设施。它不是一个单一的工具,而是一个逐步采用的大纲,以防止工件被篡改和被篡改的工件被使用,并在更高层次上强化构成供应链的平台。生产商遵循 SLSA 准则使他们的软件更加安全,用户则根据软件包的安全状况来做出决策。

截止目前,SLSA 标准处于 alpha 阶段,相关的定义可能会发生变化。

下图描述了软件供应链中已知的攻击点。更多详细描述,可参考https://slsa.dev/

slsa-dev

SLSA 框架引入了许多新的工具和概念,例如:

  • Artifact(软件制品):由构建流水线生成的任何制品文件,如容器镜像、语言包、编译的二进制文件等;
  • Provenance (来源证据链): 构建的元数据包括构建过程、构建源和依赖关系;
  • Digest (数字摘要):加密哈希函数的结果,该函数生成唯一标识工件的固定大小值,例如容器镜像的 SHA-256 哈希;
  • Attestation (证书):一个加密签名的文件,记录当时生成软件产物的来源;
  • Immutable references(不可变引用-一种标识符):,保证始终指向相同的、不可变的软件制品,如特定的容器图像或语言包;
  • Build integrity(构建完整性):验证构建流水线的输出完整性。

KubeEdge 项目如何达到 SLSA L3

截止目前,SLSA 评估等级共分为 4 个等级 L1~L4,安全性由低到高,每个等级有不同的达标要求,详细的达标要求可参考 SLSA 详细标准(https://slsa.dev/spec/v0.1/requirements)。

在去年 7 月发布的第三方安全审计报告中,KubeEdge 项目在软件供应链 SLSA Provenance 维度暂未达到 L3 等级,经过 SIG-Security 的持续安全加固,在今年 1 月发布的 v1.13.0 版本中,KubeEdge 项目在所有的 SLSA 维度中均达到 L3 等级。以下表格展示了 KubeEdge 在SourceBuildProvenanceCommon中的达标情况(Y 表示 KubeEdge 已达标,空格表示 SLSA 在该等级下未要求)。

SLSA 评估表格及达标情况

RequirementL1L2L3L4
Source
Version controlledYYY
Verified historyYY
Retained indefinitelyYY
Two-person reviewedY
Build
Scripted buildYYYY
Build ServiceYYY
Build as codeYY
Ephemeral environmentYY
IsolatedYY
ParameterlessY
HermeticY
Provenance
AvailableYYYTODO
AuthenticatedYYTODO
Service generatedYYTODO
Non-falsifiableYTODO
Dependencies completeTODO
Common
SecurityY
AccessY
SuperusersY

本章节将着重介绍 KubeEdge 如何达成 SLSA L3 等级在 Build、Provenance 维度的要求。Build/Provenance Requirements 及 KubeEdge 相应的解决方案如下。

Build Requirements:

a) 通过脚本构建:所有的构建步骤都是通过脚本自动化执行。

b) 通过构建服务进行构建:所有的构建步骤由构建服务完成,不在开发者本地环境。构建服务如 GitHub Actions、第三方云平台提供的构建服务等。

c) 作为源码构建:构建服务执行的构建定义文件和配置文件来源于版本控制系统中的文本文件,并且是可验证的。

d) 构建环境临时性:构建服务确保构建步骤在临时环境中运行,例如容器或 VM,仅为此构建提供,而不是复用先前的构建 。

e) 构建的隔离性:构建服务确保构建步骤在隔离的环境中运行,不受其他构建实例(无论是先前的还是并发的)的影响。

f) 无用户自定义参数:除了构建入口点和初始源配置之外,构建输出不会受到用户参数的影响。换句话说,构建完全是通过构建脚本定义的,而不是其他。

g) 封闭性:所有可传递的构建步骤、源和依赖项都使用不可变引用预先完全声明,并且构建步骤在没有网络访问的情况下运行。

解决方案:

KubeEdge 项目所有的构建流程均在 GitHub 上由脚本自动化执行,GitHub Actions 作为构建服务(相关的定义文件和配置文件保存在.github/workflows 目录下),可保障构建过程的可回溯、可验证以及构建环境的临时性、隔离性、构建参数和依赖项不可篡改。

Provenance Requirements:

a) 可用性:Provenance 通过用户可接受的格式提供。应该满足 SLSA Provenance 格式,但如果生产商和用户都同意,并且满足所有其他要求,可以使用另一种格式。

b) 可验证:Provenance 的真实性和完整性可以由用户验证。这应该通过来自私钥的数字签名来实现,只有生成 Provenance 的服务才能访问私钥。

c) 通过构建服务生成:Provenance 中的数据必须从构建服务中获得。

d) 不可伪造:构建服务的用户不能伪造 Provenance。

e) 第三方依赖的完整性:Provenance 记录运行构建步骤时可用的所有构建依赖项。包括构建的机器、VM 或容器的初始状态。

解决方案:

在 KubeEdge 版本发布的产物中,包括二进制文件和容器镜像 2 种格式,通过集成 SLSA 官方的 GitHub 构建项目 slsa-github-generator 来实现 SLSA L3 等级。

在 KubeEdge 版本发布的流程(.github/workflows/release.yml)中,集成了 slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml 和 slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml,可保障构建和发布产物(包括二进制文件和容器镜像)的流程满足 SLSA L3 等级的要求。

更多关于 slsa-github-generator 的详细说明请见https://github.com/slsa-framework/slsa-github-generator

关于 Provenance

Provenance 是构建的元数据包括构建过程、构建源和依赖关系,是软件构建和发布执行流程的一种证明,并且是可以被验证的,包括构建的源码仓库、代码分支、配置文件等信息。在 SLSA L3 级别,Provenance 内容是真实的、防篡改的,并且不会被项目维护者更改。二进制发布产物的 Provenance 文件随发布软件包一起发布,名称为 multiple.intoto.jsonl,容器镜像的 Provenance 文件随镜像文件一起上传到 KubeEdge dockerhub 公开仓库中。具体的 Provenance 格式说明,请参考https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#provenance-format。

如何校验 KubeEdge 发布产物是否满足 SLSA L3 等级

详细步骤描述请见https://github.com/kubeedge/kubeedge/pull/4285

校验示例如下:

$ COSIGN_EXPERIMENTAL=1 cosign verify-attestation --type slsaprovenance --policy policy.cue kubeedge/cloudcore:v1.13.0
{
"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": "https://slsa.dev/provenance/v0.2",
"subject": [{
"name": "index.docker.io/kubeedge/cloudcore",
"digest": {
"sha256": "825642e63ab5b924e2fa0661cd14d544d0be151c4bdba6f3f42796c977fbe211"
}
}
],
"predicate": {
"builder": {
"id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.4.0"
},
"buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1",
"invocation": {
"configSource": {
"uri": "git+https://github.com/kubeedge/kubeedge@refs/tags/v1.13.0",
"digest": {
"sha1": "ee357a0d5341241143e88d45df99fde865c987de"
},
"entryPoint": ".github/workflows/release.yml"
},
...

SLSA GitHub generator 签名和验证原理

使用 OpenID Connect (OIDC) 向外部服务 (Sigstore) 证明工作流的身份。OpenID Connect (OIDC) 是身份提供商在网络上使用的标准,用于为第三方证明用户的身份。 GitHub 现在在其工作流程中支持 OIDC。每次运行工作流程时,运行者都可以从 GitHub 的 OIDC 提供商处创建一个唯一的 JWT 令牌。令牌包含工作流身份的可验证信息,包括调用者存储库、提交哈希、触发器以及当前(可重用)工作流路径和引用。

使用 OIDC,工作流向 Sigstore 的 Fulcio 根证书颁发机构证明其身份,后者充当外部验证服务。 Fulcio 签署了一份短期证书,证明运行器中生成的临时签名密钥并将其与工作负载身份相关联。签署出处的记录保存在 Sigstore 的透明日志 Rekor 中。用户可以使用签名证书作为信任方来验证来源是否经过身份验证且不可伪造;它必须是在受信任的构建器中创建的。流程图如下所示。

sigstore

值得一提的是,SLSA GitHub generator 获得 sigstore 社区 2022 年度徽章 Best User Adopter。

best-user-adopter

总结

SLSA 在 KubeEdge 项目软件供应链安全中发挥着重要作用。基于 sigstore 社区提供的能力,从源码到发布产物,对软件供应链端到端的整个流程进行签名和校验,确保 KubeEdge 软件供应链安全。

相关参考:

https://slsa.dev/

https://www.sigstore.dev/

https://github.com/slsa-framework/slsa-github-generator

https://slsa.dev/blog/2022/08/slsa-github-workflows-generic-ga

https://security.googleblog.com/2022/04/improving-software-supply-chain.html

https://blog.sigstore.dev/sigstore-november-roundup-8a852cec10fc/

· 阅读需 3 分钟

On Jan 18, 2023, KubeEdge released v1.13. The new version introduces several enhanced features, significantly improving performance, security, and edge device management.

v1.13 What's New

Performance Improvement

  • CloudCore memory usage is reduced by 40%, through unified generic Informer and reduce unnecessary cache. (#4375, #4377)

  • List-watch dynamicController processing optimization, each watcher has a separate channel and goroutine processing to improve processing efficiency (#4506)

  • Added list-watch synchronization mechanism between cloud and edge and add dynamicController watch gc mechanism (#4484)

  • Removed 10s hard delay when offline nodes turn online (#4490)

  • Added prometheus monitor server and a metric connected_nodes to cloudHub. This metric tallies the number of connected nodes each cloudhub instance (#3646)

  • Added pprof for visualization and analysis of profiling data (#3646)

  • CloudCore configuration is now automatically adjusted according to nodeLimit to adapt to the number of nodes of different scales (#4376)

Security Improvement

  • KubeEdge is proud to announce that we are digitally signing all release artifacts (including binary artifacts and container images). Signing artifacts provides end users a chance to verify the integrity of the downloaded resource. It allows to mitigate man-in-the-middle attacks directly on the client side and therefore ensures the trustfulness of the remote serving the artifacts. By doing this, we reached the SLSA security assessment level L3 (#4285)

  • Remove the token field in the edge node configuration file edgecore.yaml to eliminate the risk of edge information leakage (#4488)

Upgrade Kubernetes Dependency to v1.23.15

Upgrade the vendered kubernetes version to v1.23.15, users are now able to use the feature of new version on the cloud and on the edge side.

Refer to the link for more details. (#4509)

Modbus Mapper based on DMI

Modbus Device Mapper based on DMI is provided, which is used to access Modbus protocol devices and uses DMI to synchronize the management plane messages of devices with edgecore.

Refer to the link for more details. (mappers-go#79)

Support Rolling Upgrade for Edge Nodes from Cloud

Users now able to trigger rolling upgrade for edge nodes from cloud, and specify number of concurrent upgrade nodes with nodeupgradejob.spec.concurrency. The default Concurrency value is 1, which means upgrade edge nodes one by one.

Refer to the link for more details. (#4476)

Test Runner for conformance test

KubeEdge has provided the runner of the conformance test, which contains the scripts and related files of the conformance test.

Refer to the link for more details. (#4411)

EdgeMesh: Added configurable field TunnelLimitConfig to edge-tunnel module

The tunnel stream of the edge-tunnel module is used to manage the data stream state of the tunnel. Users can obtain a stable and configurable tunnel stream to ensure the reliability of user application traffic forwarding.

Users can configure the cache size of tunnel stream according to TunnelLimitConfig to support larger application relay traffic.

Refer to the link for more details. (#399)

Cancel the restrictions on the relay to ensure the stability of the user's streaming application or long link application.

Refer to the link for more details. (#400)

Important Steps before Upgrading

  • EdgeCore now uses containerd runtime by default on KubeEdge v1.13. If you want to use docker runtime, you must set edged.containerRuntime=docker and corresponding docker configuration like DockerEndpoint, RemoteRuntimeEndpoint and RemoteImageEndpoint in EdgeCore.