新闻详情

新闻详情

首页 / 资讯中心 / 详情

rkt 元数据服务实战:用 mds-example 在 Pod 间实现文件签名与验签

发布时间:2026/11/14 11:36:08来源:尧图网络
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),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

【外设】之大彩串口显示屏 2026/11/14 3:51:47

【外设】之大彩串口显示屏

大彩串口屏初步使用 1 .官网下载 STM32 屏幕 GUI 设计资料 http://www.gz-dc.com/category/typeid/4112 找到 STM32 Keil 工程,移植相关代码因项目而异进行移植,由于项目简单,本人只对用到的指令接口进行修改。 比如:注意事项&…

阅读更多 →
无法下载Windows系统iso文件 2026/11/12 23:59:09

无法下载Windows系统iso文件

当我遇到这个问题的时候,我打开了一个网站: 登录 然后我打算下载的时候: 突然那个官方的连接就可以下载了:

阅读更多 →
【清华代码熊】DeepSeek V4.1 Flash 后训练详解 2026/11/14 10:11:15

【清华代码熊】DeepSeek V4.1 Flash 后训练详解

📌 上期解析了 DeepSeek V4.1 Flash 模型架构改进,本期解析 DeepSeek V4.1 Flash 预训练/后训练技术: 🌟 预训练:45T 文本 多模态混合语料、直接训练 sparse attention(取消 DeepSeek V4 的 dense 冷启动&…

阅读更多 →
Shuffle-R1: Efficient RL framework for Multimodal Large Language Models via Data-centric Dynamic ... 2026/11/13 13:31:48

Shuffle-R1: Efficient RL framework for Multimodal Large Language Models via Data-centric Dynamic ...

文章主要内容和创新点 主要内容 本文聚焦于多模态大语言模型(MLLM)强化学习(RL)训练中的效率问题,提出了一个名为Shuffle-R1的框架。研究发现,当前RL训练存在两个关键缺陷: 优势值坍缩(Advantage Collapsing):批次中大多数优势值集中在零附近,导致有效梯度信号被淹…

阅读更多 →
PRvL: Quantifying the Capabilities and Risks of Large Language Models for PII Redaction 2026/11/13 16:11:45

PRvL: Quantifying the Capabilities and Risks of Large Language Models for PII Redaction

一、文章主要内容总结 本文聚焦于利用大型语言模型(LLMs)实现个人身份信息(PII)脱敏的研究,旨在解决传统脱敏方法(如基于规则的系统、领域特定命名实体识别(NER)模型)泛化能力差、跨格式/跨语境适应性弱的问题。 研究通过全面评估多种LLM架构(包括密集型LLM(D-LLM…

阅读更多 →
LLaVA-RE: Binary Image-Text Relevancy Evaluation with Multimodal Large Language Model 2026/11/14 3:51:43

LLaVA-RE: Binary Image-Text Relevancy Evaluation with Multimodal Large Language Model

文章主要内容和创新点 主要内容 本文聚焦于二进制图像-文本相关性评估任务(判断图像与文本“相关”或“不相关”),针对该任务中文本格式多样、相关性定义随场景变化等挑战,提出了基于多模态大语言模型(MLLM)的解决方案LLaVA-RE。 模型设计:LLaVA-RE基于LLaVA 1.5架构,…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉