容器运行时云原生网络【免费下载链接】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 仓库中的 metadata-service 示例程序 为骨架系统讲解 rkt 元数据服务Metadata Service的身份断言能力。你将学会编译 mds-example、在两个 busybox Pod 之间传输并校验带签名的消息文件同时通过源码metadata_service.go、registration.go深入理解签名背后的 HMAC 机制与AC_METADATA_URL的注入链路。一、背景rkt 元数据服务能做什么rkt 的元数据服务由rkt metadata-service命令实现旨在帮助运行中的应用感知自身执行环境并断言其 Pod 身份具体能力包括暴露 Pod 与镜像的 manifest 内容通过 handlePodManifest、handleImageManifest提供便捷的注解annotations查询接口handlePodAnnotations 等为 Pod 提供密码学可验证的身份即基于 HMAC 的签名与验签端点。服务对外暴露两类监听见 runMetadataService通道地址用途Unix socket/run/rkt/metadata-svc.sockPod 注册/注销事件仅本机 stage0 访问TCP端口18112Pod 内应用访问公开 APImanifest、注解、签名验签其中端口与 socket 路径定义在 common/common.goMetadataServicePort 18112、MetadataServiceRegSock /run/rkt/metadata-svc.sockTCP 端口可用--listen-port调整。本指南示例程序mds-example正是围绕元数据服务的Identity Endpoint构建的它调用元数据服务完成对文件的签名sign与验签verify遵循 App Container 规范appc spec中 ACE 的 Identity 端点设计。签名文件格式就是元数据服务返回的签名内容的 base64 编码。二、示例程序源码拆解sign 与 verify 两个子命令示例程序位于 Documentation/examples/metadata-service/main.go是一个单文件 Go 程序通过两个子命令工作sign --fileFILE --signatureSIGNATURE_FILE读取待签名文件内容POST 到元数据服务的签名端点将响应体base64 签名写入指定文件verify --fileFILE --uuidPOD_UUID --signatureSIGNATURE_FILE将文件内容、发送方 Pod UUID 与签名一并 POST 到验签端点根据 HTTP 状态码判定签名是否有效。2.1 命令行参数定义init()中使用标准库flag定义参数main.gosign--file待签名文件、--signature签名输出文件verify--file待验证文件、--uuid发送方Pod 的 UUID、--signature签名文件。usage()main.go输出完整的命令帮助parseArgs在参数缺失或命令非法时报错退出。2.2 签名流程sign()签名核心逻辑在 sign()从AC_METADATA_URL环境变量读取元数据服务地址mdsURL拼接签名端点路径acMetadata/v1/pod/hmac/sign使用path.Join生成与元数据服务端路由runPublicServer中注册的/pod/hmac/sign对应ioutil.ReadFile读入待签名文件通过http.PostForm将内容作为content表单字段提交响应状态为 200 时将响应体base64 编码的 HMAC 签名以0600权限写入签名文件。值得注意的是verify()main.go在拼接端点时使用path.Join(/, acMetadata, v1, pod, hmac, verify)注意首部没有 token 段——因为AC_METADATA_URL本身已包含 token 前缀见第五节。2.3 验签流程verify()读取待验证文件内容与签名文件POST 三个表单字段content、uuid发送方 Pod UUID、signature按状态码判定200 OK返回有效true403 Forbidden返回无效false其他状态视为未知错误。主函数 main() 中AC_METADATA_URL缺失时会输出诊断提示$AC_METADATA_URL env variable not found, are you in a rkt container and is the rkt metadata service running on the host?验签成功打印signature OK失败打印signature INVALID并以退出码 1 结束。三、编译示例程序在 Documentation/examples/metadata-service 目录下执行$ CGO_ENABLED0 go build -o mds-example设置CGO_ENABLED0可生成纯静态二进制便于在容器内挂载运行。四、端到端演练在两个 Pod 之间签名并传输文件以下步骤取自 README 原文并补充注释。前提已编译 mds-example、宿主上元数据服务正在运行。4.1 启动两个 busybox Pod启动 POD a交互式、注册元数据服务并把 mds-example 以 host volume 挂载进/bin/mds-example$ sudo rkt run --mds-register --interactive --volumemds-example,kindhost,source$PWD/mds-example kinvolk.io/aci/busybox:1.24 --mount volumemds-example,target/bin/mds-example [POD a] / #再启动 POD b相同命令$ sudo rkt run --mds-register --interactive --volumemds-example,kindhost,source$PWD/mds-example kinvolk.io/aci/busybox:1.24 --mount volumemds-example,target/bin/mds-example [POD b] / #关键点是--mds-register该标志在 rkt/run.go 中定义为register pod with metadata service. needs network connectivity to the host (--net(default|default-restricted|host)且与--netnone不兼容rkt/run.go。4.2 在 POD a 中创建并签名消息[POD a] / # echo Very trustworthy message msg.txt [POD a] / # mds-example sign --filemsg.txt --signaturemsg.sig [POD a] / # ls -l msg* -rw------- 1 root root 125 Dec 18 17:34 msg.sig -rw-r--r-- 1 root root 25 Dec 18 17:34 msg.txt可以看到签名文件以0600权限写出大小 125 字节即 96 字节 SHA-512 HMAC 的 base64 编码加上换行。4.3 通过 nc 将消息与签名传输到 POD b先获取 POD b 的 IP[POD b] / # ip a (...) inet 172.16.28.84/24 scope global eth0 (...)在 POD b 上先监听接收消息再到 POD a 发送# 在 POD b [POD b] / # nc -l -p 9090 msg.txt # 切换到 POD a 发送 [POD a] / # nc 172.16.28.84 9090 msg.txt再用同样方式传输签名文件# 在 POD b [POD b] / # nc -l -p 9090 msg.sig # 切换到 POD a 发送 [POD a] / # nc 172.16.28.84 9090 msg.sig4.4 获取 POD a 的 UUID元数据服务把 Pod UUID 通过公开接口暴露Pod 内可用AC_METADATA_URL直接查询[POD a] / # echo $(wget -q -O - $AC_METADATA_URL/acMetadata/v1/pod/uuid) d1703a6a-568a-48ee-b84b-4ccd803743dd这里AC_METADATA_URL由 rkt 在 Pod 启动时注入见第五节。4.5 在 POD b 中验证消息[POD b] / # cat msg.txt Very trustworthy message [POD b] / # mds-example verify --file msg.txt --uuidd1703a6a-568a-48ee-b84b-4ccd803743dd --signaturemsg.sig signature OK验证时提交的--uuid必须使用发送方签名方Pod的 UUID因为签名正是用该 UUID 参与计算的见下文 HMAC 原理。如果文件被篡改或 UUID 不匹配程序会输出signature INVALID并退出码为 1。五、底层原理AC_METADATA_URL 注入与 HMAC 签名5.1 注册与 token 机制Pod 注册发生在 stage0 的 run.go当--mds-register开启时调用registerPod()registration.go流程为生成 16 字节随机 tokengenerateMDSToken通过 Unix socket/run/rkt/metadata-svc.sock以PUT /pods/{uuid}?token...注册 Pod manifest再为每个 app 以PUT /pods/{uuid}/{app}注册 Image manifest将--mds-token$TOKEN传给 stage1最终 stage1 init 依据网络情况构造元数据服务公开 URL。网络初始化阶段stage1/init/init.go根据 Pod 的网络模式决定公开 URL 的 IP有 CNI 网络时使用可转发的主机 IP否则使用localhost。URL 的拼接格式定义在 common/common.gofunc MetadataServicePublicURL(ip net.IP, token string) string { return fmt.Sprintf(http://%v:%v/%v, ip, MetadataServicePort, token) }即http://ip:18112/token。随后 stage1 在构建应用环境时把该 URL 注入为环境变量stage1/init/common/app.goif p.MetadataServiceURL ! { pa.env.Set(AC_METADATA_URL, p.MetadataServiceURL) }这正是示例程序从AC_METADATA_URL取地址、且 URL 自带 token 前缀的原因——token 是 Pod 在元数据服务中的身份凭证公开 API 的路由统一以/{token}/acMetadata/v1为前缀runPublicServer。5.2 签名与验签的 HMAC 实现元数据服务在启动时通过initCrypto()从系统熵源生成 512 位 HMAC 密钥metadata_service.go密钥仅存于进程内存。签名端点 handlePodSign用 token 查得 Pod UUID校验content表单字段非空计算HMAC-SHA-512( UUID 字节 || content )以 base64 编码返回Content-Type 为text/plain; charsetus-ascii。验签端点 handlePodVerify解析uuid、content、signaturebase64 解码三个字段用提交的 UUID 与 content 重算 HMAC通过hmac.Equal常量时间比较匹配返回200不匹配返回403 Forbidden。这里的核心安全语义签名是把内容绑定到特定 Pod 身份的密钥化哈希因此验签时必须知道签名方的 UUID同时 HMAC 密钥不会离开元数据服务应用之间无法伪造彼此签名。token 即谁有权限让元数据服务代表 Pod 签名/验签的认证凭据因此元数据服务进程与 Pod 之间应视为互信边界。5.3 Pod 注销Pod 停止时stage0 的unregisterPod()registration.go会依据mds-registered标记文件向/pods/{uuid}发送DELETE请求从 podStore内存中的双索引表metadata_service.go移除对应记录。六、局限与注意事项README 明确声明这是一个示例应用它把整个文件内容读入内存并作为表单字段 POST不适用于大文件签名仅提供完整性校验与 Pod 身份绑定不提供加密与机密性未做并发、流式、超时等生产级处理不适合生产环境直接使用。生产场景应参考 Documentation/subcommands/metadata-service.md 的完整接口说明含--listen-port选项与 systemd socket activation 注意事项并结合业务自行实现流式签名方案。七、相关文档与源码速查元数据服务完整说明Documentation/subcommands/metadata-service.md示例程序源码Documentation/examples/metadata-service/main.go元数据服务实现rkt/metadata_service.goPod 注册/注销与 token 生成stage0/registration.go--mds-register标志定义rkt/run.go元数据服务端口与 socket 常量common/common.goAC_METADATA_URL注入stage1/init/common/app.go元数据服务相关测试rkt/metadata_service_test.go、rkt_metadata_service_test.go赞分享容器运行时云原生网络【免费下载链接】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点击查看免费下载相关推荐Tink Java 数字签名实战用 PublicKeySign / PublicKeyVerify 对文件签名与验签Tink Java 数字签名实战用 PublicKeySign / PublicKeyVerify 对文件签名与验签 导读 本文以 Tink 仓库中的 Jav密码学x402 Offer-Receipt 扩展实战在 Express 服务器中实现签名 Offer 与签名 Receiptx402 Offer Receipt 扩展实战在 Express 服务器中实现签名 Offer 与签名 Receipt 本指南以 x402 仓库中 offer后端金融科技区块链API设计goxmldsig 实战指南纯 Go 实现 XML 数字签名与 SAML 2.0 签名验证goxmldsig 实战指南纯 Go 实现 XML 数字签名与 SAML 2.0 签名验证 导读 goxmldsig 是一个使用纯 Go 实现的 XML 数字后端微服务存储认证鉴权上一篇RabbitMQ备份恢复数据迁移和灾难恢复方案下一篇如何通过自定义LabelImg导出模板解决特定项目标注格式需求创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 rkt 元数据服务实战：用 mds-example 在 Pod 间实现文件签名与验签
容器运行时云原生网络【免费下载链接】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 仓库中的 metadata-service 示例程序 为骨架系统讲解 rkt 元数据服务Metadata Service的身份断言能力。你将学会编译 mds-example、在两个 busybox Pod 之间传输并校验带签名的消息文件同时通过源码metadata_service.go、registration.go深入理解签名背后的 HMAC 机制与AC_METADATA_URL的注入链路。一、背景rkt 元数据服务能做什么rkt 的元数据服务由rkt metadata-service命令实现旨在帮助运行中的应用感知自身执行环境并断言其 Pod 身份具体能力包括暴露 Pod 与镜像的 manifest 内容通过 handlePodManifest、handleImageManifest提供便捷的注解annotations查询接口handlePodAnnotations 等为 Pod 提供密码学可验证的身份即基于 HMAC 的签名与验签端点。服务对外暴露两类监听见 runMetadataService通道地址用途Unix socket/run/rkt/metadata-svc.sockPod 注册/注销事件仅本机 stage0 访问TCP端口18112Pod 内应用访问公开 APImanifest、注解、签名验签其中端口与 socket 路径定义在 common/common.goMetadataServicePort 18112、MetadataServiceRegSock /run/rkt/metadata-svc.sockTCP 端口可用--listen-port调整。本指南示例程序mds-example正是围绕元数据服务的Identity Endpoint构建的它调用元数据服务完成对文件的签名sign与验签verify遵循 App Container 规范appc spec中 ACE 的 Identity 端点设计。签名文件格式就是元数据服务返回的签名内容的 base64 编码。二、示例程序源码拆解sign 与 verify 两个子命令示例程序位于 Documentation/examples/metadata-service/main.go是一个单文件 Go 程序通过两个子命令工作sign --fileFILE --signatureSIGNATURE_FILE读取待签名文件内容POST 到元数据服务的签名端点将响应体base64 签名写入指定文件verify --fileFILE --uuidPOD_UUID --signatureSIGNATURE_FILE将文件内容、发送方 Pod UUID 与签名一并 POST 到验签端点根据 HTTP 状态码判定签名是否有效。2.1 命令行参数定义init()中使用标准库flag定义参数main.gosign--file待签名文件、--signature签名输出文件verify--file待验证文件、--uuid发送方Pod 的 UUID、--signature签名文件。usage()main.go输出完整的命令帮助parseArgs在参数缺失或命令非法时报错退出。2.2 签名流程sign()签名核心逻辑在 sign()从AC_METADATA_URL环境变量读取元数据服务地址mdsURL拼接签名端点路径acMetadata/v1/pod/hmac/sign使用path.Join生成与元数据服务端路由runPublicServer中注册的/pod/hmac/sign对应ioutil.ReadFile读入待签名文件通过http.PostForm将内容作为content表单字段提交响应状态为 200 时将响应体base64 编码的 HMAC 签名以0600权限写入签名文件。值得注意的是verify()main.go在拼接端点时使用path.Join(/, acMetadata, v1, pod, hmac, verify)注意首部没有 token 段——因为AC_METADATA_URL本身已包含 token 前缀见第五节。2.3 验签流程verify()读取待验证文件内容与签名文件POST 三个表单字段content、uuid发送方 Pod UUID、signature按状态码判定200 OK返回有效true403 Forbidden返回无效false其他状态视为未知错误。主函数 main() 中AC_METADATA_URL缺失时会输出诊断提示$AC_METADATA_URL env variable not found, are you in a rkt container and is the rkt metadata service running on the host?验签成功打印signature OK失败打印signature INVALID并以退出码 1 结束。三、编译示例程序在 Documentation/examples/metadata-service 目录下执行$ CGO_ENABLED0 go build -o mds-example设置CGO_ENABLED0可生成纯静态二进制便于在容器内挂载运行。四、端到端演练在两个 Pod 之间签名并传输文件以下步骤取自 README 原文并补充注释。前提已编译 mds-example、宿主上元数据服务正在运行。4.1 启动两个 busybox Pod启动 POD a交互式、注册元数据服务并把 mds-example 以 host volume 挂载进/bin/mds-example$ sudo rkt run --mds-register --interactive --volumemds-example,kindhost,source$PWD/mds-example kinvolk.io/aci/busybox:1.24 --mount volumemds-example,target/bin/mds-example [POD a] / #再启动 POD b相同命令$ sudo rkt run --mds-register --interactive --volumemds-example,kindhost,source$PWD/mds-example kinvolk.io/aci/busybox:1.24 --mount volumemds-example,target/bin/mds-example [POD b] / #关键点是--mds-register该标志在 rkt/run.go 中定义为register pod with metadata service. needs network connectivity to the host (--net(default|default-restricted|host)且与--netnone不兼容rkt/run.go。4.2 在 POD a 中创建并签名消息[POD a] / # echo Very trustworthy message msg.txt [POD a] / # mds-example sign --filemsg.txt --signaturemsg.sig [POD a] / # ls -l msg* -rw------- 1 root root 125 Dec 18 17:34 msg.sig -rw-r--r-- 1 root root 25 Dec 18 17:34 msg.txt可以看到签名文件以0600权限写出大小 125 字节即 96 字节 SHA-512 HMAC 的 base64 编码加上换行。4.3 通过 nc 将消息与签名传输到 POD b先获取 POD b 的 IP[POD b] / # ip a (...) inet 172.16.28.84/24 scope global eth0 (...)在 POD b 上先监听接收消息再到 POD a 发送# 在 POD b [POD b] / # nc -l -p 9090 msg.txt # 切换到 POD a 发送 [POD a] / # nc 172.16.28.84 9090 msg.txt再用同样方式传输签名文件# 在 POD b [POD b] / # nc -l -p 9090 msg.sig # 切换到 POD a 发送 [POD a] / # nc 172.16.28.84 9090 msg.sig4.4 获取 POD a 的 UUID元数据服务把 Pod UUID 通过公开接口暴露Pod 内可用AC_METADATA_URL直接查询[POD a] / # echo $(wget -q -O - $AC_METADATA_URL/acMetadata/v1/pod/uuid) d1703a6a-568a-48ee-b84b-4ccd803743dd这里AC_METADATA_URL由 rkt 在 Pod 启动时注入见第五节。4.5 在 POD b 中验证消息[POD b] / # cat msg.txt Very trustworthy message [POD b] / # mds-example verify --file msg.txt --uuidd1703a6a-568a-48ee-b84b-4ccd803743dd --signaturemsg.sig signature OK验证时提交的--uuid必须使用发送方签名方Pod的 UUID因为签名正是用该 UUID 参与计算的见下文 HMAC 原理。如果文件被篡改或 UUID 不匹配程序会输出signature INVALID并退出码为 1。五、底层原理AC_METADATA_URL 注入与 HMAC 签名5.1 注册与 token 机制Pod 注册发生在 stage0 的 run.go当--mds-register开启时调用registerPod()registration.go流程为生成 16 字节随机 tokengenerateMDSToken通过 Unix socket/run/rkt/metadata-svc.sock以PUT /pods/{uuid}?token...注册 Pod manifest再为每个 app 以PUT /pods/{uuid}/{app}注册 Image manifest将--mds-token$TOKEN传给 stage1最终 stage1 init 依据网络情况构造元数据服务公开 URL。网络初始化阶段stage1/init/init.go根据 Pod 的网络模式决定公开 URL 的 IP有 CNI 网络时使用可转发的主机 IP否则使用localhost。URL 的拼接格式定义在 common/common.gofunc MetadataServicePublicURL(ip net.IP, token string) string { return fmt.Sprintf(http://%v:%v/%v, ip, MetadataServicePort, token) }即http://ip:18112/token。随后 stage1 在构建应用环境时把该 URL 注入为环境变量stage1/init/common/app.goif p.MetadataServiceURL ! { pa.env.Set(AC_METADATA_URL, p.MetadataServiceURL) }这正是示例程序从AC_METADATA_URL取地址、且 URL 自带 token 前缀的原因——token 是 Pod 在元数据服务中的身份凭证公开 API 的路由统一以/{token}/acMetadata/v1为前缀runPublicServer。5.2 签名与验签的 HMAC 实现元数据服务在启动时通过initCrypto()从系统熵源生成 512 位 HMAC 密钥metadata_service.go密钥仅存于进程内存。签名端点 handlePodSign用 token 查得 Pod UUID校验content表单字段非空计算HMAC-SHA-512( UUID 字节 || content )以 base64 编码返回Content-Type 为text/plain; charsetus-ascii。验签端点 handlePodVerify解析uuid、content、signaturebase64 解码三个字段用提交的 UUID 与 content 重算 HMAC通过hmac.Equal常量时间比较匹配返回200不匹配返回403 Forbidden。这里的核心安全语义签名是把内容绑定到特定 Pod 身份的密钥化哈希因此验签时必须知道签名方的 UUID同时 HMAC 密钥不会离开元数据服务应用之间无法伪造彼此签名。token 即谁有权限让元数据服务代表 Pod 签名/验签的认证凭据因此元数据服务进程与 Pod 之间应视为互信边界。5.3 Pod 注销Pod 停止时stage0 的unregisterPod()registration.go会依据mds-registered标记文件向/pods/{uuid}发送DELETE请求从 podStore内存中的双索引表metadata_service.go移除对应记录。六、局限与注意事项README 明确声明这是一个示例应用它把整个文件内容读入内存并作为表单字段 POST不适用于大文件签名仅提供完整性校验与 Pod 身份绑定不提供加密与机密性未做并发、流式、超时等生产级处理不适合生产环境直接使用。生产场景应参考 Documentation/subcommands/metadata-service.md 的完整接口说明含--listen-port选项与 systemd socket activation 注意事项并结合业务自行实现流式签名方案。七、相关文档与源码速查元数据服务完整说明Documentation/subcommands/metadata-service.md示例程序源码Documentation/examples/metadata-service/main.go元数据服务实现rkt/metadata_service.goPod 注册/注销与 token 生成stage0/registration.go--mds-register标志定义rkt/run.go元数据服务端口与 socket 常量common/common.goAC_METADATA_URL注入stage1/init/common/app.go元数据服务相关测试rkt/metadata_service_test.go、rkt_metadata_service_test.go赞分享容器运行时云原生网络【免费下载链接】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点击查看免费下载相关推荐Tink Java 数字签名实战用 PublicKeySign / PublicKeyVerify 对文件签名与验签Tink Java 数字签名实战用 PublicKeySign / PublicKeyVerify 对文件签名与验签 导读 本文以 Tink 仓库中的 Jav密码学x402 Offer-Receipt 扩展实战在 Express 服务器中实现签名 Offer 与签名 Receiptx402 Offer Receipt 扩展实战在 Express 服务器中实现签名 Offer 与签名 Receipt 本指南以 x402 仓库中 offer后端金融科技区块链API设计goxmldsig 实战指南纯 Go 实现 XML 数字签名与 SAML 2.0 签名验证goxmldsig 实战指南纯 Go 实现 XML 数字签名与 SAML 2.0 签名验证 导读 goxmldsig 是一个使用纯 Go 实现的 XML 数字后端微服务存储认证鉴权上一篇RabbitMQ备份恢复数据迁移和灾难恢复方案下一篇如何通过自定义LabelImg导出模板解决特定项目标注格式需求创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考