十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

cosign initialize 命令详解:初始化 Sigstore TUF 可信根,为签名验证铺路

cosign initialize 命令详解:初始化 Sigstore TUF 可信根,为签名验证铺路 cosign initialize 命令详解初始化 Sigstore TUF 可信根为签名验证铺路【免费下载链接】cosignCode signing and transparency for containers and binaries项目地址: https://gitcode.com/GitHub_Trending/co/cosigncosign initialize是 cosign 中负责初始化 Sigstore 可信根Trusted Root的命令它通过 TUFThe Update Framework机制拉取并缓存用于验证的受信任证书与密钥目标trusted certificate and key targets例如用于校验 Fulcio 所签发证书的 Fulcio 根 CA。读完本文你将掌握该命令的默认行为、全部命令行参数、离线路网air-gap与 staging 环境下的初始化方式以及它在源码层面的实际执行链路。命令概览与核心作用cosign initialize的定位是初始化 SigStore root以获取验证所需的受信任证书与密钥目标。在 cosign 的验证体系中cosign verify、cosign verify-attestation等命令需要可信的根数据来验证签名链路如 Fulcio 证书、Rekor 日志、TSA 时间戳证书而这些根数据正是通过本命令从 TUF 仓库拉取并缓存的。命令入口定义在 cmd/cosign/cli/initialize.go其RunE逻辑会根据是否传入--staging分派到不同的实现函数传入--staging调用initialize.DoInitializeStaging(cmd.Context())否则调用initialize.DoInitializeWithRootChecksum(cmd.Context(), o.Root, o.Mirror, o.RootChecksum)。底层实现位于 cmd/cosign/cli/initialize/init.go核心函数doInitialize完整串起了加载初始根 → 配置 TUF 客户端 → 缓存远端信息 → 获取签名配置与可信根的整条链路。默认行为根据命令的长帮助文本Long字段与官方文档 doc/cosign_initialize.md默认情况下启用以下两个选项当前受信任的 Sigstore TUF 根已内嵌在 cosign 发布版本中——即发布时打包进二进制文件无需额外下载即可作为初始信任锚点Sigstore 远程 TUF 仓库从 CDN 镜像拉取默认地址为https://tuf-repo-cdn.sigstore.dev。任何更新后的 TUF 仓库内容都会被写入$HOME/.sigstore/root/目录。cosign 验证过程中使用的受信任密钥与证书例如用 Fulcio 根 CA 校验 Fulcio 签发的证书均从这份可信元数据trusted metadata中获取。命令语法与参数详解基本语法cosign initialize [flags]专属参数在 cmd/cosign/cli/options/initialize.go 中InitializeOptions定义了四个专属参数含义与默认值如下参数类型默认值说明--mirrorstringhttps://tuf-repo-cdn.sigstore.devSigStore TUF 仓库的 GCS bucket、HTTP(S) 基础 URL或file:///本地文件存储远端用于离线/隔离网络环境--rootstring空使用内嵌根受信任初始 root 的路径默认为 cosign 内嵌的 root--root-checksumstring空初始 root 的校验和若 root 通过 http(s) 下载则为必填。默认按 sha256 校验可通过sha512:checksum前缀改用 sha512--stagingboolfalse使用 staging TUF 仓库参数说明要点--root支持文件路径或 URL 引用两种形式用于提供带外out-of-band受信任的初始root.json从而将 cosign 指向一个独立的 TUF 根--root-checksum的校验和算法切换逻辑在 pkg/blob/load.go 的LoadFileOrURLWithChecksum中实现默认使用 sha256只有sha512:前缀才会切换为 sha512其他算法前缀会直接报unsupported checksum algorithm错误同时该校验和比较基于解码后的字节而非十六进制字符串因此大小写不敏感。从父命令继承的参数--output-file string log output to a file -t, --timeout duration timeout for commands (default 3m0s) -d, --verbose log debug output--output-file将日志输出到指定文件-t, --timeout命令超时时间默认3m0s-d, --verbose输出调试日志。官方示例五种典型用法以下示例全部来自命令的Example字段与 doc/cosign_initialize.md 一致覆盖了从默认初始化到带校验和的高级用法# 指定自定义镜像源 cosign initialize --mirror url # 使用分布式根密钥基于默认镜像初始化 cosign initialize # 使用分布式根密钥基于 staging 镜像初始化 cosign initialize --staging # 使用带外根密钥文件基于默认镜像初始化 cosign initialize --root url # 使用带外根密钥文件 自定义仓库镜像 cosign initialize --mirror url --root url # 使用带外根密钥文件 自定义仓库镜像并校验根校验和 cosign initialize --mirror url --root url --root-checksum sha256各用法适用场景解读裸执行cosign initialize最简路径适合绝大多数标准环境直接使用内嵌根 官方 CDN 镜像--staging面向 Sigstore 开发/测试指向 staging TUF 仓库便于在非生产环境验证新元数据--root企业或自建 Sigstore 场景下通过带外分发的根文件建立信任锚点--mirror --root组合完全自定义的 TUF 仓库 自定义根适用于私有部署再加上--root-checksum为通过 HTTP(S) 下载的初始根提供完整性校验防止中间人篡改信任锚点。源码执行链路initialize 内部发生了什么核心实现函数doInitialize位于 cmd/cosign/cli/initialize/init.go的执行流程可以拆解为六步1. 加载初始根内容if root ! { if !forceSkipChecksumValidation { if rootChecksum (strings.HasPrefix(root, http://) || strings.HasPrefix(root, https://)) { fmt.Fprintln(os.Stderr, options.RootWithoutChecksumDeprecation) } } verifyChecksum : !forceSkipChecksumValidation (rootChecksum ! ) if verifyChecksum { rootFileBytes, err blob.LoadFileOrURLWithChecksum(root, rootChecksum) } else { rootFileBytes, err blob.LoadFileOrURL(root) } ... }关键细节若--root指向 HTTP(S) URL 且未提供--root-checksum会打印一条弃用警告RootWithoutChecksumDeprecation定义于 cmd/cosign/cli/options/deprecate.go从 URL 获取初始根而不提供其校验和的做法已弃用未来版本将禁止请通过--root-checksum提供校验和blob.LoadFileOrURLpkg/blob/load.go支持http://、https://、env://三种 scheme 以及本地文件路径其中env://VAR从环境变量读取内容本地路径则直接os.ReadFile。2. 组装 TUF 客户端选项opts : tuf.DefaultOptions() if root ! { opts.Root rootFileBytes } if mirror ! { opts.RepositoryBaseURL mirror if mirror tuf.StagingMirror { opts.Root tuf.StagingRoot() } } if tufCacheDir : env.Getenv(env.VariableTUFRootDir); tufCacheDir ! { opts.CachePath tufCacheDir }未指定--root时使用 sigstore 库内置的默认根即内嵌在 cosign 发布版本中的根--staging会把镜像切换为 staging 镜像并同时换上 staging 根缓存目录可通过环境变量TUF_ROOT覆盖见下文环境变量一节。3. 记录远端镜像信息remote : map[string]string{mirror: opts.RepositoryBaseURL} remoteBytes, _ : json.Marshal(remote) os.RemoveAll(opts.CachePath) os.MkdirAll(opts.CachePath, 0o700) os.WriteFile(filepath.Join(opts.CachePath, remote.json), remoteBytes, 0o600)initialize 会清空并重建缓存目录并把当前使用的镜像 URL 写入remote.json供后续签名/验证命令参考当前远端来源。测试TestDoInitializecmd/cosign/cli/initialize/init_test.go中也会断言缓存目录下存在remote.json。4. 获取签名配置 signing_config.json_, err tufroot.FetchSigningConfigWithOptions(opts) if err ! nil { ui.Warnf(ctx, Could not fetch signing_config.json from the TUF mirror ...) }签名配置signing config用于签名时确定服务 URL若镜像暂未提供该文件仅打印警告并继续不会中断初始化。5. 获取可信根 trusted_root.jsonv2 路径trustedRoot, err : tufroot.NewLiveTrustedRoot(opts) if err ! nil { ui.Warnf(ctx, Could not fetch trusted_root.json from the TUF mirror ..., falling back to individual targets. ...) } if trustedRoot ! nil { return nil }这是当前推荐的主路径从 TUF 仓库拉取trusted_root.json成功即完成初始化并直接返回。若镜像没有trusted_root.json则打印提示并回退到旧版路径。6. 回退到传统 TUF targetsv1 路径if err : tufv1.Initialize(ctx, mirror, rootFileBytes); err ! nil { return err } status, err : tufv1.GetRootStatus(ctx) ... fmt.Println(Root status: \n, string(b))对于尚未提供trusted_root.json的旧版镜像initialize 会初始化传统的 TUF targets如ctfe.pub、rekor.pub等独立公钥目标最后输出格式化后的 Root status 供用户检查。测试用例佐证cmd/cosign/cli/initialize/init_test.go 用httptest起了一个本地 TUF 服务器覆盖三种场景TUF v2镜像提供trusted_root.json与signing_config.v0.2.json时成功走 v2 路径无额外输出TUF v1镜像仅提供ctfe.pub时回退到 v1 路径stdout 输出ctfe.pub等目标stderr 提示trusted_root.json缺失并建议升级元数据仓库无效 root传入了不存在的 root 文件时返回错误且不会回退使用内嵌根invalid root - should not try to use embedded。这组测试恰好印证了文档所说的受信任密钥与证书从可信元数据中拉取以及镜像缺省时回退到独立 targets的完整行为。相关环境变量cosign initialize的行为还会受到以下 Sigstore 环境变量的影响定义于 pkg/cosign/env/env.go环境变量说明TUF_ROOTTUF 缓存目录路径覆盖默认的$HOME/.sigstore/root/init.go 中通过env.Getenv(env.VariableTUFRootDir)读取并传入opts.CachePathTUF_MIRRORTUF 镜像 URL配合TUF_ROOT_JSON可在签名/验证命令执行期间刷新 TUF 元数据设置后 cosign 会优先尝试使用trusted_root.json并忽略自定义 TUF 元数据TUF_ROOT_JSON用于初始化并更新本地 TUF 仓库的root.json文件路径需与TUF_MIRROR配合使用测试代码正是通过t.Setenv(TUF_ROOT, tufCache)把缓存指到临时目录从而验证缓存文件落盘位置。验证初始化结果初始化成功后可以检查缓存目录确认结果ls -R $HOME/.sigstore/root/目录下应包含remote.json记录镜像 URL以及从 TUF 仓库拉取的trusted_root.json、signing_config.v0.2.json等目标文件。若镜像为旧版仅提供独立 targets则会在初始化结束时直接打印Root statusJSON 供查看各角色根的状态。需要注意的是--root参数带有MarkFlagDirname标记见 cmd/cosign/cli/options/initialize.go提示该参数期望指向文件/目录路径而--mirror的默认值由tuf.DefaultRemoteRoot常量提供即文档所述的https://tuf-repo-cdn.sigstore.dev。小结cosign initialize是 cosign 信任链的播种命令它以内嵌或带外的初始根为锚点从指定 TUF 镜像拉取受信任元数据并缓存到本地默认$HOME/.sigstore/root/为后续cosign verify、cosign verify-attestation等验证操作提供 Fulcio 根 CA、Rekor 公钥、TSA 证书等信任依据。通过--mirror、--root、--root-checksum、--staging四个参数的组合它可以覆盖标准公网环境、私有镜像、完全离线air-gapfile:///以及 staging 测试等多种部署形态而TUF_ROOT、TUF_MIRROR、TUF_ROOT_JSON环境变量则提供了 CI/CD 场景下的配置灵活性。【免费下载链接】cosignCode signing and transparency for containers and binaries项目地址: https://gitcode.com/GitHub_Trending/co/cosign创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表