容器運行時云原生【免費下載鏈接】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:項目地址https://gitcode.com/gh_mirrors/do/docker-ce點擊查看免費下載導讀docker trust inspect是 Docker Content Trust內容信任體系中用于只讀查詢鏡像倉庫簽名與密鑰信息的核心命令。它以 JSON默認或人類可讀表格--pretty兩種格式輸出指定鏡像倉庫中所有已簽名標簽的摘要、簽名者名單、委托簽名者及其密鑰 ID、倉庫 Root 與 Repository 管理密鑰是安全團隊審計鏡像供應鏈、開發(fā)者排查簽名問題最直接的診斷工具。本文基于 docker-ce 倉庫中該命令的官方文檔與完整源碼實現(xiàn)系統(tǒng)講解其用法、JSON 與表格輸出語義、底層數(shù)據(jù)流與常見錯誤處理助你徹底掌握docker trust inspect的使用與原理。命令概覽用法與選項docker trust inspect屬于 Docker CLI 的docker trust命令族負責返回關于密鑰與簽名的低層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關鍵點參數(shù)至少需要 1 個IMAGE[:TAG]。從源碼看命令通過cli.RequiresMinArgs(1)強制至少一個參數(shù)不提供參數(shù)會直接報錯requires at least 1 argument見 inspect.go 與對應測試 inspect_test.go。--pretty以人類友好的表格格式輸出取代默認的 JSON。prettyPrint布爾標志定義在 inspect.go。--help打印用法說明。在 cmd.go 中可以看到inspect與revoke、sign、key、signer一起注冊為docker trust的子命令屬于Manage trust on Docker images信任管理體系的一部分。命令用途說明docker trust inspect為已簽名的倉庫提供低層 JSON 信息包括所有已簽名的鏡像標簽tags這些標簽由誰簽名signers哪些實體可以為新標簽簽名即通過docker trust signer add配置的委托簽名者。在默認 JSON 輸出中數(shù)據(jù)按trustRepo結構序列化其字段在源碼 common.go 中定義JSON 字段含義Name被查詢的鏡像倉庫名含 tag 時原樣保留SignedTags已簽名標簽列表每個包含SignedTag標簽名、Digest內容尋址摘要、Signers簽名者列表Signers倉庫配置的委托簽名者及其密鑰 ID 列表未配置時為空數(shù)組AdministrativeKeys管理密鑰Repository倉庫 targets 密鑰與Root信任根密鑰底層實現(xiàn)inspect 命令的數(shù)據(jù)流與原理為了真正理解docker trust inspect輸出中每個字段的來源我們需要進入其源碼實現(xiàn)。命令的核心數(shù)據(jù)獲取函數(shù)是lookupTrustInfocommon.go整個數(shù)據(jù)流如下1. 解析鏡像引用與鑒權信息imgRefAndAuth, err : trust.GetImageReferencesAndAuth(ctx, nil, image.AuthResolver(cli), remote)這一步通過 cli/trust/trust.go 中的GetImageReferencesAndAuth完成調用reference.ParseNormalizedNamed解析IMAGE[:TAG]并將倉庫名解析為RepositoryInfo同時解析出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會構造帶鑒權的 HTTP 傳輸層先是GET server/v2/的 ping 探測用于解析 Registry/Notary 的 challenge 鑒權方式再根據(jù)倉庫 Index 信息決定信任服務器地址——官方鏡像默認使用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若目標不存在client.ErrNoSuchTarget則返回空表。4. 匹配已發(fā)布簽名signatureRows : matchReleasedSignatures(allSignedTargets)matchReleasedSignaturescommon.go是輸出語義的關鍵只有被簽名進入targets或targets/releases這兩個released角色的標簽才會被列入SignedTags其他所有為同一(tag, digest)組合簽名的委托角色如targets/alice都會被計入該標簽的Signers若某標簽僅由targets/targets/releases簽名沒有額外委托簽名者Signers為空之后在輸出階段統(tǒng)一顯示為Repo Admin輸出按標簽名做自然排序natural sort。這一是否 released的判斷在isReleasedTargethelpers.go中定義而 TUF 角色名到人類可讀簽名者名的轉換由notaryRoleToSignerhelpers.go完成——即去掉targets/前綴targets與targets/releases顯示為Repo Admin。相關的單元測試見 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等基礎角色只保留真正的委托簽名者見getDelegationRoleToKeyMapcommon.go。6. 兩條輸出路徑runInspectinspect.go按--pretty是否開啟分叉默認 JSON 路徑將getRepoTrustInfo得到的trustRepo結構交給通用inspect.Inspectinspector.go最終經(jīng)IndentedInspector以 4 空格縮進的 JSON 數(shù)組輸出。--pretty路徑調用prettyPrintTrustInfoinspect_pretty.go按區(qū)塊輸出Signatures for repo、List of signers and their keys for repo僅存在委托簽名者時、Administrative keys for repo三部分表格。多鏡像查詢時pretty 模式會在每個倉庫輸出之間插入空行作為分隔inspect.go。實戰(zhàn)示例一查看單個鏡像標簽的簽名細節(jié)查詢單個鏡像標簽的信任信息直接傳入IMAGE[:TAG]即可$ docker trust inspect alpine:latest默認輸出為 JSON 數(shù)組每個被查詢對象對應數(shù)組中的一個元素例如[ { Name: alpine:latest, SignedTags: [ { SignedTag: latest, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] } ], Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]字段解讀SignedTags中的每一項列出SignedTag已簽名標簽名、其Digest唯一的內容尋址摘要以及為該簽名負責的Signers。此處僅有Repo Admin表示該標簽由倉庫的targets/targets/releases角色簽名沒有額外的委托簽名者。AdministrativeKeys列出Repository與Root兩個管理密鑰Root是信任鏈的根密鑰Repository是倉庫級管理密鑰兩者共同負責修改簽名者signers以及為已簽名倉庫做密鑰輪換key rotation。Signers為空數(shù)組表示該倉庫尚未通過docker trust signer add配置額外的委托簽名者。實戰(zhàn)示例二帶委托簽名者的倉庫當倉庫通過其他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標簽由alice、bob、carol三個委托簽名者共同簽名Signers區(qū)塊列出每個簽名者對應的密鑰 ID同一簽名者可持有多個密鑰對應 TUF 委托角色targets/alice等的 KeyIDs。這些 ID 在源碼中取自委托角色的KeyIDs字段見 inspect.go并按名稱排序輸出。實戰(zhàn)示例三未簽名標簽的行為差異情況 A倉庫本身沒有簽名數(shù)據(jù)或鏡像不可訪問。此時docker trust inspect不會顯示任何簽名標簽而是直接報錯$ docker trust inspect unsigned-img No signatures or cannot access unsigned-img這正是源碼中l(wèi)ookupTrustInfo在無法訪問倉庫、或倉庫未初始化notary 元數(shù)據(jù)缺失時返回的錯誤信息No signatures or cannot access %scommon.go。相關的 offline / uninitialized 場景均有單元測試覆蓋inspect_test.go。情況 B標簽本身未簽名但同一倉庫的其他標簽已簽名。此時docker trust inspect仍會報告相關的密鑰信息因為倉庫級管理密鑰與委托簽名者信息是存在的只是SignedTags為空$ docker trust inspect alpine:unsigned[ { Name: alpine:unsigned, Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]該行為對應測試用例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 } ] } ] } ]注意此時雖然該 tag 未簽名但倉庫中配置的委托簽名者alice、bob及其密鑰仍會被列出說明這些信息屬于倉庫級別而非某個 tag 級別。實戰(zhàn)示例四查看倉庫內全部已簽名標簽不帶 tag 時docker trust inspect會報告?zhèn)}庫內所有已簽名標簽的細節(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指向同一個 digestd6bfc3baf615...即內容尋址摘要相同——這正是matchReleasedSignatures以(tag, digest)二元組為鍵聚合簽名者的原因common.go。實戰(zhàn)示例五一次查詢多個倉庫/鏡像docker trust inspect接受多個倉庫與鏡像作為參數(shù)結果按參數(shù)順序組織為一個有序列表$ 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)調用getRef完成inspector.go任一對象出錯時錯誤信息會被收集最終以StatusError形式返回。測試用例MultipleFullReposWithSigners也驗證了多倉庫順序輸出inspect_test.go。--pretty 模式人類可讀輸出默認 JSON 之外--pretty選項可將輸出轉為更易讀的表格形式。單個標簽$ 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已簽名的鏡像標簽名DIGEST該標簽唯一的內容尋址摘要content-addressable digestSIGNERS所有對該標簽簽名的實體列表。僅由targets/targets/releases簽名的標簽顯示為(Repo Admin)括號即表示這是倉庫管理員級別的簽名見 inspect_pretty.go。Administrative keys列出的管理密鑰分別指定了信任根密鑰Root Key與倉庫管理密鑰Repository Key它們是修改簽名者列表與對已簽名倉庫做密鑰輪換的權威密鑰。表格格式化邏輯在 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當倉庫配置了委托簽名者時--pretty會額外輸出List of signers and their keys區(qū)塊展示每個SIGNER及其KEYS。注意 pretty 模式下密鑰 ID 被截斷為 12 位短 ID源碼中printSignerInfo使用Trunc: true配合stringid.TruncateID見 formatter.go而 JSON 模式輸出完整 ID——這一點在實際排查時需注意區(qū)分。未簽名標簽--pretty$ docker trust inspect --pretty alpine:unsigned No signatures for alpine:unsigned Administrative keys for alpine:unsigned: Repository Key: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd Root Key: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce此時沒有SIGNED TAG表格而是直接提示No signatures for repo隨后仍然列出管理密鑰。對應的 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如果倉庫中其他標簽已簽名--pretty模式同樣會報告相關的密鑰信息。倉庫全部標簽--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帶委托簽名者的多標簽倉庫--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這個示例最直觀地展示了委托簽名機制的實際效果同一個倉庫內不同標簽的簽名者組合各不相同——red僅由alice簽名blue/green由alice與bob共同簽名yellow由carol簽名purple則需要全部三位簽名者。這正是多簽名者協(xié)作發(fā)布流程可通過 docker trust sign 觸發(fā)的可視化呈現(xiàn)。常見錯誤信息與排查建議基于底層NotaryError的錯誤分類邏輯trust.go以及l(fā)ookupTrustInfo的錯誤處理常見報錯及其含義如下錯誤信息觸發(fā)場景與建議No signatures or cannot access remote倉庫無法訪問、未在 Notary 初始化、或離線。檢查網(wǎng)絡與DOCKER_CONTENT_TRUST_SERVER配置僅接受 https URL確認倉庫確實啟用過內容信任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ù)建議確認倉庫地址與 Notary 服務器配置Error: remote repository repo out-of-date: ...信任元數(shù)據(jù)過期signed.ErrExpired需要擁有相應密鑰的簽名者重新簽名發(fā)布需要說明的是docker trust inspect是一個只讀查詢命令以ActionsPullOnly即pull權限訪問 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 承擔。同時docker trust inspect的查詢結果與docker pull/docker push在DOCKER_CONTENT_TRUST1時校驗簽名所依賴的信任數(shù)據(jù)TUF 元數(shù)據(jù)、密鑰、委托角色來自同一套 Notary 數(shù)據(jù)源因此它也是排查為什么某個鏡像 pull 時無法通過信任校驗的第一現(xiàn)場?？偨Ydocker trust inspect是 Docker Content Trust 生態(tài)中面向審計與排障的核心只讀命令JSON 模式輸出機器可讀的完整信任狀態(tài)SignedTags聚合已發(fā)布標簽及其簽名者Signers羅列委托簽名者與密鑰 IDAdministrativeKeys給出Repository與Root兩級管理密鑰--pretty模式以表格呈現(xiàn)同一信息密鑰 ID 截斷為短 ID適合人工快速瀏覽底層原理依托 Notary 客戶端lookupTrustInfo通過GetAllTargetMetadataByName獲取全部 targets 元數(shù)據(jù)以(tag, digest)為鍵、以是否進入targets/targets/releases角色判定已發(fā)布再聚合委托角色的簽名者名單源碼見 common.go、inspect.go、inspect_pretty.go。掌握docker trust inspect即可隨時查看誰簽了哪些標簽、用什么密鑰簽的、哪些實體有權繼續(xù)簽名為鏡像供應鏈的可信審計提供最直接的事實依據(jù)。贊分享容器運行時云原生【免費下載鏈接】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:項目地址https://gitcode.com/gh_mirrors/do/docker-ce點擊查看免費下載相關推薦docker trust key load 命令詳解導入簽名私鑰到 Docker 信任密鑰庫docker trust key load 命令詳解導入簽名私鑰到 Docker 信任密鑰庫 導讀 docker trust key load 是 Docke容器運行時云原生Docker CLI docker trust 內容信任完全指南鏡像簽名、密鑰管理與簽名者協(xié)作Docker CLI docker trust 內容信任完全指南鏡像簽名、密鑰管理與簽名者協(xié)作 docker trust 是 Docker CLI 中用于鏡像CLI開發(fā)工具Docker鏡像元數(shù)據(jù)查詢終極指南docker inspect命令詳解與實戰(zhàn)Docker鏡像元數(shù)據(jù)查詢終極指南docker inspect命令詳解與實戰(zhàn) 想要深入了解Docker鏡像的詳細信息嗎 docker inspect 命令是云原生開發(fā)工具數(shù)據(jù)科學創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 docker trust inspect 命令詳解：全面掌握 Docker 鏡像簽名與密鑰信息查詢
容器運行時云原生【免費下載鏈接】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:項目地址https://gitcode.com/gh_mirrors/do/docker-ce點擊查看免費下載導讀docker trust inspect是 Docker Content Trust內容信任體系中用于只讀查詢鏡像倉庫簽名與密鑰信息的核心命令。它以 JSON默認或人類可讀表格--pretty兩種格式輸出指定鏡像倉庫中所有已簽名標簽的摘要、簽名者名單、委托簽名者及其密鑰 ID、倉庫 Root 與 Repository 管理密鑰是安全團隊審計鏡像供應鏈、開發(fā)者排查簽名問題最直接的診斷工具。本文基于 docker-ce 倉庫中該命令的官方文檔與完整源碼實現(xiàn)系統(tǒng)講解其用法、JSON 與表格輸出語義、底層數(shù)據(jù)流與常見錯誤處理助你徹底掌握docker trust inspect的使用與原理。命令概覽用法與選項docker trust inspect屬于 Docker CLI 的docker trust命令族負責返回關于密鑰與簽名的低層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關鍵點參數(shù)至少需要 1 個IMAGE[:TAG]。從源碼看命令通過cli.RequiresMinArgs(1)強制至少一個參數(shù)不提供參數(shù)會直接報錯requires at least 1 argument見 inspect.go 與對應測試 inspect_test.go。--pretty以人類友好的表格格式輸出取代默認的 JSON。prettyPrint布爾標志定義在 inspect.go。--help打印用法說明。在 cmd.go 中可以看到inspect與revoke、sign、key、signer一起注冊為docker trust的子命令屬于Manage trust on Docker images信任管理體系的一部分。命令用途說明docker trust inspect為已簽名的倉庫提供低層 JSON 信息包括所有已簽名的鏡像標簽tags這些標簽由誰簽名signers哪些實體可以為新標簽簽名即通過docker trust signer add配置的委托簽名者。在默認 JSON 輸出中數(shù)據(jù)按trustRepo結構序列化其字段在源碼 common.go 中定義JSON 字段含義Name被查詢的鏡像倉庫名含 tag 時原樣保留SignedTags已簽名標簽列表每個包含SignedTag標簽名、Digest內容尋址摘要、Signers簽名者列表Signers倉庫配置的委托簽名者及其密鑰 ID 列表未配置時為空數(shù)組AdministrativeKeys管理密鑰Repository倉庫 targets 密鑰與Root信任根密鑰底層實現(xiàn)inspect 命令的數(shù)據(jù)流與原理為了真正理解docker trust inspect輸出中每個字段的來源我們需要進入其源碼實現(xiàn)。命令的核心數(shù)據(jù)獲取函數(shù)是lookupTrustInfocommon.go整個數(shù)據(jù)流如下1. 解析鏡像引用與鑒權信息imgRefAndAuth, err : trust.GetImageReferencesAndAuth(ctx, nil, image.AuthResolver(cli), remote)這一步通過 cli/trust/trust.go 中的GetImageReferencesAndAuth完成調用reference.ParseNormalizedNamed解析IMAGE[:TAG]并將倉庫名解析為RepositoryInfo同時解析出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會構造帶鑒權的 HTTP 傳輸層先是GET server/v2/的 ping 探測用于解析 Registry/Notary 的 challenge 鑒權方式再根據(jù)倉庫 Index 信息決定信任服務器地址——官方鏡像默認使用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若目標不存在client.ErrNoSuchTarget則返回空表。4. 匹配已發(fā)布簽名signatureRows : matchReleasedSignatures(allSignedTargets)matchReleasedSignaturescommon.go是輸出語義的關鍵只有被簽名進入targets或targets/releases這兩個released角色的標簽才會被列入SignedTags其他所有為同一(tag, digest)組合簽名的委托角色如targets/alice都會被計入該標簽的Signers若某標簽僅由targets/targets/releases簽名沒有額外委托簽名者Signers為空之后在輸出階段統(tǒng)一顯示為Repo Admin輸出按標簽名做自然排序natural sort。這一是否 released的判斷在isReleasedTargethelpers.go中定義而 TUF 角色名到人類可讀簽名者名的轉換由notaryRoleToSignerhelpers.go完成——即去掉targets/前綴targets與targets/releases顯示為Repo Admin。相關的單元測試見 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等基礎角色只保留真正的委托簽名者見getDelegationRoleToKeyMapcommon.go。6. 兩條輸出路徑runInspectinspect.go按--pretty是否開啟分叉默認 JSON 路徑將getRepoTrustInfo得到的trustRepo結構交給通用inspect.Inspectinspector.go最終經(jīng)IndentedInspector以 4 空格縮進的 JSON 數(shù)組輸出。--pretty路徑調用prettyPrintTrustInfoinspect_pretty.go按區(qū)塊輸出Signatures for repo、List of signers and their keys for repo僅存在委托簽名者時、Administrative keys for repo三部分表格。多鏡像查詢時pretty 模式會在每個倉庫輸出之間插入空行作為分隔inspect.go。實戰(zhàn)示例一查看單個鏡像標簽的簽名細節(jié)查詢單個鏡像標簽的信任信息直接傳入IMAGE[:TAG]即可$ docker trust inspect alpine:latest默認輸出為 JSON 數(shù)組每個被查詢對象對應數(shù)組中的一個元素例如[ { Name: alpine:latest, SignedTags: [ { SignedTag: latest, Digest: d6bfc3baf615dc9618209a8d607ba2a8103d9c8a405b3bd8741d88b4bef36478, Signers: [ Repo Admin ] } ], Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]字段解讀SignedTags中的每一項列出SignedTag已簽名標簽名、其Digest唯一的內容尋址摘要以及為該簽名負責的Signers。此處僅有Repo Admin表示該標簽由倉庫的targets/targets/releases角色簽名沒有額外的委托簽名者。AdministrativeKeys列出Repository與Root兩個管理密鑰Root是信任鏈的根密鑰Repository是倉庫級管理密鑰兩者共同負責修改簽名者signers以及為已簽名倉庫做密鑰輪換key rotation。Signers為空數(shù)組表示該倉庫尚未通過docker trust signer add配置額外的委托簽名者。實戰(zhàn)示例二帶委托簽名者的倉庫當倉庫通過其他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標簽由alice、bob、carol三個委托簽名者共同簽名Signers區(qū)塊列出每個簽名者對應的密鑰 ID同一簽名者可持有多個密鑰對應 TUF 委托角色targets/alice等的 KeyIDs。這些 ID 在源碼中取自委托角色的KeyIDs字段見 inspect.go并按名稱排序輸出。實戰(zhàn)示例三未簽名標簽的行為差異情況 A倉庫本身沒有簽名數(shù)據(jù)或鏡像不可訪問。此時docker trust inspect不會顯示任何簽名標簽而是直接報錯$ docker trust inspect unsigned-img No signatures or cannot access unsigned-img這正是源碼中l(wèi)ookupTrustInfo在無法訪問倉庫、或倉庫未初始化notary 元數(shù)據(jù)缺失時返回的錯誤信息No signatures or cannot access %scommon.go。相關的 offline / uninitialized 場景均有單元測試覆蓋inspect_test.go。情況 B標簽本身未簽名但同一倉庫的其他標簽已簽名。此時docker trust inspect仍會報告相關的密鑰信息因為倉庫級管理密鑰與委托簽名者信息是存在的只是SignedTags為空$ docker trust inspect alpine:unsigned[ { Name: alpine:unsigned, Signers: [], AdministrativeKeys: [ { Name: Repository, Keys: [ { ID: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd } ] }, { Name: Root, Keys: [ { ID: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce } ] } ] } ]該行為對應測試用例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 } ] } ] } ]注意此時雖然該 tag 未簽名但倉庫中配置的委托簽名者alice、bob及其密鑰仍會被列出說明這些信息屬于倉庫級別而非某個 tag 級別。實戰(zhàn)示例四查看倉庫內全部已簽名標簽不帶 tag 時docker trust inspect會報告?zhèn)}庫內所有已簽名標簽的細節(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指向同一個 digestd6bfc3baf615...即內容尋址摘要相同——這正是matchReleasedSignatures以(tag, digest)二元組為鍵聚合簽名者的原因common.go。實戰(zhàn)示例五一次查詢多個倉庫/鏡像docker trust inspect接受多個倉庫與鏡像作為參數(shù)結果按參數(shù)順序組織為一個有序列表$ 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)調用getRef完成inspector.go任一對象出錯時錯誤信息會被收集最終以StatusError形式返回。測試用例MultipleFullReposWithSigners也驗證了多倉庫順序輸出inspect_test.go。--pretty 模式人類可讀輸出默認 JSON 之外--pretty選項可將輸出轉為更易讀的表格形式。單個標簽$ 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已簽名的鏡像標簽名DIGEST該標簽唯一的內容尋址摘要content-addressable digestSIGNERS所有對該標簽簽名的實體列表。僅由targets/targets/releases簽名的標簽顯示為(Repo Admin)括號即表示這是倉庫管理員級別的簽名見 inspect_pretty.go。Administrative keys列出的管理密鑰分別指定了信任根密鑰Root Key與倉庫管理密鑰Repository Key它們是修改簽名者列表與對已簽名倉庫做密鑰輪換的權威密鑰。表格格式化邏輯在 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當倉庫配置了委托簽名者時--pretty會額外輸出List of signers and their keys區(qū)塊展示每個SIGNER及其KEYS。注意 pretty 模式下密鑰 ID 被截斷為 12 位短 ID源碼中printSignerInfo使用Trunc: true配合stringid.TruncateID見 formatter.go而 JSON 模式輸出完整 ID——這一點在實際排查時需注意區(qū)分。未簽名標簽--pretty$ docker trust inspect --pretty alpine:unsigned No signatures for alpine:unsigned Administrative keys for alpine:unsigned: Repository Key: 5a46c9aaa82ff150bb7305a2d17d0c521c2d784246807b2dc611f436a69041fd Root Key: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce此時沒有SIGNED TAG表格而是直接提示No signatures for repo隨后仍然列出管理密鑰。對應的 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如果倉庫中其他標簽已簽名--pretty模式同樣會報告相關的密鑰信息。倉庫全部標簽--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帶委托簽名者的多標簽倉庫--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這個示例最直觀地展示了委托簽名機制的實際效果同一個倉庫內不同標簽的簽名者組合各不相同——red僅由alice簽名blue/green由alice與bob共同簽名yellow由carol簽名purple則需要全部三位簽名者。這正是多簽名者協(xié)作發(fā)布流程可通過 docker trust sign 觸發(fā)的可視化呈現(xiàn)。常見錯誤信息與排查建議基于底層NotaryError的錯誤分類邏輯trust.go以及l(fā)ookupTrustInfo的錯誤處理常見報錯及其含義如下錯誤信息觸發(fā)場景與建議No signatures or cannot access remote倉庫無法訪問、未在 Notary 初始化、或離線。檢查網(wǎng)絡與DOCKER_CONTENT_TRUST_SERVER配置僅接受 https URL確認倉庫確實啟用過內容信任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ù)建議確認倉庫地址與 Notary 服務器配置Error: remote repository repo out-of-date: ...信任元數(shù)據(jù)過期signed.ErrExpired需要擁有相應密鑰的簽名者重新簽名發(fā)布需要說明的是docker trust inspect是一個只讀查詢命令以ActionsPullOnly即pull權限訪問 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 承擔。同時docker trust inspect的查詢結果與docker pull/docker push在DOCKER_CONTENT_TRUST1時校驗簽名所依賴的信任數(shù)據(jù)TUF 元數(shù)據(jù)、密鑰、委托角色來自同一套 Notary 數(shù)據(jù)源因此它也是排查為什么某個鏡像 pull 時無法通過信任校驗的第一現(xiàn)場?？偨Ydocker trust inspect是 Docker Content Trust 生態(tài)中面向審計與排障的核心只讀命令JSON 模式輸出機器可讀的完整信任狀態(tài)SignedTags聚合已發(fā)布標簽及其簽名者Signers羅列委托簽名者與密鑰 IDAdministrativeKeys給出Repository與Root兩級管理密鑰--pretty模式以表格呈現(xiàn)同一信息密鑰 ID 截斷為短 ID適合人工快速瀏覽底層原理依托 Notary 客戶端lookupTrustInfo通過GetAllTargetMetadataByName獲取全部 targets 元數(shù)據(jù)以(tag, digest)為鍵、以是否進入targets/targets/releases角色判定已發(fā)布再聚合委托角色的簽名者名單源碼見 common.go、inspect.go、inspect_pretty.go。掌握docker trust inspect即可隨時查看誰簽了哪些標簽、用什么密鑰簽的、哪些實體有權繼續(xù)簽名為鏡像供應鏈的可信審計提供最直接的事實依據(jù)。贊分享容器運行時云原生【免費下載鏈接】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:項目地址https://gitcode.com/gh_mirrors/do/docker-ce點擊查看免費下載相關推薦docker trust key load 命令詳解導入簽名私鑰到 Docker 信任密鑰庫docker trust key load 命令詳解導入簽名私鑰到 Docker 信任密鑰庫 導讀 docker trust key load 是 Docke容器運行時云原生Docker CLI docker trust 內容信任完全指南鏡像簽名、密鑰管理與簽名者協(xié)作Docker CLI docker trust 內容信任完全指南鏡像簽名、密鑰管理與簽名者協(xié)作 docker trust 是 Docker CLI 中用于鏡像CLI開發(fā)工具Docker鏡像元數(shù)據(jù)查詢終極指南docker inspect命令詳解與實戰(zhàn)Docker鏡像元數(shù)據(jù)查詢終極指南docker inspect命令詳解與實戰(zhàn) 想要深入了解Docker鏡像的詳細信息嗎 docker inspect 命令是云原生開發(fā)工具數(shù)據(jù)科學創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考