容器运行时云原生网络【免费下载链接】rkt[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.项目地址https://gitcode.com/gh_mirrors/rk/rkt点击查看免费下载本指南以 rkt 官方文档 Documentation/signing-and-verification-guide.md 为主体围绕 ACIApp Container Image的签名、分发与校验全流程展开手把手生成 GPG 密钥对并给 ACI 打上分离签名、通过 Meta Discovery 发布镜像与公钥、使用rkt trust建立信任以及验证rkt run/rkt fetch的完整校验链路。阅读完你将能独立为自有 ACI 建立签名—分发—信任—验证的安全闭环并理解 rkt keystore 的底层布局与--insecure-options的安全取舍。rkt 的默认安全模型要求所有 ACI 使用 GPG 分离签名进行签名。本文以入门指南 Documentation/getting-started-guide.md 中创建的helloACI 为例逐层展开。hello-0.0.1-linux-amd64.aci文章结构签名 ACI → 通过 Meta Discovery 分发镜像 → 用 rkt 校验镜像 → 建立信任 → 完整示例。签名 ACISigning ACIs默认情况下rkt 要求 ACI 使用 gpg 分离签名detached signature进行签名。下面是创建可用于 ACI 签名的 gpg 密钥对的完整流程。如果你已有现成的 gpg 签名密钥可以直接跳到签名 ACI一节。生成 gpg 签名密钥创建名为gpg-batch的文件写入如下内容%echo Generating a default key Key-Type: RSA Key-Length: 2048 Subkey-Type: RSA Subkey-Length: 2048 Name-Real: Carly Container Name-Comment: ACI signing key Name-Email: carlyexample.com Expire-Date: 0 Passphrase: rkt %pubring rkt.pub %secring rkt.sec %commit %echo done关键参数说明Key-Type/Key-Length主密钥类型与位数这里使用 RSA 2048 位Subkey-Type/Subkey-Length子密钥类型与位数用于加密usage: E与签名主密钥usage: SC分离符合 OpenPGP 最佳实践Expire-Date: 0密钥永不过期Passphrase: rkt仅为示例使用的简单口令生产环境应使用强口令%pubring/%secring指定公钥环与私钥环的输出文件名使整个演示自包含不影响系统默认钥匙环。使用批处理模式生成密钥$ gpg --batch --gen-key gpg-batch列出密钥$ gpg --no-default-keyring \ --secret-keyring ./rkt.sec --keyring ./rkt.pub --list-keys ./rkt.pub ------------ pub 2048R/26EF7A14 2015-01-09 uid [ unknown] Carly Container (ACI signing key) carlyexample.com sub 2048R/B9C074CD 2015-01-09从输出可以看到该签名密钥的信任级别trust为unknown。如果用 gpg CLI 校验用它签名的 ACI会出现如下警告gpg: WARNING: This key is not certified with a trusted signature!因为我们明确知道这个密钥的来源所以可以把它标记为终极信任$ gpg --no-default-keyring \ --secret-keyring ./rkt.sec \ --keyring ./rkt.pub \ --edit-key 26EF7A14 \ trust gpg (GnuPG/MacGPG2) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 2048R/26EF7A14 created: 2015-01-09 expires: never usage: SC trust: unknown validity: unknown sub 2048R/B9C074CD created: 2015-01-09 expires: never usage: E [ unknown] (1). Carly Container (ACI signing key) carlyexample.com Please decide how far you trust this user to correctly verify other users keys (by looking at passports, checking fingerprints from different sources, etc.) 1 I dont know or wont say 2 I do NOT trust 3 I trust marginally 4 I trust fully 5 I trust ultimately m back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y pub 2048R/26EF7A14 created: 2015-01-09 expires: never usage: SC trust: ultimate validity: unknown sub 2048R/B9C074CD created: 2015-01-09 expires: never usage: E [ unknown] (1). Carly Container (ACI signing key) carlyexample.com Please note that the shown key validity is not necessarily correct unless you restart the program. gpg quit导出公钥签名/校验体系对外只需要公钥。用--armor导出为 ASCII 格式便于通过 Web 分发$ gpg --no-default-keyring --armor \ --secret-keyring ./rkt.sec --keyring ./rkt.pub \ --export carlyexample.com pubkeys.gpg签名 ACI对hello-0.0.1-linux-amd64.aci生成分离签名文件ASCII 装甲格式$ gpg --no-default-keyring --armor \ --secret-keyring ./rkt.sec --keyring ./rkt.pub \ --output hello-0.0.1-linux-amd64.aci.asc \ --detach-sig hello-0.0.1-linux-amd64.aci注意--detach-sig生成的是与 ACI 文件分离的.asc签名文件这正是 rkt 期望的形态签名不内嵌于镜像可独立分发与独立校验。使用 gpg 校验镜像在发布之前先用 gpg 自检签名是否有效$ gpg --no-default-keyring \ --secret-keyring ./rkt.sec --keyring ./rkt.pub \ --verify hello-0.0.1-linux-amd64.aci.asc hello-0.0.1-linux-amd64.aci gpg: Signature made Fri Jan 9 05:01:49 2015 PST using RSA key ID 26EF7A14 gpg: Good signature from Carly Container (ACI signing key) carlyexample.com [ultimate]此时你应该拥有以下三个文件hello-0.0.1-linux-amd64.aci.asc hello-0.0.1-linux-amd64.aci pubkeys.gpg三者分别对应签名文件、ACI 镜像、公钥文件下一步将把后两者发布到 Web。通过 Meta Discovery 分发镜像在域名example.com/hello下托管如下 HTML携带两个 ACI 发现 meta 标签!DOCTYPE html html langen head meta charsetutf-8 meta nameac-discovery contentexample.com/hello https://example.com/images/{name}-{version}-{os}-{arch}.{ext} meta nameac-discovery-pubkeys contentexample.com/hello https://example.com/pubkeys.gpg /head /html按 meta 标签描述的地址提供以下文件https://example.com/images/example.com/hello-0.0.1-linux-amd64.aci.asc https://example.com/images/example.com/hello-0.0.1-linux-amd64.aci https://example.com/pubkeys.gpg两个 meta 标签的作用分别为ac-discovery告诉 rkt 如何根据镜像名拼装 ACI 与签名文件的下载地址模板ac-discovery-pubkeys告诉 rkt 到哪里获取该镜像名前缀对应的公钥供rkt trust在未显式给出公钥地址时自动发现。rkt 集成以下命令$ rkt run example.com/hello:0.0.1会使 rkt 依次检索以下 URIhttps://example.com/hello?ac-discovery1 https://example.com/images/example.com/hello-0.0.1-linux-amd64.aci https://example.com/images/example.com/hello-0.0.1-linux-amd64.aci.asc第一个响应携带ac-discovery1探测参数中包含下载 ACI 与分离签名文件的模板 URLmeta nameac-discovery contentexample.com/hello https://example.com/images/{name}-{version}-{os}-{arch}.{ext}模板占位符的填充规则{name}镜像名示例中为example.com/hello{os}与{arch}由 rkt 基于当前运行系统自动填充Linux、amd64 等{version}取自命令行给出的 tag如:0.0.1未提供 tag 时回退为latest{ext}根据所取工件替换为.aciACI 镜像或.aci.asc分离签名。从源码角度看这一发现逻辑由 rkt/image/namefetcher.go 中的nameFetcher.discoverApp实现它调用 App Container 规范的discovery.DiscoverACIEndpoints获取 ACI 端点含 ACI 与 ASC 两个 URL随后在fetchImageFromEndpoints中分别下载签名与镜像{os}/{arch}的默认值填充逻辑见 rkt/image/fetcher.go 中的setAppDefaults引用common.GetArch()与common.GetOS()。ACI 下载完成后rkt 会从镜像元数据manifest中提取镜像名用于在 rkt keystore 中定位已信任的公钥并执行签名校验——即 rkt/image/validator.go 中ValidateWithSignature的流程它以 manifest 中的镜像名为 prefix 调用 keystore 的CheckSignature确保签名者确实属于该前缀的已信任公钥。若签名者未知代码会提示用户尝试rkt trust --prefix image。用 rkt 校验镜像Verifying Images with rkt建立信任Establishing Trust默认情况下rkt 不信任任何签名密钥。信任通过将公钥存入 rkt keystore 来建立可以使用rkt trust也可以按下一节描述手动完成。默认的 rkt keystore 布局由以下目录构成/etc/rkt/trustedkeys/root.d /etc/rkt/trustedkeys/prefix.d /usr/lib/rkt/trustedkeys/root.d /usr/lib/rkt/trustedkeys/prefix.d/etc/rkt系统管理员存放信任密钥的位置/usr/lib/rkt由操作系统发行版预置的信任密钥管理员不应直接修改。信任的密钥以公钥指纹为文件名保存在相应目录中。管理员可以通过在/etc/rkt下写入一个空文件来禁用某个发行版预置的信任密钥。例如若你的发行版带有如下信任密钥/usr/lib/rkt/trustedkeys/prefix.d/coreos.com/a175e31de7e3c5b9d2c4603e4dfb22bf75ef7a23可以通过写入下列空文件来禁用它/etc/rkt/trustedkeys/prefix.d/coreos.com/a175e31de7e3c5b9d2c4603e4dfb22bf75ef7a23这一空文件即撤销机制在源码中有明确实现keystore 加载 keyring 时pkg/keystore/keystore.go 的loadKeyring对大小为 0 的密钥文件执行delete(trustedKeys, info.Name())从信任集合中移除该指纹MaskTrustedKeySystemPrefix/MaskTrustedKeySystemRoot则负责在/etc/rkt下写入这些空文件。信任的生效域是前缀前缀式的loadKeyring会依次遍历系统/本地 root 目录与系统/本地 prefix 目录并按 prefix 的层级如coreos.com/etcd的父前缀coreos.com向上收集信任。信任 example.com/hello 的密钥下面演示如何信任用于签名example.com/hello前缀镜像的密钥。使用 rkt trust最简便的方式是使用rkt trust子命令直接把包含公钥的 URI 传给它$ rkt trust --prefixexample.com/hello https://example.com/pubkeys.gpg Prefix: example.com/hello Key: https://example.com/aci-pubkeys.gpg GPG key fingerprint is: B346 E31D E7E3 C6F9 D1D4 603F 4DFB 61BF 26EF 7A14 Carly Container (ACI signing key) carlyexample.com Are you sure you want to trust this key (yes/no)? yes Trusting https://example.com/aci-pubkeys.gpg for prefix example.com/hello. Added key for prefix example.com/hello at /etc/rkt/trustedkeys/prefix.d/example.com/hello/b346e31de7e3c6f9d1d4603f4dfb61bf26ef7a14现在指纹为b346e31de7e3c6f9d1d4603f4dfb61bf26ef7a14的公钥将被信任用于所有镜像名前缀为example.com/hello的镜像。rkt trust的实现rkt/trust.go还有几个值得了解的细节不加--prefix也不加--root时rkt 会拒绝执行提示aborting due to implicit unbounded trust防止在未明确范围的情况下隐式建立无限信任--prefix与--root互斥--prefix不允许带 URL scheme会报错提示省略scheme://若不提供公钥参数rkt 会通过 meta discovery 自动发现公钥地址GetPubKeyLocations调用discovery.DiscoverPublicKeys指纹审查环节默认AcceptAsk会在终端交互确认rkt/pubkey/pubkey.go 的reviewKey只接受yes/no非 TTY 环境下无法交互则会报错并提示改用--trust-keys-from-https--skip-fingerprint-review可跳过确认AcceptForce密钥保存时会以 OpenPGP 解析出的主密钥指纹作为文件名fingerprintToFilename输出 40 位十六进制小写指纹目录权限 0755、文件权限 0644见StoreTrustedKeyPrefix。手动添加密钥不使用rkt trust也可以手动把密钥加入 rkt 的密钥数据库。做法是下载密钥、获取其指纹、以指纹为文件名存入数据库。下载公钥$ curl -O https://example.com/pubkeys.gpg获取公钥指纹$ gpg --no-default-keyring --with-fingerprint --keyring ./pubkeys.gpg carlyexample.com pub 2048R/26EF7A14 2015-01-09 Key fingerprint B346 E31D E7E3 C6F9 D1D4 603F 4DFB 61BF 26EF 7A14 uid [ unknown] Carly Container (ACI signing key) carlyexample.com sub 2048R/B9C074CD 2015-01-09去掉空格并转为小写$ echo B346 E31D E7E3 C6F9 D1D4 603F 4DFB 61BF 26EF 7A14 | \ tr -d [:space:] | tr [:upper:] [:lower:]b346e31de7e3c6f9d1d4603f4dfb61bf26ef7a14为 example.com/hello 前缀信任该密钥mkdir -p /etc/rkt/trustedkeys/prefix.d/example.com/hello mv pubkeys.gpg /etc/rkt/trustedkeys/prefix.d/example.com/hello/b346e31de7e3c6f9d1d4603f4dfb61bf26ef7a14现在指纹为b346e31de7e3c6f9d1d4603f4dfb61bf26ef7a14的公钥将被信任用于所有镜像名前缀为example.com/hello的镜像。注意手动放置的密钥文件同样会被entityFromFile做指纹一致性校验——密钥文件必须命名为其真实指纹否则报fingerprint mismatch错误并被拒绝加载因此指纹的获取与命名必须精确。全局信任一个密钥如果想信任一个公钥用于任意镜像把它存入以下任一root目录/etc/rkt/trustedkeys/root.d /usr/lib/rkt/trustedkeys/root.d示例使用Example Usage下载、校验并运行一个 ACI默认情况下rkt 会尝试下载 ACI 的分离签名并校验镜像# rkt run example.com/hello:0.0.1 rkt: starting to discover app img example.com/hello:0.0.1 rkt: starting to fetch img from http://example.com/images/example.com/hello-0.0.1-linux-amd64.aci Downloading aci: [ ] 7.24 KB/1.26 MB rkt: example.com/hello:0.0.1 verified signed by: Carly Container (ACI signing key) carlyexample.com /etc/localtime is not a symlink, not updating container timezone. ^]^]Container stage1 terminated by signal KILL.输出中的verified signed by:一行即表示镜像已通过信任公钥的签名校验并输出了签名者身份。使用--insecure-optionsimage可针对单次运行关闭镜像校验# rkt --insecure-optionsimage run example.com/hello:0.0.1 rkt: starting to discover app img example.com/hello:0.0.1 rkt: starting to fetch img from http://example.com/images/example.com/hello-0.0.1-linux-amd64.aci rkt: warning: image signature verification has been disabled Downloading aci: [ ] 32.8 KB/1.26 MB /etc/localtime is not a symlink, not updating container timezone. ^]^]Container stage1 terminated by signal KILL.注意使用--insecure-optionsimage时rkt 会打印如下警告rkt: warning: image signature verification has been disabled--insecure-options的取值定义在 rkt/flag/secflags.go除image跳过镜像签名校验外还包括tls跳过 TLS 校验、http允许 HTTP、pubkey允许通过不安全连接获取签名密钥、capabilities/paths/seccomp跳过运行时安全特性、以及便捷组合all-fetch、all-run与all。校验被跳过后rkt 走SkipImageCheck()分支直接下载镜像不再执行签名获取与验证见 rkt/image/namefetcher.go 的fetch与 rkt/image/httpfetcher.go 的fetchURL。下载并校验一个 ACI不运行使用fetch子命令可以只下载并校验 ACI而不立即运行 Pod。这在需要向大量主机预缓存 ACI 时非常有用# rkt fetch example.com/hello:0.0.1 rkt: starting to discover app img example.com/hello:0.0.1 rkt: starting to fetch img from http://example.com/images/example.com/hello-0.0.1-linux-amd64.aci Downloading aci: [ ] 14.5 KB/1.26 MB rkt: example.com/hello:0.0.1 verified signed by: Carly Container (ACI signing key) carlyexample.com sha512-b3f138e10482d4b5f334294d69ae5c40与之前相同使用--insecure-optionsimage可关闭镜像校验# rkt --insecure-optionsimage fetch example.com/hello:0.0.1 rkt: starting to discover app img example.com/hello:0.0.1 rkt: starting to fetch img from http://example.com/images/example.com/hello-0.0.1-linux-amd64.aci rkt: warning: image signature verification has been disabled Downloading aci: [ ] 4.34 KB/1.26 MB sha512-b3f138e10482d4b5f334294d69ae5c40输出末尾的sha512-...是镜像在本地 store 中的内容寻址键content-addressable key。关于fetch与run在镜像拉取策略上的差异可参考 Documentation/image-fetching-behavior.mdrun/prepare默认--pull-policynew先查本地 store缺失再远程拉取而fetch默认--pull-policyupdate尝试远程获取但复用未变更内容另有never只查本地。端到端校验链路小结从源码看一次带校验的远程拉取rkt run example.com/hello:0.0.1的完整链路为rkt/image/fetcher.go 的Fetcher.FetchImage判断镜像类型并路由到 nameFetcher按名发现rkt/image/namefetcher.go 的discoverApp通过 appc 规范的discovery.DiscoverACIEndpoints完成 meta discovery得到 ACI 与 ASC URL若 keystore 中尚无该前缀的信任密钥maybeFetchPubKeys会尝试经ac-discovery-pubkeys自动发现并在 TTY 交互确认或--trust-keys-from-https强制下写入信任DownloadSignature经 rkt/image/asc.go 的asc/remoteAscFetcher获取.asc签名文件validaterkt/image/validator.go校验 manifest 中的镜像名、标签最终由keystore.CheckSignaturepkg/keystore/keystore.go使用 OpenPGP 完成分离签名验证并通过printIdentities打印签名者身份校验通过后镜像写入 storerun才真正启动容器。该验证逻辑对应的功能测试可参考 tests/rkt_image_verify_test.go 与 tests/rkt_trust_test.go它们分别覆盖了镜像签名校验与rkt trust的端到端行为。总结rkt 的签名与校验体系建立在 App Container 规范之上由三个可独立掌握的环节构成签名gpg 生成密钥对并为 ACI 制作分离签名、分发通过ac-discovery/ac-discovery-pubkeysmeta 标签让镜像与公钥可被自动发现、信任与校验rkt trust或手动落盘建立 keystore 信任拉取时强制校验签名。理解 keystore 的 root/prefix 分层、空文件撤销机制、指纹命名约定与--insecure-options的作用域是安全运维 rkt 集群的关键。生产环境建议为每个镜像前缀建立专用签名密钥、通过 HTTPS 分发、始终保留签名校验仅在受控环境中显式使用--insecure-optionsimage。赞分享容器运行时云原生网络【免费下载链接】rkt[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.项目地址https://gitcode.com/gh_mirrors/rk/rkt点击查看免费下载相关推荐AWX 项目签名与校验Project Signing and Verification实战指南基于 ansible-sign 的 GPG 签名与供应链完整性验证AWX 项目签名与校验Project Signing and Verification实战指南基于 ansible sign 的 GPG 签名与供应链完整后端运维任务调度Nix 项目维护者 GPG 签名密钥管理发布签名的信任链与验证指南Nix 项目维护者 GPG 签名密钥管理发布签名的信任链与验证指南 导读 本文聚焦 Nixpurely functional package manager包管理器开发工具CLI构建工具Git Credential Manager 的 GPG 签名验证指南在 Linux 上校验 .deb 包与 tarball 的官方签名Git Credential Manager 的 GPG 签名验证指南在 Linux 上校验 .deb 包与 tarball 的官方签名 导读 本文以 Git开发工具认证鉴权上一篇Qwen2.5-VL-7B-Instruct-quantized.w8a8视频处理指南如何让AI理解动态视觉内容下一篇如何选择RapidOCR模型移动端vs服务器端性能对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考