容器運(yùn)行時(shí)云原生【免費(fèi)下載鏈接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:項(xiàng)目地址https://gitcode.com/gh_mirrors/do/docker-ce點(diǎn)擊查看免費(fèi)下載導(dǎo)讀docker trust inspect是 Docker Content Trust內(nèi)容信任體系中用于只讀查詢鏡像倉庫簽名與密鑰信息的核心命令。它以 JSON默認(rèn)或人類可讀表格--pretty兩種格式輸出指定鏡像倉庫中所有已簽名標(biāo)簽的摘要、簽名者名單、委托簽名者及其密鑰 ID、倉庫 Root 與 Repository 管理密鑰是安全團(tuán)隊(duì)審計(jì)鏡像供應(yīng)鏈、開發(fā)者排查簽名問題最直接的診斷工具。本文基于 docker-ce 倉庫中該命令的官方文檔與完整源碼實(shí)現(xiàn)系統(tǒng)講解其用法、JSON 與表格輸出語義、底層數(shù)據(jù)流與常見錯誤處理助你徹底掌握docker trust inspect的使用與原理。命令概覽用法與選項(xiàng)docker trust inspect屬于 Docker CLI 的docker trust命令族負(fù)責(zé)返回關(guān)于密鑰與簽名的低層low-level信息。其完整用法如下Usage: docker trust inspect IMAGE[:TAG] [IMAGE[:TAG]...] Return low-level information about keys and signatures Options: --help Print usage --pretty Print the information in a human friendly format關(guān)鍵點(diǎn)參數(shù)至少需要 1 個(gè)IMAGE[:TAG]。從源碼看命令通過cli.RequiresMinArgs(1)強(qiáng)制至少一個(gè)參數(shù)不提供參數(shù)會直接報(bào)錯requires at least 1 argument見 inspect.go 與對應(yīng)測試 inspect_test.go。--pretty以人類友好的表格格式輸出取代默認(rèn)的 JSON。prettyPrint布爾標(biāo)志定義在 inspect.go。--help打印用法說明。在 cmd.go 中可以看到inspect與revoke、sign、key、signer一起注冊為docker trust的子命令屬于Manage trust on Docker images信任管理體系的一部分。命令用途說明docker trust inspect為已簽名的倉庫提供低層 JSON 信息包括所有已簽名的鏡像標(biāo)簽tags這些標(biāo)簽由誰簽名signers哪些實(shí)體可以為新標(biāo)簽簽名即通過docker trust signer add配置的委托簽名者。在默認(rèn) JSON 輸出中數(shù)據(jù)按trustRepo結(jié)構(gòu)序列化其字段在源碼 common.go 中定義JSON 字段含義Name被查詢的鏡像倉庫名含 tag 時(shí)原樣保留SignedTags已簽名標(biāo)簽列表每個(gè)包含SignedTag標(biāo)簽名、Digest內(nèi)容尋址摘要、Signers簽名者列表Signers倉庫配置的委托簽名者及其密鑰 ID 列表未配置時(shí)為空數(shù)組AdministrativeKeys管理密鑰Repository倉庫 targets 密鑰與Root信任根密鑰底層實(shí)現(xiàn)inspect 命令的數(shù)據(jù)流與原理為了真正理解docker trust inspect輸出中每個(gè)字段的來源我們需要進(jìn)入其源碼實(shí)現(xiàn)。命令的核心數(shù)據(jù)獲取函數(shù)是lookupTrustInfocommon.go整個(gè)數(shù)據(jù)流如下1. 解析鏡像引用與鑒權(quán)信息imgRefAndAuth, err : trust.GetImageReferencesAndAuth(ctx, nil, image.AuthResolver(cli), remote)這一步通過 cli/trust/trust.go 中的GetImageReferencesAndAuth完成調(diào)用reference.ParseNormalizedNamed解析IMAGE[:TAG]并將倉庫名解析為RepositoryInfo同時(shí)解析出tag與digest。測試用例覆蓋了非法引用如ALPINE大寫的invalid reference format、純 SHA 摘要的invalid repository name。2. 建立 Notary 客戶端只讀notaryRepo, err : cli.NotaryClient(imgRefAndAuth, trust.ActionsPullOnly)docker trust inspect以**只讀pull only**模式訪問 Notary 倉庫。GetNotaryRepositorytrust.go會構(gòu)造帶鑒權(quán)的 HTTP 傳輸層先是GET server/v2/的 ping 探測用于解析 Registry/Notary 的 challenge 鑒權(quán)方式再根據(jù)倉庫 Index 信息決定信任服務(wù)器地址——官方鏡像默認(rèn)使用https://notary.docker.io非官方鏡像使用https://registry-name也可通過環(huán)境變量DOCKER_CONTENT_TRUST_SERVER覆蓋。密鑰與元數(shù)據(jù)緩存在$DOCKER_CONFIG/trust目錄下GetTrustDirectory。3. 清理 changelist 并讀取簽名if err clearChangeList(notaryRepo); err ! nil { ... } allSignedTargets, err : notaryRepo.GetAllTargetMetadataByName(tag)clearChangeList清空 notary 暫存區(qū) changelist見 helpers.go。隨后通過GetAllTargetMetadataByName(tag)按 tag 拉取全部 targets 元數(shù)據(jù)。若倉庫未初始化或無法訪問返回No signatures or cannot access remote若目標(biāo)不存在client.ErrNoSuchTarget則返回空表。4. 匹配已發(fā)布簽名signatureRows : matchReleasedSignatures(allSignedTargets)matchReleasedSignaturescommon.go是輸出語義的關(guān)鍵只有被簽名進(jìn)入targets或targets/releases這兩個(gè)released角色的標(biāo)簽才會被列入SignedTags其他所有為同一(tag, digest)組合簽名的委托角色如targets/alice都會被計(jì)入該標(biāo)簽的Signers若某標(biāo)簽僅由targets/targets/releases簽名沒有額外委托簽名者Signers為空之后在輸出階段統(tǒng)一顯示為Repo Admin輸出按標(biāo)簽名做自然排序natural sort。這一是否 released的判斷在isReleasedTargethelpers.go中定義而 TUF 角色名到人類可讀簽名者名的轉(zhuǎn)換由notaryRoleToSignerhelpers.go完成——即去掉targets/前綴targets與targets/releases顯示為Repo Admin。相關(guān)的單元測試見 inspect_pretty_test.go 中的TestMatchReleasedSignatureFromTargets、TestMatchOneReleasedMultiSignature等。5. 獲取管理角色與委托角色adminRolesWithSigs, err : notaryRepo.ListRoles() // Root、Targets 等管理角色 delegationRoles, err : notaryRepo.GetDelegationRoles() // 委托簽名角色管理角色ListRoles用于生成AdministrativeKeysdata.CanonicalRootRole顯示為Rootdata.CanonicalTargetsRole顯示為Repository見 inspect.go。委托角色GetDelegationRoles用于生成Signers列表源碼會跳過targets/releases、root、snapshot、targets、timestamp等基礎(chǔ)角色只保留真正的委托簽名者見getDelegationRoleToKeyMapcommon.go。6. 兩條輸出路徑runInspectinspect.go按--pretty是否開啟分叉默認(rèn) JSON 路徑將getRepoTrustInfo得到的trustRepo結(jié)構(gòu)交給通用inspect.Inspectinspector.go最終經(jīng)IndentedInspector以 4 空格縮進(jìn)的 JSON 數(shù)組輸出。--pretty路徑調(diào)用prettyPrintTrustInfoinspect_pretty.go按區(qū)塊輸出Signatures for repo、List of signers and their keys for repo僅存在委托簽名者時(shí)、Administrative keys for repo三部分表格。多鏡像查詢時(shí)pretty 模式會在每個(gè)倉庫輸出之間插入空行作為分隔inspect.go。實(shí)戰(zhàn)示例一查看單個(gè)鏡像標(biāo)簽的簽名細(xì)節(jié)查詢單個(gè)鏡像標(biāo)簽的信任信息直接傳入IMAGE[:TAG]即可$ docker trust inspect alpine:latest默認(rèn)輸出為 JSON 數(shù)組每個(gè)被查詢對象對應(yīng)數(shù)組中的一個(gè)元素例如[ { Name: alpine:latest, SignedTags: [ { SignedTag: latest, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] } ], Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]字段解讀SignedTags中的每一項(xiàng)列出SignedTag已簽名標(biāo)簽名、其Digest唯一的內(nèi)容尋址摘要以及為該簽名負(fù)責(zé)的Signers。此處僅有Repo Admin表示該標(biāo)簽由倉庫的targets/targets/releases角色簽名沒有額外的委托簽名者。AdministrativeKeys列出Repository與Root兩個(gè)管理密鑰Root是信任鏈的根密鑰Repository是倉庫級管理密鑰兩者共同負(fù)責(zé)修改簽名者signers以及為已簽名倉庫做密鑰輪換key rotation。Signers為空數(shù)組表示該倉庫尚未通過docker trust signer add配置額外的委托簽名者。實(shí)戰(zhàn)示例二帶委托簽名者的倉庫當(dāng)倉庫通過其他docker trust命令如 docker trust signer add配置了簽名者后docker trust inspect會額外輸出Signers鍵$ docker trust inspect my-image:purple輸出示例[ { Name: my-image:purple, SignedTags: [ { SignedTag: purple, Digest: 941d3dba358621ce3c41ef67b47cf80f701ff80cdf46b5cc86587eaebfe45557, Signers: [ alice, bob, carol ] } ], Signers: [ { Name: alice, Keys: [ { ID: 04dd031411ed671ae1e12f47ddc8646d98f135090b01e54c3561e843084484a3 }, { ID: 6a11e4898a4014d400332ab0e096308c844584ff70943cdd1d6628d577f45fd8 } ] }, { Name: bob, Keys: [ { ID: 433e245c656ae9733cdcc504bfa560f90950104442c4528c9616daa45824ccba } ] }, { Name: carol, Keys: [ { ID: d32fa8b5ca08273a2880f455fcb318da3dc80aeae1a30610815140deef8f30d9 }, { ID: 9a8bbec6ba2af88a5fad6047d428d17e6d05dbdd03d15b4fc8a9a0e8049cd606 } ] } ], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 27df2c8187e7543345c2e0bf3a1262e0bc63a72754e9a7395eac3f747ec23a44 } ] }, { Name: Root, Keys: [ { ID: 40b66ccc8b176be8c7d365a17f3e046d1c3494e053dd57cfeacfe2e19c4f8e8f } ] } ] } ]此例展示了完整的信任模型purple標(biāo)簽由alice、bob、carol三個(gè)委托簽名者共同簽名Signers區(qū)塊列出每個(gè)簽名者對應(yīng)的密鑰 ID同一簽名者可持有多個(gè)密鑰對應(yīng) TUF 委托角色targets/alice等的 KeyIDs。這些 ID 在源碼中取自委托角色的KeyIDs字段見 inspect.go并按名稱排序輸出。實(shí)戰(zhàn)示例三未簽名標(biāo)簽的行為差異情況 A倉庫本身沒有簽名數(shù)據(jù)或鏡像不可訪問。此時(shí)docker trust inspect不會顯示任何簽名標(biāo)簽而是直接報(bào)錯$ docker trust inspect unsigned-img No signatures or cannot access unsigned-img這正是源碼中l(wèi)ookupTrustInfo在無法訪問倉庫、或倉庫未初始化notary 元數(shù)據(jù)缺失時(shí)返回的錯誤信息No signatures or cannot access %scommon.go。相關(guān)的 offline / uninitialized 場景均有單元測試覆蓋inspect_test.go。情況 B標(biāo)簽本身未簽名但同一倉庫的其他標(biāo)簽已簽名。此時(shí)docker trust inspect仍會報(bào)告相關(guān)的密鑰信息因?yàn)閭}庫級管理密鑰與委托簽名者信息是存在的只是SignedTags為空$ docker trust inspect alpine:unsigned[ { Name: alpine:unsigned, Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]該行為對應(yīng)測試用例UnsignedTagInSignedRepoinspect_test.gogolden 期望輸出見 trust-inspect-unsigned-tag-with-signers.golden[ { Name: signed-repo:unsigned, SignedTags: [], Signers: [ { Name: bob, Keys: [ { ID: B } ] }, { Name: alice, Keys: [ { ID: A } ] } ], AdministrativeKeys: [ { Name: Root, Keys: [ { ID: rootID } ] }, { Name: Repository, Keys: [ { ID: targetsID } ] } ] } ]注意此時(shí)雖然該 tag 未簽名但倉庫中配置的委托簽名者alice、bob及其密鑰仍會被列出說明這些信息屬于倉庫級別而非某個(gè) tag 級別。實(shí)戰(zhàn)示例四查看倉庫內(nèi)全部已簽名標(biāo)簽不帶 tag 時(shí)docker trust inspect會報(bào)告?zhèn)}庫內(nèi)所有已簽名標(biāo)簽的細(xì)節(jié)$ docker trust inspect alpine[ { Name: alpine, SignedTags: [ { SignedTag: 3.5, Digest: b007a354427e1880de9cdba533e8e57382b7f2853a68a478a17d447b302c219c, Signers: [ Repo Admin ] }, { SignedTag: 3.6, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] }, { SignedTag: edge, Digest: 23e7d843e63a3eee29b6b8cfcd10e23dd1ef28f47251a985606a31040bf8e096, Signers: [ Repo Admin ] }, { SignedTag: latest, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] } ], Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]輸出按 tag 名稱自然排序。可以觀察到3.6與latest指向同一個(gè) digestd6bfc3baf615...即內(nèi)容尋址摘要相同——這正是matchReleasedSignatures以(tag, digest)二元組為鍵聚合簽名者的原因common.go。實(shí)戰(zhàn)示例五一次查詢多個(gè)倉庫/鏡像docker trust inspect接受多個(gè)倉庫與鏡像作為參數(shù)結(jié)果按參數(shù)順序組織為一個(gè)有序列表$ docker trust inspect alpine notary[ { Name: alpine, SignedTags: [ { SignedTag: 3.5, Digest: b007a354427e1880de9cdba533e8e57382b7f2853a68a478a17d447b302c219c, Signers: [ Repo Admin ] }, { SignedTag: 3.6, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] }, { SignedTag: edge, Digest: 23e7d843e63a3eee29b6b8cfcd10e23dd1ef28f47251a985606a31040bf8e096, Signers: [ Repo Admin ] }, { SignedTag: integ-test-base, Digest: 3952dc48dcc4136ccdde37fbef7e250346538a55a0366e3fccc683336377e372, Signers: [ Repo Admin ] }, { SignedTag: latest, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] } ], Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] }, { Name: notary, SignedTags: [ { SignedTag: server, Digest: 71f64ab718a3331dee103bc5afc6bc492914738ce37c2d2f127a8133714ecf5c, Signers: [ Repo Admin ] }, { SignedTag: signer, Digest: a6122d79b1e74f70b5dd933b18a6d1f99329a4728011079f06b245205f158fe8, Signers: [ Repo Admin ] } ], Signers: [], AdministrativeKeys: [ { Name: Root, Keys: [ { ID: 8cdcdef5bd039f4ab5a029126951b5985eebf57cabdcdc4d21f5b3be8bb4ce92 } ] }, { Name: Repository, Keys: [ { ID: 85bfd031017722f950d480a721f845a2944db26a3dc084040a70f1b0d9bbb3df } ] } ] } ]從源碼看多對象場景由通用inspect.Inspect循環(huán)調(diào)用getRef完成inspector.go任一對象出錯時(shí)錯誤信息會被收集最終以StatusError形式返回。測試用例MultipleFullReposWithSigners也驗(yàn)證了多倉庫順序輸出inspect_test.go。--pretty 模式人類可讀輸出默認(rèn) JSON 之外--pretty選項(xiàng)可將輸出轉(zhuǎn)為更易讀的表格形式。單個(gè)標(biāo)簽$ docker trust inspect --pretty alpine:latest SIGNED TAG DIGEST SIGNERS latest 1072e499f3f655a032e88542330cf75b02e7bdf673278f701d7ba61629ee3ebe (Repo Admin) Administrative keys for alpine:latest: Repository Key: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd Root Key: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce表格三列的含義SIGNED TAG已簽名的鏡像標(biāo)簽名DIGEST該標(biāo)簽唯一的內(nèi)容尋址摘要content-addressable digestSIGNERS所有對該標(biāo)簽簽名的實(shí)體列表。僅由targets/targets/releases簽名的標(biāo)簽顯示為(Repo Admin)括號即表示這是倉庫管理員級別的簽名見 inspect_pretty.go。Administrative keys列出的管理密鑰分別指定了信任根密鑰Root Key與倉庫管理密鑰Repository Key它們是修改簽名者列表與對已簽名倉庫做密鑰輪換的權(quán)威密鑰。表格格式化邏輯在 formatter.go 中定義表頭依次為SIGNED TAG、DIGEST、SIGNERS。帶委托簽名者的倉庫--pretty$ docker trust inspect --pretty my-image:purple SIGNED TAG DIGEST SIGNERS purple 941d3dba358621ce3c41ef67b47cf80f701ff80cdf46b5cc86587eaebfe45557 alice, bob, carol List of signers and their keys: SIGNER KEYS alice 47caae5b3e61, a85aab9d20a4 bob 034370bcbd77, 82a66673242c carol b6f9f8e1aab0 Administrative keys for my-image: Repository Key: 27df2c8187e7543345c2e0bf3a1262e0bc63a72754e9a7395eac3f747ec23a44 Root Key: 40b66ccc8b176be8c7d365a17f3e046d1c3494e053dd57cfeacfe2e19c4f8e8f當(dāng)倉庫配置了委托簽名者時(shí)--pretty會額外輸出List of signers and their keys區(qū)塊展示每個(gè)SIGNER及其KEYS。注意 pretty 模式下密鑰 ID 被截?cái)酁?12 位短 ID源碼中printSignerInfo使用Trunc: true配合stringid.TruncateID見 formatter.go而 JSON 模式輸出完整 ID——這一點(diǎn)在實(shí)際排查時(shí)需注意區(qū)分。未簽名標(biāo)簽--pretty$ docker trust inspect --pretty alpine:unsigned No signatures for alpine:unsigned Administrative keys for alpine:unsigned: Repository Key: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd Root Key: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce此時(shí)沒有SIGNED TAG表格而是直接提示No signatures for repo隨后仍然列出管理密鑰。對應(yīng)的 golden 期望輸出見 trust-inspect-pretty-unsigned-tag-with-signers.goldenNo signatures for signed-repo:unsigned List of signers and their keys for signed-repo:unsigned SIGNER KEYS alice A bob B Administrative keys for signed-repo:unsigned Repository Key: targetsID Root Key: rootID如果倉庫中其他標(biāo)簽已簽名--pretty模式同樣會報(bào)告相關(guān)的密鑰信息。倉庫全部標(biāo)簽--pretty$ docker trust inspect --pretty alpine SIGNED TAG DIGEST SIGNERS 2.6 9ace551613070689a12857d62c30ef0daa9a376107ec0fff0e34786cedb3399b (Repo Admin) 2.7 9f08005dff552038f0ad2f46b8e65ff3d25641747d3912e3ea8da6785046561a (Repo Admin) 3.1 d9477888b78e8c6392e0be8b2e73f8c67e2894ff9d4b8e467d1488fcceec21c8 (Repo Admin) 3.2 19826d59171c2eb7e90ce52bfd822993bef6a6fe3ae6bb4a49f8c1d0a01e99c7 (Repo Admin) 3.3 8fd4b76819e1e5baac82bd0a3d03abfe3906e034cc5ee32100d12aaaf3956dc7 (Repo Admin) 3.4 833ad81ace8277324f3ca8c91c02bdcf1d13988d8ecf8a3f97ecdd69d0390ce9 (Repo Admin) 3.5 af2a5bd2f8de8fc1ecabf1c76611cdc6a5f1ada1a2bdd7d3816e121b70300308 (Repo Admin) 3.6 1072e499f3f655a032e88542330cf75b02e7bdf673278f701d7ba61629ee3ebe (Repo Admin) edge 79d50d15bd7ea48ea00cf3dd343b0e740c1afaa8e899bee475236ef338e1b53b (Repo Admin) latest 1072e499f3f655a032e88542330cf75b02e7bdf673278f701d7ba61629ee3ebe (Repo Admin) Administrative keys for alpine: Repository Key: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd Root Key: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce帶委托簽名者的多標(biāo)簽倉庫--pretty$ docker trust inspect --pretty my-image SIGNED TAG DIGEST SIGNERS red 852cc04935f930a857b630edc4ed6131e91b22073bcc216698842e44f64d2943 alice blue f1c38dbaeeb473c36716f6494d803fbfbe9d8a76916f7c0093f227821e378197 alice, bob green cae8fedc840f90c8057e1c24637d11865743ab1e61a972c1c9da06ec2de9a139 alice, bob yellow 9cc65fc3126790e683d1b92f307a71f48f75fa7dd47a7b03145a123eaf0b45ba carol purple 941d3dba358621ce3c41ef67b47cf80f701ff80cdf46b5cc86587eaebfe45557 alice, bob, carol orange d6c271baa6d271bcc24ef1cbd65abf39123c17d2e83455bdab545a1a9093fc1c alice List of signers and their keys for my-image: SIGNER KEYS alice 47caae5b3e61, a85aab9d20a4 bob 034370bcbd77, 82a66673242c carol b6f9f8e1aab0 Administrative keys for my-image: Repository Key: 27df2c8187e7543345c2e0bf3a1262e0bc63a72754e9a7395eac3f747ec23a44 Root Key: 40b66ccc8b176be8c7d365a17f3e046d1c3494e053dd57cfeacfe2e19c4f8e8f這個(gè)示例最直觀地展示了委托簽名機(jī)制的實(shí)際效果同一個(gè)倉庫內(nèi)不同標(biāo)簽的簽名者組合各不相同——red僅由alice簽名blue/green由alice與bob共同簽名yellow由carol簽名purple則需要全部三位簽名者。這正是多簽名者協(xié)作發(fā)布流程可通過 docker trust sign 觸發(fā)的可視化呈現(xiàn)。常見錯誤信息與排查建議基于底層NotaryError的錯誤分類邏輯trust.go以及l(fā)ookupTrustInfo的錯誤處理常見報(bào)錯及其含義如下錯誤信息觸發(fā)場景與建議No signatures or cannot access remote倉庫無法訪問、未在 Notary 初始化、或離線。檢查網(wǎng)絡(luò)與DOCKER_CONTENT_TRUST_SERVER配置僅接受 https URL確認(rèn)倉庫確實(shí)啟用過內(nèi)容信任requires at least 1 argument未提供任何IMAGE[:TAG]參數(shù)invalid reference format/invalid repository name鏡像引用語法非法如全大寫倉庫名或直接傳 SHA 摘要摘要需通過IMAGEsha256:...形式給出No signers for remoteListRoles失敗無法獲取管理角色信息Error: no trust data available for remote repository ...收到非法 JSONjson.SyntaxError通常意味著該倉庫根本沒有信任數(shù)據(jù)建議確認(rèn)倉庫地址與 Notary 服務(wù)器配置Error: remote repository repo out-of-date: ...信任元數(shù)據(jù)過期signed.ErrExpired需要擁有相應(yīng)密鑰的簽名者重新簽名發(fā)布需要說明的是docker trust inspect是一個(gè)只讀查詢命令以ActionsPullOnly即pull權(quán)限訪問 Notary它不會修改任何信任數(shù)據(jù)所有寫入類操作簽名、增刪簽名者、吊銷、生成/加載密鑰分別由 docker trust sign、docker trust signer add、docker trust signer remove、docker trust revoke、docker trust key generate 與 docker trust key load 承擔(dān)。同時(shí)docker trust inspect的查詢結(jié)果與docker pull/docker push在DOCKER_CONTENT_TRUST1時(shí)校驗(yàn)簽名所依賴的信任數(shù)據(jù)TUF 元數(shù)據(jù)、密鑰、委托角色來自同一套 Notary 數(shù)據(jù)源因此它也是排查為什么某個(gè)鏡像 pull 時(shí)無法通過信任校驗(yàn)的第一現(xiàn)場?？偨Y(jié)docker trust inspect是 Docker Content Trust 生態(tài)中面向?qū)徲?jì)與排障的核心只讀命令JSON 模式輸出機(jī)器可讀的完整信任狀態(tài)SignedTags聚合已發(fā)布標(biāo)簽及其簽名者Signers羅列委托簽名者與密鑰 IDAdministrativeKeys給出Repository與Root兩級管理密鑰--pretty模式以表格呈現(xiàn)同一信息密鑰 ID 截?cái)酁槎?ID適合人工快速瀏覽底層原理依托 Notary 客戶端lookupTrustInfo通過GetAllTargetMetadataByName獲取全部 targets 元數(shù)據(jù)以(tag, digest)為鍵、以是否進(jìn)入targets/targets/releases角色判定已發(fā)布再聚合委托角色的簽名者名單源碼見 common.go、inspect.go、inspect_pretty.go。掌握docker trust inspect即可隨時(shí)查看誰簽了哪些標(biāo)簽、用什么密鑰簽的、哪些實(shí)體有權(quán)繼續(xù)簽名為鏡像供應(yīng)鏈的可信審計(jì)提供最直接的事實(shí)依據(jù)。贊分享容器運(yùn)行時(shí)云原生【免費(fèi)下載鏈接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:項(xiàng)目地址https://gitcode.com/gh_mirrors/do/docker-ce點(diǎn)擊查看免費(fèi)下載相關(guān)推薦docker trust key load 命令詳解導(dǎo)入簽名私鑰到 Docker 信任密鑰庫docker trust key load 命令詳解導(dǎo)入簽名私鑰到 Docker 信任密鑰庫 導(dǎo)讀 docker trust key load 是 Docke容器運(yùn)行時(shí)云原生Docker CLI docker trust 內(nèi)容信任完全指南鏡像簽名、密鑰管理與簽名者協(xié)作Docker CLI docker trust 內(nèi)容信任完全指南鏡像簽名、密鑰管理與簽名者協(xié)作 docker trust 是 Docker CLI 中用于鏡像CLI開發(fā)工具Docker鏡像元數(shù)據(jù)查詢終極指南docker inspect命令詳解與實(shí)戰(zhàn)Docker鏡像元數(shù)據(jù)查詢終極指南docker inspect命令詳解與實(shí)戰(zhàn) 想要深入了解Docker鏡像的詳細(xì)信息嗎 docker inspect 命令是云原生開發(fā)工具數(shù)據(jù)科學(xué)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考