不好意思因为那个投影投不了所以现在可能没有办法开始讲所以我们就现在如果有现场有人有对哈伯有什么问题我们就可以现场回答如果有需要的话我们就现在就暂时进入那个Q&A环节所以我们可以探讨一下我们今天的三成主要讲一下就是哈伯尔最近的一些进展然后关于2.9的一些功能以及后续的我们的一些诶 您说呃 就是我现在知道就是哈伯已经implemented OCI SPIKE 1.1的一部分的内容对吧对对对呃 应该现在是implemented OCI SPIKE 1.1的RC2对吧对的那有没有计划不如更新到最新的RC5呃 您是说distribution spike还是Image spike呃 我们Image spike实际上其实我下午四点会有一个算省和那个notation那边 就是AURUS嗯然后我们实际上是基于RC4的一个一个implementation所以我们是我们的计划是会support image spike呃 and distribution spike的GA呃 所以一旦他们GA的话我们马上就会出版本去support然后今天的demo我们会有一些关于spike的一些support啊 好的然后如果下午您如果感兴趣的话我可以去我们那个跟VIRUON的一个一个呃 对呃 那边我们会更详细的讲一下那个spike的support呃 好的 好的呃 反正我是一个AURUS的mantana啊 好的OK 你好 你好呃 所以说 呃 之后的话我们会在AURUS的AURUS Go的2.4会支持到Image spike ofRC5OK OK其实我们现在在Distribution spike已经支持到RC3嗯所以我们的demo实际上是完全是非常的smoothly的因为在AURUS client和harbor之间我们继续一个spike所以大家是不需要做任何的codes of customization所以我们就可以smoothly to support对方所以就是多说一点就是基于这个spike然后harbor是可以接入任何基于这个spike clientlike a cosine notation AURUS对好的 好的谢谢多谢呃 sorry就是我们今天可能主要会讲一些2.9上面harbor的一些增强然后我们呃 主要是针对于过去一些社区反馈的一些意见以及主要是我们对于安全性做了一些增强因为呃 从Sinsafe这边的一个呃趋势来看就是呃 container image的一个安全性对于对于大家是一个重要的一个考量所以我们对于harbor是一个Sinsafe的一个ofci的register所以我们针对于container安全性上面做了很多那个一些增进所以我们单独有一个security harbor的一个feature专门是对CVE的一个总揽然后呃 提供system admin的一些对于整个你overall harbor的一个安全性的一个概括包括一些你对CVE的一些filter比如说呃在过去的一些feature上面比如说harbor是可以支持image的expanding然后但是呃 社区用户很多反馈对我们来讲说我想知道某一个CVE到底感染了哪些harbor系统里的镜像然后他们现在需要做的事情是说我需要一个一个的去查每一个artifact的一个report比如说我有一个lock foge的CVE那我想知道这个lock foge的CVE到底影响了我整个harbor系统上面哪些artifact所以我需要去one by one去check但是现在我们提供了一个centralized一个CVE的desk for这样的话大家是可以在整个这个一个集中式的desk for去查你的CVE然后通过for example你可以通过CV的ID去search你这个CVE到底是影响了系统里哪些artifact所以这些呃是比较有效高效的功能去让你的set a mean对整个harbor是有一个系统性的踪览你的安全性怎么样然后你有哪些呃高微的artifact比如说你你整个系统里面拥有CVE最多的一些artifact是哪些你作为一个系统管理员你就要pay attention to这些CVE因为你这些CVE这些artifact是有非常多的CVE然后如果你还在生产中使用这些artifact那就是一个非常不不合适的一个行为另外就说说另外一个您好您说有新的零对或者新的新的零对或者新的CVE生产的时候这个在这个库里面是怎么更新的是可以自动输入还是从哪个地方有一个统一拉取您是说CVE因为CVE本身的如果有更新或者有新的零对发现之后对因为我们现在使用的是Trivia作为一个CVE的adapter所以Trivia是有一个Krown的去拉取Database的一个行为它会从Database的CVE库去后台与周期性的去拉取最近就是从上游去统布过来对吧对的那有就是我太了解有知识这种人工的输入或者人工去维护这个可以的因为Harbor的用户的一些使用场景是说它是在Edge的上面它使用于Harbor实际上是没有网络的然后它们是可以offline去导入你的CVE的Database这样的话你是可以周期性的找一个还继续下载你的Database然后去offline去import到你的Harbor的scanner里面然后这样的话也可以实时的保持更新OK 我没问题谢谢另外一个增强就是说我们实际上是在总体的一个列表上上可以看到整个系统里你需要最重要关注的一些CVE有哪些比如说我们需要我们会列出来一些CVE使用非常高的一些CVE给系统管理员那它就可以看到这个CVE是被哪些artifact包含然后这些artifact如果还是在生产中使用那这些就不太合适OK因为我们这些所有做的增强其实大部分都是从社区的一些反馈我们收集了一些意见或者是一些无论是社区的用户还是企业用户给我们的一些feedback所以我觉得我们非常热衷于听大家的意见所以我们可以有非常多的取造SlackChannel Github包括现场的这种face to face大家都可以反馈你们在使用过程中遇到一些问题比如说我们今天给大家讲的这些增强包括CVE 包括GC包括一些Mentennas的Message的一些Customization这些东西都是在用户在他们的生产环境中遇到的实际问题然后他们说OK 这Hobber能不能有这样的一个增强能不能有这样的一个功能然后大家反馈给我们之后我们实际上会交给我们的PM去做考量然后我们会根据我们的一些Priority会把它放到我们的弱慢里面然后放到我们的未来的某一个Release里面所以不好意思我们可能今天Slice这边有点问题所以我们会严实一点点加上我们今天的Session今天我们是Hobber的Mentennas的Session然后由我跟陈宇我们两个都是来自于Hobber的Team的Mentennas然后我叫王妍然后目前是在Mentennas in Step下面的Hobber和Distribution两个项目然后我主要现在在Hobber做Technical Lead好 大家好我叫庄淳宇然后我目前是Hobber的Mentennas今天主要是给大家带来我们Hobber项目最新的一些进展好 那么我们今天的这个分享呢主要会分成几个方面那么首先我会为大家介绍一下Hobber项目它的一个整体的一个功能以及它的一些架构等等帮助大家更好的来了解Hobber这个项目了解它能给用户带来哪些价值那么第二部分呢是这个关于我们在2.9的做的一些这个最新的一些功能上的一些分享那么这些功能呢其实也都是来源于社区的一些这些呃 开的需求啊或者是反馈的一些问题那么第三部分呢我们会为了能够让大家更清晰的去了解到这些功能呢我们也做了一个简单的demo会由王妍为我们分享那么第四部分呢是这个关于未来的我们的这个呃Hobber的功能上的一些我们即将可能打算去实现的这些功能那么最后一部分就是关于如果你对Hobber的有兴趣想加入Hobber的开发或者是问题的讨论我也欢迎加入我们的这个这个这个一些讨论渠道来来加入到Hobber的这个贡献当中去呃 那么首先是关于什么是Hobber呢那Hobber它是一个开源的远远深的这么一个制品仓库那么这里也可以简单和大家分享一下Hobber项目的一个成长史吧那么最早呢那么大家都知道1314年的时候Docker技术的一个火热把这个容器进向呃 也是至于一个非常重要的一个地位因为包括Docker公司的这个口号Build ship and run嘛那这些这三action所对应的这个对象其实都是容器进向那所以Hobber就是这样一个项目它是去最早呢呃 呃 最早呢这个Docker公司呢也提供了一个这个Distribution这个项目那这个项目它仅仅是提供了一个基础的这个进向的铺式的功能但是对于企业用户使用的使用来说的话其实光有这些基础的功能是不够的所以Hobber在这个基础上呢去增加了一些企业级的功能呃 那么Hobber项目最早呢是14年在这个VML 中国研发中心内部的一个实验项目当时还不叫Hobber 叫Crain那么后来经过两年多的一个发展在16年的时候呢更名为Hobber 并且开源到GitHub那么在开源到GitHub之后呢又经过社区用户的一些反馈以及迭代呃 我们就在18年的时候加入了这个CNCF基金会那么加入基金会之后呢又经过这个也是得益于CNCF的一个支持以及这个广大Hobber社区用户啊以及这些贡献者的一个支持我们也是在2020年呢成功从这个CNCF基金会毕业那么也是中国首歌从这个CNCF毕业的一个项目那么毕业的概念呢毕业的含义呢就意味着因为CNCF对一个项目的一个这个阶段是以成熟度来作为一个区分的那么从CNCF毕业呢就意味着这个项目已经达到了一个比较成熟稳定的阶段可以去放心的去在深调环境上去做一个使用好 那么接下来是Hobber给用户提供的一些核心功能那主要涵盖一下这几个方面嘛首先是全线控制这一块因为大家知道在企业级去使用一个一些软件的时候我们对于这个这个全线这一块其实还是很严格的所以说Hobber也提供了以项目为维度的一个隔离机制并且每个项目之间呢能够去配置不同的角色以及用户那么不同的角色它是被赋予不同的权限比如有的角色它可能只有铺的权限那有的角色可能既有铺也有铺式的权限那么还有一些更高级的这个角色可能拥有这个Delete或者是一些Mantanas的这个权限所以这也就是Hobber的RBAC的这一套体系也就是构建于我们的这个设计之上的那么第二部分是这个关于这个制品的一个分发这一方向因为现在随着这个企业的规模的一个增长那大家的这个集权规模可能都是非常的庞大包括可能会用到公有云 私有云 混合云甚至是易购的这些架构那么往往单一的这种进向仓库是没有办法满足这个企业的这个场景的所以说我们也是从几个方面吧来提供了这样把进向分发到多地多数据中心的这么一个能力Replication的话其实是可以将Hobber上的进向去分发到这个对端的这个进向仓库上去比如说你可以将Hobber上的进向备份到这个不同的Register比如说阿里云 腾讯云等等那么ProxyCache呢是以一个它可以将一个项目去设置成一个Proxy的这种类型那么设置成Proxy类型之后呢这个项目就会以一个代理的这种模式去运行那么以代理模式去运行之后呢它能够将上有的这些进向去缓存到Hobber上那么这样的话当用户下一次再去从这个Hobber上去铺进向的时候就不需要再从远端去铺而是直接从Hobber上去铺这样的话可以节省你对上有upstream的一个访问那么在一些上有upstream有Rate Limit的场景下这个功能会比较有效那么另外一个是大家现在的极限规模可能非常的大可能达到上千的这个节点那对于这些上千的节点往往我们可能会有同时部署某个应用的这种场景那这些应用它可能是以demonset的这种形式也就是每个node上都会去部署这样的一个镜像那么这个时候如果在这个场景下我们依然使用这种单一的进向仓库去拉取形象的话那这个效率会很低对于进向仓库也是一个非常大的压力所以Hobber也是提供了一个P2P pre-hate的这么一个功能那这个功能可以说是将Hobber的能力和一些分布式的这种P2P的进向仓库的能力做了一个结合 做了一个集成那像这个Dragonfly或者是Kraken他们提供了这种通过P2P网络的这种方式来加速这个进向的一个分发而Hobber可以作为一个上游的这么一个仓库去把一些比较热点的这些进向提前的去预热分发到这个进向仓库提前分发到这个P2P的这个网络里面去那么第三部分也是现在比较重视的一部分就是安全和合规这部分那么在这一部分Hobber也提供了一项例如进向扫描 进向签名以及CVE的导出这些功能因为有的安全审计部门可能会需要知道了解我当前系统里有多少个CVE那这些CV最终我希望以一个表格的形式作为一个证明去下载下来那么另外还有就是刚刚王焱提到的我们这个Secret Hub的一个能力那么因为之前的Hobber上缺少一个全局的这么一个安全的视角来看整个我系统里的一些健康状况或者安全状况所以这个功能也是填补了这一块的空白那么第四部分在可维护性方面Hobber其实是提供了基于策略的这种维护机制那么用户可以以策略来驱动它的一个整个Hobber的维护比如说像一些call它的配额的配置一些retention一些GC的这些配置那么通过这些功能以及policy的这些配合的一个使用可以让你的Hobber达到一个自运为的这么一个状况就是说让你的Hobber的整个的一个存储包括空间不会一直无限的增长而是能保持一个比较健康的一个状况那么最后一部分是可扩展性方面可扩展性方面因为你作为一个系统你肯定是需要与外部的一些系统去做一些销货的所以可扩展性也是非常重要的一部分那么Hobber也提供了基于OIDC和LDAP的这种认证机制能够方便地将Hobber和企业本身的这种账号全线体系去做一个打通那么另外还有像这个Webhook的机制能够帮助用户去将Hobber上的一些事件去推送到用户的这个事件服务中来帮助他们更好的审计或审查之类的那么在Scan部分呢因为Hobber其实我们都知道Kubernetes是有CNI这样的一个定义来适配这个多个厂商的这种运行室或者是这种规范那Hobber同时也提供了一个parkable的Scanner的这么一个规范那也就是说不同的安全厂商只要followHobber的这个规范就能够很轻松地去将自己的这个Scanner集成到Hobber上来那么还有一些这个用户可能在也会大家现在在用一些DevOps的理念可能会在CICD中去build或者铺式进向那在CICD中去构建铺式进向的话你如果去使用一个比较权限大的账户那也是一个安全问题所以我们也提供了这个Robot Account能力可以去细化这个权限能够保证你的这个使用的账号能够是一个比较最小的一个权限那这样的话也会比较安全好 那目前Hobber的一个安装呢其实我们也是提供了一些灵活的方式那么最基础最简单的一种呢就是Dog Compose的方式Dog Compose我们提供了两种安装猫一种是离线安装猫一种是在线安装猫离线安装猫的话就是把Hobber的这些所有的镜像都已经打包到同一个这个规档文件里面中那大家去部署的话通过离线安装猫去部署是不需要依赖外网环境的在线安装猫的话就是仅仅是Hobber的一个Page的一个模板那这些最终的这些Hobber组建的镜像是需要通过Dog Hub上去拉取形象来下载的那这个是需要外网的一个环境保证的那么第二种是目前也是比较用的多的这种方式就是Helm Chat因为大家现在都可以用KyS嘛那所以Helm Chat可以帮助用户在KyS集群中去部署一个Hobber并且能够去配置一些这种高可用这种可困难性的一些配置那么最后一种也是比较高级的一种方式就是它和前两种方式的不同在于除了提供基础的Hobber实力的一个部署它还提供了一些这种Day2的operation的操作就是它能够通过这种CRD的这种机制将一些Hobber上的项目的一些配置等等通过CR的定义然后以KyS Control的这种模式去将这些配置Apply到Hobber上那么这种方式它的缺点就是说它有一个学习成本你可能需要去了解KyS的CRD的这种机制以及它的一些概念等等那么这个图是Hobber的一个整体的一个架构图那么最上层是Hobber的客户端也就是DawnClient、Couplet等等那么再往下我们可以把它分成三层来看待分别是代理层、服务层和数据层那么它们分别对应的其实是一个由外到内的一个顺序那么最上层是一个代理层代理层的话其实是一个以API Pass为路径的这么一个代理服务它可能是一个NGIX也可能是你的English Controller那它基于这种API的路径将不同的请求分发到Hobber不同的组件上因为Hobber本身是一个微服的一个架构那么再往下是Hobber的自己的一些组件首先是HobberCoreHobberCore其实可以理解成是Hobber的API Server它也是Hobber的大脑它负责所有API请求的一个handle和处理包括键权、中间键的一些处理等等那么再往下就是一些第三方的一些组件像Notary Charger Museum虽然这些已经被deprecated掉了但是之前他们就是以第三方组件的这种形式存在的那么最后最底下这一层就是数据层也就是最终这些拥护的数据以及进向的数据它们最终存储的一个地方那像Hobber的话是采用了Redis来作为一个缓存然后PG数据库作为一个Hobber里的这些原信息的一个存储以及还有像进向的这些层数据的存储我们可以通过本地的文件、文件块或者是一些S3或者是一些云存储的这种方式那么左侧部分我们也可以看到Hobber也提供了可观测性的一个能力可以通过普罗米修斯来暴露你的Hobber上的一些应用的指标比如说你当前有多少个进向你进向被铺了多少次那么同时还支持这个通过Yager来做一个分布式的一个追踪也就是说你可以通过这个集成Yager的方式来查看你的API请求它的一个不同的一个耗时的一个情况能够帮助你更快的定位这种性能问题那么右侧部分是这个Hobber支持的一些Scan的Scanna的这些厂商目前可能会有更多像Clare像Truevy等等目前Truevy也是作为Hobber more than的一个Scanna那么像Replication的Provider目前也支持很多的公有营私有营或者是一些这种其他的开源产品像DogHub、华为的Amazement、Google等等好,那么接下来带大家一起来看一下这个我们在2.9里面去提供的一些功能首先是Security Hub因为刚刚说到Hobber一直缺少一个这种全局的安全的视角那么所以Security Hub填补了这一块的一个空白那么通过Security Hub的用户可以去看到它当前系统里所有的这些CVE这些漏洞的这些信息它的一个情况包括我们也highlight了一些这种Top 5,Dangerous的Top 5这个Most Dangerous的这种CVE那么除了这些静态的这些展示我们还提供了一种这种基于搜索的这种互操作性的一个展示我们可以通过这种不同的CVE属性比如说像CVE的ID、CVE的等级它的Bagist等等快速的去帮助用户去搜索当前系统里某些CVE是存在于哪些镜像上的那么第二部分就是这个关于OSI Distribution Spec 1.1.0 RC2的一个词那目前应该是RC3那一个支持那因为Hobber其实做一个原原生制柄成果我们肯定是实时的去跟Distribution Spec去做一个对齐做一个兼容的那么在这个RC2里面其实主要是引入了一些这种Artifact这种Linkage的这种关系因为传统的其实这个是一个眼镜的一个过程最早期可能我们只支持存储镜像那么再往后随着这个原原生的一个发展我们有了越来越多的一些制品除了容器镜像之外还有像Helm Chart、CNAP等等这些制品那么再往后眼睛那这些制品之间又可以通过一些属性来做一些关联让它们有一种这种Linkage的关系那么目前的Hobber是支持将Notation还有Nidus还有像Costine的这些制品去推送到Hobber上推送到Hobber上之后能够以一个这种accessory的也就是附属的这种制品的这种形式来attach到某一个subject的artifact上这样的话也能帮助用户更好的去查看它当前系统当前这个镜像下附属有哪些这种附属的制品那么下一个部分是关于在2.9我们做了一些功能上的一些增强首先是这个自定义的Message Banner因为大家在使用一些Hobber的时候可能经常对于运为团队来说它是需要定时的去运为或者是发布一些通知的但是之前可能缺少这样的渠道那么自定义的Message Banner可以让管理员去配置一些全局的这种消息然后配置之后这些消息就能够以这个会展示在最页面的最顶端那可以帮助用户更好的知道当前Hobber的一个情况那么第二部分是这个我们也第二部分是一个性能上的增强那么之前我们的一个GC比如说当你的Hobber实力很长时间没有进行过GC之后那么我们知道GC最后它的一个原理的话是需要去删除一个这些多余或者无用的这些artifact多余的无用的这些layer那这些layer如果说是存储在S3上的那么这些删除可能如果是有很多的镜像的一个情况的话你的这个耗时可能会非常的长所以我们是引入了多Walker的这么一个删除的一个机制通过多Walker的这个方式可以来加速你的一个GC过程那么在下面这个呢其实也是关于性能上的一个增强那么大家如果对于某一个项目下经常有这种大量并发的去铺持那么在这种高频高并发的一个情况下会导致数据库连接的一个占用以及HighCPU的一个占用那么所以我们在2.9呢是通过引入了一种新的机制也就是以Redis来作为这个更新cota的这么一种方式然后在一步刷新的方式刷新回这个数据库那么这样的话不仅仅是减少了一个数据库所以我们在2.9呢通过引入了一种新的机制那么这样的话不仅仅是减少了数据库的连接数同时也是减少了这些CPU资源的一个占用好然后接下来由王彥伟我们带来这个demo部分多谢陈宇我们就把刚刚陈宇讲过的1级2.9的增强我们做一个简单的demo在demo之前我们先铺持一个sub-jamb manifest然后我们这里选择的是redis的5.0然后我们铺持完之后我们在harbor上面会看到它是一个安sign的一个artifind所以我们说明可以看到它的status是没有sign过的然后下面我们就会用Cosign去sign这个redis5.0然后铺持完之后我们就可以看到signatureCosign的signature同时我们也会看到这个redis的status会变成signreferring to harbor对status然后我们展开是可以看到这里没有一个Cosign signature关联到了redis上面然后因为它是一个ocl subjamb所以我们也可以看到它一些details同时我们在2.9还支持了notation作为image signer去sign一个image所以用notation sign过了之后我们是可以看到redis上面是同时挂在了两个signature一个是cosign一个是notation的signature同时也可以看到它一些details这里我们多说一句就是说这个地方实际上就是我们在distribution spike 1.1的支持也就是说在1.1上面是可以定义多个artifind之间的关系然后这里面的好处是在于你可以去给一个subjamb manifest例如redis去签名去挂载你的sbob然后挂载你的cvesport等等因为这种关系不仅仅维护在单个harbor的节点上面就是在harbor-harbor之间也是可以去做replication的时候你可以把你的redisreplicate到另外一个harbor上面同时你的签名你的sbob也同时会被replicate到另外一个harbor意思上去就是另外一个harbor也会保持这种关联关系同时这个是可以任何一个签名都是可以被独立删除的下面我们就去来看一下secret hub的一个分享然后在演示之前我们先去扫描一下redis然后我们是在2.9之前我们是可以看到点击redis的detail是可以看到这些所有的cve的具体信息在某一个artifact下面但在2.9之上我们提供了一个secret hub的功能就是说实际上这是一个cve的centralized dashboard你可以看到整个系统有多少个cve以及有哪些需要关注的artifact也就是说这些artifact有一些有很多cve然后同时有哪些cve值得你关注因为这些是有high score的可能会影响你整个系统的安全性同时下面我们可以看到cve的一些搜索信息就像我刚才讲的你是可以通过cve的id系统管理员是可以通过一些定制的category to search你的cve去来查看整个系统的安全状态比如我们是可以直接观看查找Redis这个artifact对应的cve有哪些同时也可以通过cve的id去search那这个cve在这个系统里面到底影响了哪些artifact那这些信息是很方便对于系统管理员去看你整个系统的一个安全状态同时也可以支持一些cve的危害程度以及cve的分数比如说我们想要查系统里大于8.0的cve到底有哪些下面的话我们来看一下gc的增长在演示之前我们先把demo的Redis删除然后我们可以看一下我们会执行一个gc的job这里就是我们做的第一个增长就是在2.9之前gc都是单线场去执行那么我们听到社区的反馈是说因为很多企业的用户他们有非常非常多的cseb pipeline它会生成每天会生成很多用过就不用的镜像所以很大量然后他们的反馈是说他们虽然设置了delay的schedule但是在一天之内他们的量由于比较大它并不能完全删掉所以他们希望说可以做一个增长说能有parallel的deletion所以在这里我们可以做了一个增长用户是可以指定在执行gc的时候是可以指定的parallel是有数量上多少这里我们指定了两个worker所以去执行gc基于我们的一些测试我们内部的一些测试是我们测过10万个artifact和etb总量是etb的数据基于我们的测试结果是大概我们是可以有4倍的增强速度的提高这里另外一个小的增强就是在gc的执行记录上面我们会加了一些summary因为这个增强也是基于社区的一个反馈然后因为有的用户也是企业用户他们删除的量太大以致于造成这个log实际上是打不开的这个log因为行数太多可能是有几百兆所以它没有办法在UI上打开所以它很想知道这一次gc的一些summary是什么然后它给我们的feedback是说可不可以把一些summary信息放在history里面所以我们在这里就做了一个简单的增强另外就是在打开一个gclog我们可以看到因为引入了multiple deletion所以我们为每一个work assign了一个uid所以在log里面我们是可以看到有两个work同时在删除文件最后一点的增强就是customize the maintenance message这个增强也是来自于我们的一个企业用户因为他们在使用harbor to sell他们的用户的时候他们会说我们的harbor实际上它虽然搭了一个ha的harbor environment但是它还是有一个maintenance的一个downside的一个taps out他们希望是有一个时间去给他们做维护在这个时间它怎么能通知它的用户呢然后它给我们有一个feedback是说可不可以有一个这样的机制让我去定制一些customize的message然后这里我们是可以定制你的text然后以及你的warning的level是以及是不是可以clickable包括你的这个maintenance的时间窗口是什么多久比如说是一天或者是两天然后当你设置成功之后我们可以看到在最上面我们是可以看到一个message如果你希望是一个warning它就是一个黄色的然后clickable的话就是用户是可以看到并且可以把它关掉这是一个那这些是harbor在index就上面的一些增加然后后面我们会有一些后续的一些展望生育会继续介绍谢谢好谢谢王源的demo然后我们接下来的话我们继续看一下我们在未来的harbor版本中的一些功能上的一些展望那么首先是这个fullside distribution spec 1.1因为现在其实已经到了rc string的一个版本那么接之后我们也会去及时的去和spec做一个对齐做一个兼容那么这个spec其实主要概括来说的话聚焦于三个方面第一个方面是它引入了一种新的这个自断叫artifact type那这个artifact type的话其实就是用于来定义用户自己的这种的质评属性那如果是对于一个镜像的话因为我们之前可能接触的比较多了就是镜像那么其实随着永远上的一个发展用户可能有各种各样的这种制品类型比如说包括像这种目前比较火热的AI的一些模型最终也可以打包成这个oci的镜像那这个时候它就可以去定义自己的这种制品类型那么有了这个自定义的制品类型呢也是能够更加方便用户去作为后期的一个这种管理和维护那么第二部分呢就是引入了这个subject的这么一个属性那么这个属性是挂在在MiniFist上面的通过这个subject属性你可以将两个制品两个本来没有关系的制品关联到一起那么构建出这样的一个关联关系之后呢我们就能够去在用户在客户端层面去查探到我当前这个系统上不同制品之间的这么一个这种连接关系包括像刚刚代贸里我们看到的我们在一个镜像上attach了这个cosign的signature和notation的签名那么第三部分呢就是这个referred API因为这个其实是对于第二种方式的一个衍生因为第二种方式我们引入了这个subject的属性那么第三种其实是引入了这样一个新的一个这样一个API来帮助用户去查询它的一个这样的一个连接关系就是说我可以查看我当前这个制品上挂载了哪些附属的这些制品比如说我当前的某个镜像上我挂载了那些签名我挂载了那些的文件那么同时呢目前在spec的定义中呢你也是去可选的去支持这种artifact type也就是说能够去支持根据artifact type的这种类型来查找你一个artifact下挂载的这些artifact的这种类型比如说你当前的artifact下面挂载了10个附属的artifact但是你只想查询某一种类型比如说我只想查询cosign的签名这个时候可能就可以通过artifact type这种类型来做一个查询那么第二部分呢就是关于这个软件供应链安全这块的一个展望吧因为大家都知道现在其实对于圆圆圳的安全也是越来越重视那么对于这个因为现在在安全界的话经常也提倡的一个理念就是说安全左移也就是说我们将一些安全的这些策略提前发现问题在更早期的阶段去发现这些安全问题那么所以我们也是考虑在未来百分之中支持这个sbom那sbom的全称叫software be of materials那其实它就是一个软件物料清单那这个就有点类似我们去购买一个食品的时候我们可以去看到食品的包装袋上袋上会写这个这个食品它的一个组成的一个成分那么sbom其实就是对应到软件里的这个这个成分你的这个软件里你用到了哪些的这种第三方的组件你的这些组件的版本是什么你的组件的你的组件的这些license是什么那么所以呢哈巴也是基于考虑从四个方面来实现这么一个sbom的功能首先是去支持我们通过OCI的能够自动的去生成这些artifact的sbom那么我们也会考虑采用这种placol scanner的这种spect方式来方便各种各样这种sbom生成工具的一个集成那么通过实现这个spect呢这个不同的哈巴可以去集成不同的这种sbom的这种工具来生成sbom那么第二部分生成sbom之后呢其实有一个比较重要有用的功能就是我们传统的去扫描一个镜像那一般这些scanner的一个流程是首先会把这个镜像铺下来然后呢铺下来那铺这个镜像其实首先要铺minifist之后要把这些镜像的layer全都铺下来因为它要去每一层的文件去做这样一个分析最终才能扫出这个cve那有些镜像很大可能是上百Gb的这样一个规模那这个时候去扫描这些镜像是一个非常耗时的过程那主要的这个耗时点呢可能就都存在于这个铺的这个过程中你的这个网络传输你的这个带宽限制等等那么但是有了sbom之后呢我们其实就不一样了因为当有了sbom之后这个sbom上其实就由你这个镜像上所有的这种制品的这些组件的这些信息那么有了这些信息之后呢其实我们只要把这个sbom去铺下来之后去对它做一个扫描就能更快速的去知道去了解这个制品上目前当前有哪些漏洞那么同时呢这个我们也会考虑支持这种可实化的一个这个管理和展示因为sbom本身它可能是一些这种这些这种各种依赖的这种信息但是不太利于用户去查看但是我们可以提供一些这种一些展示页面去帮助用户更好的去展示去查看它当前artifact下的一些sbom的一些信息那么最后一部分就是我们刚刚其实上面也介绍到了在2.9里我们引入了security hub这个功能那么它主要是为了提供这种全局的安全视角那我们的之所以这个功能叫security hub其实我们讲做的不仅仅是对于某些cve来提供这种全局的视角而是所有和安全相关的这种能力这种展示我们都会考虑集成到这个security hub中来那么最终通过这个security security的这个hub就可以去更好地去管控你整个hub的安全的一个状况那么下面是这个如果大家有兴趣去加入这个hub的一些问题的讨论或者是开发的话可以通过这个slack channel以及邮件组以及这个双周立会大家通过这种双周立会可以去和我们做这种再先会面对面的一些交流去分享自己在hub中的一些最佳时间或者是遇到的一些问题或者是一些需求等等好那么最后谢谢大家然后另外一个就是我们也有中国用户的这个社群如果大家有问题都可以在群里去进行一个分享进行一个讨论好谢谢大家