沿袭我们的月度发布传统,极狐GitLab 发布了 17.5 版本,该版本带来了多仓库 MR 合并时考虑统一主流水线的执行状态(JH-only)、增强的分支规则编辑功能、密钥推送保护已经正式可用等几十个重点功能的改进。下面是部分重点功能的详细解读。
极狐GitLab 正式推出针对GitLab CE 老旧版本免费用户的 GitLab 专业升级服务,可以为老旧版本进行专业升级,避免业务宕机。
关于极狐GitLab 的安装升级,可以查看官方指导文档。
registry.gitlab.cn/omnibus/gitlab-jh:17.5.0-jh.0
helm search repo gitlab-jh
NAME CHART VERSION APP VERSION
gitlab-jh/gitlab 8.5.0 v17.5.0
gitlab-jh/gitlab-runner 0.70.0 17.5.0
|
|
|
|
|
|
|
|
|
|
|
|
对于多个仓库的 MR,当它们的项目中勾选了 “流水线必须成功” 才能合并 MR 的选项时,如果它们所在的项目中没有各自的流水线,那这些 MR 能否合并取决于统一的主流水线是否执行通过了。
|
|
|
|
|
|
|
|
|
|
|
|
在极狐GitLab 15.10 中,我们引入了与分支设置和规则相关的整合视图功能。这个视图为你提供了一种简单的方式,以理解你的项目在多个设置中的配置。
在此功能之上,你可以在视图上直接对特定的分支规则进行修改,包括分支保护策略、批准规则以及外部状态检查等配置。这些新功能为分支配置的持续改进奠定了基础,将来将允许更大的灵活性。
|
|
|
|
|
|
|
|
|
|
|
|
我们很高兴地宣布密钥推送保护功能已经对所有旗舰版客户来说正式可用啦!
如果不小心将密钥提交到了 Git 仓库,比如 key 或者 API 令牌,那么任何对仓库有访问权限的人都有可能获取这些密钥信息,然后伪装成密钥所对应的用户,做一些恶意操作。密钥泄露耗时费钱,而且会对公司声誉造成潜在伤害。而密钥推送保护功能通过在推送发生的第一时间对密钥信息进行保护,从而减少密钥泄露的修复时间,降低带来的风险。
自从 Beta 版本后,我们对密钥推送保护功能又做了改进。当使用 Git 命令对代码进行提交时,不仅只有变更(差异)会被用来做密钥扫描。我们还增加了对排除路径、规则或特定值的实验性支持,以避免误报。
|
|
|
|
|
|
|
|
|
|
|
|
现在,JihuLab.com 上的凭据清单对顶级群组的拥有者已经可用了。你可以跨群组查看你的企业用户个人访问令牌和 SSH Key 了。你还可以撤销、删除以及查看与凭据相关的其他额外信息。之前,此功能只有极狐GitLab 私有化部署的管理员能用。
群组拥有者可以使用凭据清单来了解拥有者范围内所具有的凭据,这提高了可视化和可控性。
|
|
|
|
|
|
|
|
|
|
|
|
现在,在极狐GitLab 中,你可以通过对特定组件的过滤来确定群组或项目中是否使用了该组件。在整个列表中用手动查找的方式来确认某个特定的软件包或软件版本是否在使用是非常耗时的。有了这个在依赖列表中对组件进行过滤的功能,就可以对易受攻击的依赖项进行隔离,而且能更加方便地对应用程序所面临的风险进行评估。
|
|
|
|
|
|
|
|
|
|
|
|
我们很高兴地宣布,针对极狐GitLab 私有化部署,我们对容器镜像仓库 API 做了一个非常重要的改进。在极狐GitLab 17.5 中,我们实现了对 :id/registry/repositories/:repository_id/tags
端点的键集分页功能(keyset pagination ),使其与 JihuLab.com 上已有的功能保持一致。这项改进是我们持续努力提升 API 性能的一部分,而且为所有极狐GitLab 的部署提供了一致性体验。
键集分页功能为处理大型数据集提供了更加灵活的方式,也带来了更好的性能以及更好的用户体验。这个功能在管理大型容器镜像仓库时特别有用,因为它能在仓库中对标签进行浏览时显得更丝滑。为了使用此功能,私有化部署实例必须要升级到下一代容器镜像仓库。
|
|
|
|
|
|
|
|
|
|
|
|
你可以在极狐GitLab 界面上对 pod 状态、Flux 调谐进行查看。然而,这种方法难以扩展,因为所需的设置只能通过 GraphQL 或者 UI 进行对外暴露。现在,极狐GitLab 支持通过 REST API 来对 Kubernetes agent 以及每个环境中的命名空间设置、Fulx 资源进行配置了。
|
|
|
|
|
|
|
|
|
|
|
|
直到现在,Kubernetes agent 也只能被用在和极狐GitLab 实例能够连接的 Kubernetes 集群上。这个问题就导致有些用户没法用 Kubernetes agent,因为他们的实例安装在了私有网络或者防火墙背后。从极狐GitLab 17.5 开始,你可以从极狐GitLab 发起集群-极狐GitLab 连接,假设已经有一个已经正确配置的 agentk
实例在等待连接初始化。
一旦建立了初始化连接,就可以使用 agent 的所有功能了。此次更改并未对集群初始化的方式做任何改变。
|
|
|
|
|
|
|
|
|
|
|
|
作为 Flux 用户,你是否曾经需要快速停止一次自动同步或漂移修正?你是否想要触发一个 HelmRelease 来同步手动移除的资源?这些动作非常适合用 Flux 暂停或恢复功能来实现。直到现在,最好的方式可能是使用 Flux 命令行,但是这需要切换上下文,而且需要记住相应的指令以确保操作的资源是正确的。在极狐GitLab 17.5 中,你可以在 Kubernetes 内置的仪表盘中对同步进行暂停或者恢复。
|
|
|
|
|
|
|
|
|
|
|
|
之前,合规中心只在群组或子群组上可用。
在此版本中,我们为项目添加了合规中心。在这个层级上,合规中心为与特定项目相关的检查和违规行为提供仅查看的功能。
如果要添加或者编辑框架,你需要在顶级群组上对合规中心进行操作。
|
|
|
|
|
|
|
|
|
|
|
|
企业用户可以用本地账号的用户名密码进行认证。现在,群组拥有者可以为群组内的企业用户禁用密码认证了。如果密码认证被禁用,企业用户可以使用群组的 SAML 身份提供者通过 GitLab 网页用户界面进行认证,或者使用个人访问令牌通过极狐GitLab API 和 Git 使用 HTTP 基本认证进行认证。
|
|
|
|
|
|
|
|
|
|
|
|
在极狐GitLab 17.3中,我们宣布了对于合规流水线的弃用,并且将在18.0中彻底移除。取而代之的是流水线执行策略的使用,这是我们在极狐GitLab 17.2 中发布的。
为了帮你将既有的合规流水线迁移至流水线策略类型,此版本包含了一个告警横幅:
通知用户关于合规流水线弃用的事情。
提供了一个提示和引导的工作流来将既有的合规流水线迁移至流水线执行策略类型。
|
|
|
|
|
|
|
|
|
|
|
|
现在你可以查看某个令牌关联了哪些群组、子群组以及项目。这样可以更容易地确定令牌过期或吊销的影响,并理解令牌可以在何处使用。
|
|
|
|
|
|
|
|
|
|
|
|
极狐GitLab 17.5 包含了一个与 NGINX Ingress Controller 版本相关的更新。nginx-controller
容器镜像的版本现在是 1.11.2
。请注意,此项更新需要新的 RBAC 需求,因为新的控制器在使用 endpointslices,而这需要一个 RBAC 规则来对它们进行访问。
|
|
|
|
|
|
|
|
|
|
|
|
极狐GitLab 17.5 包含了对单节点实例的 PostgreSQL 从 14.x 升级到 16.x 的变更。自动升级并未开启,因此需要手动触发才行。
|
|
|
|
|
|
|
|
|
|
|
|
我们还发布了极狐GitLab Runner 17.5。极狐GitLab Runner 是一个轻量级、高扩展的代理,用来运行你的 CI/CD 作业并且将结果发送回极狐GitLab 实例。极狐GitLab Runner 和极狐GitLab CI/CD 绑定在一起,而极狐GitLab CI/CD 是一个开源且内置在极狐GitLab 里面的服务。
新特性:
修复的缺陷:
gitlab-runner-fips-17.4.0-1
包在 Amazon Linux 2 上面运行失败并返回 glibc 错误DOCKER_AUTH_CONFIG
变量有多个仓库时,作业无法拉取基础镜像
|
|
|
|
|
|
|
|
|
|
|
|
我们很高兴地宣布此版本新增了对受保护 npm 包的支持,这个新设计的功能目的是为了加强极狐GitLab 软件包仓库的安全性和稳定性。在软件研发的快节奏世界中,如果不小心修改或者删除了某个包,就能打断整个研发流程。受保护包通过将最重要的依赖进行安全保护来防止意外变更来很好的解决这个问题。
从极狐GitLab 17.5 开始,你可以通过创建保护规则来保护 npm 包。如果某个包与保护规则相匹配,那么只有特定的用户可以对其进行更新或者删除。有了这个功能,你就可以阻止意外变更、提高合规性以及通过减少人为监督来简化工作流。
|
|
|
|
|
|
|
|
|
|
|
|
极狐GitLab 通过 Kubernetes agent 和 Flux 集成提供了灵活、可靠以及安全的 GitOps 支持。然而,在极狐GitLab 启动 Flux 以及设置 Kubernetes agent 涉及大量的文档阅读,而且需要在极狐GitLab 界面和命令行终端之间进行切换。现在,极狐GitLab 命令行提供了 glab cluster agent for bootstap
命令来简化在既有 Flux 的安装之上对 agent 进行安装。所以,现在仅需两个简单的命令就能完成 agent 和 Flux 的配置。
|
|
|
|
|
|
|
|
|
|
|
|
极狐GitLab 在 Kubernetes 仪表盘上为 pod 以及 pod 日志流提供了一个实时视角。在极狐GitLab 17.4中,我们从用户界面提供了一个静态的资源特定事件信息列表。这个版本进一步改进了 Kubernetes 仪表板,让能够实时流式传输集群中出现的事件。
|
|
|
|
|
|
|
|
|
|
|
|
我们已经在高级 SAST 中增加了对 Ruby 的支持。如果要使用这个跨文件、跨函数的扫描支持,需要你开启高级 SAST。如果你已经开启了高级 SAST,Ruby 支持就会被自动激活。
在上个月,我们还发布了一些更新来改善高级 SAST 所支持的其他语言的检测规则:
如果想要查看针对每种语言,高级 SAST 检测到了哪些漏洞,可以查看新的高级 SAST 覆盖率页面。
|
|
|
|
|
|
|
|
|
|
|
|
现在你可以在安全策略范围内针对群组/子群组进行定位。这扩展了现有的选项,允许你对群组/子群组中的所有项目、基于定义的项目列表中的项目,以及对符合合规框架标签列表的项目进行定位。
这为你在跨群组开启策略时提供了更多的灵活性,同时在必要时也能够对某些项目应用例外,将它们排除在强制执行范围之外。
|
|
|
|
|
|
|
|
|
|
|
|
管理员现在有一个增强的摘要视图,可以查看有关其实例上用户的以下关键信息:
这提高了用户管理效率,因为管理员可以快速从摘要视图中看到有多少用户处于这些状态,并对其进行过滤。
|
|
|
|
|
|
|
|
|
|
|
|
之前,当开启 SAML SSO 后,群组可以选择强制执行 SSO,这就要求所有的成员都得用 SSO 认证来访问该群组。然而,有些群组希望对员工或群组成员强制执行 SSO,但是对于外部贡献者或者外包员工可以在没有 SSO 的情况下依旧能访问该群组。
现在,启用了 SAML SSO 的群组会自动对所有拥有 SAML 身份的成员强制执行 SSO。没有 SAML 身份的群组成员不会被要求使用 SSO,除非明确启用了 SSO 强制执行。
如果以下某个条件为真或全部条件为真,一个成员就会拥有 SAML 身份:
他们使用他们的极狐GitLab 群组单点登录 URL 登录极狐GitLab。
他们是由 SCIM 管理的。
为了能平滑使用此功能,在选择为此群组开启 SAML 认证选项前确保你的 SAML 配置能够正确工作。