mirror of https://github.com/docker/docs.git
Updated the existing DTR Trust pages from Notary CLI to DCT CLI
Signed-off-by: ollypom <oppomeroy@gmail.com>
This commit is contained in:
ollypom
parent
3ae9602269
commit
80d2051937
|
|
@ -2195,10 +2195,6 @@ manuals:
|
|||
section:
|
||||
- path: /ee/dtr/user/manage-images/sign-images/
|
||||
title: Sign an image
|
||||
- path: /ee/dtr/user/manage-images/sign-images/delegate-image-signing/
|
||||
title: Delegate image signing
|
||||
- path: /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/
|
||||
title: Manage trusted repositories
|
||||
- path: /ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp/
|
||||
title: Trust with a Remote UCP
|
||||
- sectiontitle: Promotion policies and mirroring
|
||||
|
|
|
|||
|
|
@ -1,179 +0,0 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 23.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 690 250" style="enable-background:new 0 0 690 250;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:#FFFFFF;}
|
||||
.st1{fill-rule:evenodd;clip-rule:evenodd;fill:#FFB463;}
|
||||
.st2{fill:#C0C9CE;}
|
||||
.st3{font-family:'OpenSans';}
|
||||
.st4{font-size:12px;}
|
||||
.st5{fill-rule:evenodd;clip-rule:evenodd;fill:#00B6B5;}
|
||||
.st6{fill-rule:evenodd;clip-rule:evenodd;fill:#445D6E;}
|
||||
.st7{fill-rule:evenodd;clip-rule:evenodd;fill:#C0C9CE;}
|
||||
.st8{fill:#82949E;}
|
||||
.st9{font-size:16px;}
|
||||
.st10{fill-rule:evenodd;clip-rule:evenodd;fill:#E0E4E7;}
|
||||
</style>
|
||||
<rect class="st0" width="690" height="250"/>
|
||||
<title>delegate-image-signing-1</title>
|
||||
<desc>Created with Sketch.</desc>
|
||||
<g id="dtr-diagrams">
|
||||
<g id="delegate-image-signing-1">
|
||||
<g id="all" transform="translate(175.000000, 11.000000)">
|
||||
<g id="Group" transform="translate(171.000000, 0.000000)">
|
||||
<g id="teams">
|
||||
<g id="billing-team" transform="translate(97.000000, 0.000000)">
|
||||
<path id="Shape-Copy" class="st1" d="M34.5,26.5c7.3,0,13.2-5.9,13.2-13.2C47.8,5.9,41.8,0,34.5,0S21.2,5.9,21.2,13.2
|
||||
C21.2,20.6,27.2,26.5,34.5,26.5L34.5,26.5z M34.5,33.1C25.7,33.1,8,37.5,8,46.4V53h53v-6.6C61,37.5,43.3,33.1,34.5,33.1
|
||||
L34.5,33.1z"/>
|
||||
<text transform="matrix(1 0 0 1 0.7998 70)" class="st2 st3 st4">IT ops team</text>
|
||||
</g>
|
||||
<g id="blog-team">
|
||||
<text transform="matrix(1 0 0 1 1.7197 70)" class="st2 st3 st4">QA team</text>
|
||||
<path id="Shape-Copy-2" class="st5" d="M26.5,26.5c7.3,0,13.2-5.9,13.2-13.2C39.8,5.9,33.8,0,26.5,0S13.2,5.9,13.2,13.2
|
||||
C13.2,20.6,19.2,26.5,26.5,26.5L26.5,26.5z M26.5,33.1C17.7,33.1,0,37.5,0,46.4V53h53v-6.6C53,37.5,35.3,33.1,26.5,33.1
|
||||
L26.5,33.1z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="permissions" transform="translate(160.000000, 101.000000)">
|
||||
<g transform="translate(105.000000, 84.000000)">
|
||||
<path id="settings" class="st6" d="M75,11.3V8.7C73.6,8.2,72.8,8,72.3,7v0c-0.4-1.1,0.1-1.8,0.7-3.1L71.1,2
|
||||
c-1.3,0.6-2,1.1-3.1,0.7h0C67,2.2,66.8,1.4,66.3,0h-2.7C63.2,1.4,63,2.2,62,2.7h0c-1.1,0.4-1.8-0.1-3.1-0.7L57,3.9
|
||||
c0.6,1.3,1.1,2,0.7,3.1C57.2,8,56.4,8.2,55,8.7v2.7c1.4,0.5,2.2,0.6,2.7,1.7c0.4,1.1-0.1,1.8-0.7,3.1l1.9,1.9
|
||||
c1.3-0.6,2-1.1,3.1-0.7h0c1.1,0.4,1.2,1.3,1.7,2.7h2.7c0.5-1.4,0.6-2.2,1.7-2.7h0c1.1-0.4,1.8,0.1,3.1,0.7l1.9-1.9
|
||||
c-0.6-1.3-1.1-2-0.7-3.1C72.8,12,73.6,11.8,75,11.3L75,11.3z M65,13.3c-1.8,0-3.3-1.5-3.3-3.3s1.5-3.3,3.3-3.3
|
||||
c1.8,0,3.3,1.5,3.3,3.3S66.8,13.3,65,13.3L65,13.3z"/>
|
||||
<path id="Shape" class="st6" d="M12.1,1C4.5,1,0,10,0,10s4.5,9,12.1,9c7.4,0,11.9-9,11.9-9S19.5,1,12.1,1L12.1,1z M12,16
|
||||
c-3.3,0-6-2.7-6-6c0-3.3,2.7-6,6-6c3.3,0,6,2.7,6,6C18,13.3,15.3,16,12,16L12,16z M15,10c0,1.7-1.3,3-3,3s-3-1.3-3-3s1.3-3,3-3
|
||||
S15,8.3,15,10L15,10z"/>
|
||||
<path class="st6" d="M31,15v4h4L45.6,8.4l-4-4L31,15L31,15z M35,17.7h-2.6V15h1.3v1.3H35V17.7L35,17.7z M48.6,5.4l-1.7,1.7
|
||||
l-4-4l1.7-1.7C44.9,1.1,45.2,1,45.6,1c0.4,0,0.7,0.1,0.9,0.4l2.1,2.1C49.1,4,49.1,4.8,48.6,5.4L48.6,5.4z"/>
|
||||
</g>
|
||||
<g transform="translate(0.000000, 84.000000)">
|
||||
<path class="st7" d="M75,11.3V8.7C73.6,8.2,72.8,8,72.3,7v0c-0.4-1.1,0.1-1.8,0.7-3.1L71.1,2c-1.3,0.6-2,1.1-3.1,0.7h0
|
||||
C67,2.2,66.8,1.4,66.3,0h-2.7C63.2,1.4,63,2.2,62,2.7h0c-1.1,0.4-1.8-0.1-3.1-0.7L57,3.9c0.6,1.3,1.1,2,0.7,3.1
|
||||
C57.2,8,56.4,8.2,55,8.7v2.7c1.4,0.5,2.2,0.6,2.7,1.7c0.4,1.1-0.1,1.8-0.7,3.1l1.9,1.9c1.3-0.6,2-1.1,3.1-0.7h0
|
||||
c1.1,0.4,1.2,1.3,1.7,2.7h2.7c0.5-1.4,0.6-2.2,1.7-2.7h0c1.1-0.4,1.8,0.1,3.1,0.7l1.9-1.9c-0.6-1.3-1.1-2-0.7-3.1
|
||||
C72.8,12,73.6,11.8,75,11.3L75,11.3z M65,13.3c-1.8,0-3.3-1.5-3.3-3.3s1.5-3.3,3.3-3.3c1.8,0,3.3,1.5,3.3,3.3
|
||||
S66.8,13.3,65,13.3L65,13.3z"/>
|
||||
<path class="st7" d="M12.1,1C4.5,1,0,10,0,10s4.5,9,12.1,9c7.4,0,11.9-9,11.9-9S19.5,1,12.1,1L12.1,1z M12,16c-3.3,0-6-2.7-6-6
|
||||
c0-3.3,2.7-6,6-6c3.3,0,6,2.7,6,6C18,13.3,15.3,16,12,16L12,16z M15,10c0,1.7-1.3,3-3,3s-3-1.3-3-3s1.3-3,3-3S15,8.3,15,10
|
||||
L15,10z"/>
|
||||
<path class="st7" d="M31,15v4h4L45.6,8.4l-4-4L31,15L31,15z M35,17.7h-2.6V15h1.3v1.3H35V17.7L35,17.7z M48.6,5.4l-1.7,1.7
|
||||
l-4-4l1.7-1.7C44.9,1.1,45.2,1,45.6,1c0.4,0,0.7,0.1,0.9,0.4l2.1,2.1C49.1,4,49.1,4.8,48.6,5.4L48.6,5.4z"/>
|
||||
</g>
|
||||
<g transform="translate(105.000000, 42.000000)">
|
||||
<path class="st6" d="M75,11.3V8.7C73.6,8.2,72.8,8,72.3,7v0c-0.4-1.1,0.1-1.8,0.7-3.1L71.1,2c-1.3,0.6-2,1.1-3.1,0.7h0
|
||||
C67,2.2,66.8,1.4,66.3,0h-2.7C63.2,1.4,63,2.2,62,2.7h0c-1.1,0.4-1.8-0.1-3.1-0.7L57,3.9c0.6,1.3,1.1,2,0.7,3.1
|
||||
C57.2,8,56.4,8.2,55,8.7v2.7c1.4,0.5,2.2,0.6,2.7,1.7c0.4,1.1-0.1,1.8-0.7,3.1l1.9,1.9c1.3-0.6,2-1.1,3.1-0.7h0
|
||||
c1.1,0.4,1.2,1.3,1.7,2.7h2.7c0.5-1.4,0.6-2.2,1.7-2.7h0c1.1-0.4,1.8,0.1,3.1,0.7l1.9-1.9c-0.6-1.3-1.1-2-0.7-3.1
|
||||
C72.8,12,73.6,11.8,75,11.3L75,11.3z M65,13.3c-1.8,0-3.3-1.5-3.3-3.3s1.5-3.3,3.3-3.3c1.8,0,3.3,1.5,3.3,3.3
|
||||
S66.8,13.3,65,13.3L65,13.3z"/>
|
||||
<path class="st6" d="M12.1,1C4.5,1,0,10,0,10s4.5,9,12.1,9c7.4,0,11.9-9,11.9-9S19.5,1,12.1,1L12.1,1z M12,16c-3.3,0-6-2.7-6-6
|
||||
c0-3.3,2.7-6,6-6c3.3,0,6,2.7,6,6C18,13.3,15.3,16,12,16L12,16z M15,10c0,1.7-1.3,3-3,3s-3-1.3-3-3s1.3-3,3-3S15,8.3,15,10
|
||||
L15,10z"/>
|
||||
<path class="st6" d="M31,15v4h4L45.6,8.4l-4-4L31,15L31,15z M35,17.7h-2.6V15h1.3v1.3H35V17.7L35,17.7z M48.6,5.4l-1.7,1.7
|
||||
l-4-4l1.7-1.7C44.9,1.1,45.2,1,45.6,1c0.4,0,0.7,0.1,0.9,0.4l2.1,2.1C49.1,4,49.1,4.8,48.6,5.4L48.6,5.4z"/>
|
||||
</g>
|
||||
<g transform="translate(0.000000, 42.000000)">
|
||||
<path class="st7" d="M75,11.3V8.7C73.6,8.2,72.8,8,72.3,7v0c-0.4-1.1,0.1-1.8,0.7-3.1L71.1,2c-1.3,0.6-2,1.1-3.1,0.7h0
|
||||
C67,2.2,66.8,1.4,66.3,0h-2.7C63.2,1.4,63,2.2,62,2.7h0c-1.1,0.4-1.8-0.1-3.1-0.7L57,3.9c0.6,1.3,1.1,2,0.7,3.1
|
||||
C57.2,8,56.4,8.2,55,8.7v2.7c1.4,0.5,2.2,0.6,2.7,1.7c0.4,1.1-0.1,1.8-0.7,3.1l1.9,1.9c1.3-0.6,2-1.1,3.1-0.7h0
|
||||
c1.1,0.4,1.2,1.3,1.7,2.7h2.7c0.5-1.4,0.6-2.2,1.7-2.7h0c1.1-0.4,1.8,0.1,3.1,0.7l1.9-1.9c-0.6-1.3-1.1-2-0.7-3.1
|
||||
C72.8,12,73.6,11.8,75,11.3L75,11.3z M65,13.3c-1.8,0-3.3-1.5-3.3-3.3s1.5-3.3,3.3-3.3c1.8,0,3.3,1.5,3.3,3.3
|
||||
S66.8,13.3,65,13.3L65,13.3z"/>
|
||||
<path class="st7" d="M12.1,1C4.5,1,0,10,0,10s4.5,9,12.1,9c7.4,0,11.9-9,11.9-9S19.5,1,12.1,1L12.1,1z M12,16c-3.3,0-6-2.7-6-6
|
||||
c0-3.3,2.7-6,6-6c3.3,0,6,2.7,6,6C18,13.3,15.3,16,12,16L12,16z M15,10c0,1.7-1.3,3-3,3s-3-1.3-3-3s1.3-3,3-3S15,8.3,15,10
|
||||
L15,10z"/>
|
||||
<path class="st7" d="M31,15v4h4L45.6,8.4l-4-4L31,15L31,15z M35,17.7h-2.6V15h1.3v1.3H35V17.7L35,17.7z M48.6,5.4l-1.7,1.7
|
||||
l-4-4l1.7-1.7C44.9,1.1,45.2,1,45.6,1c0.4,0,0.7,0.1,0.9,0.4l2.1,2.1C49.1,4,49.1,4.8,48.6,5.4L48.6,5.4z"/>
|
||||
</g>
|
||||
<g transform="translate(105.000000, 0.000000)">
|
||||
<path class="st6" d="M75,11.3V8.7C73.6,8.2,72.8,8,72.3,7v0c-0.4-1.1,0.1-1.8,0.7-3.1L71.1,2c-1.3,0.6-2,1.1-3.1,0.7h0
|
||||
C67,2.2,66.8,1.4,66.3,0h-2.7C63.2,1.4,63,2.2,62,2.7h0c-1.1,0.4-1.8-0.1-3.1-0.7L57,3.9c0.6,1.3,1.1,2,0.7,3.1
|
||||
C57.2,8,56.4,8.2,55,8.7v2.7c1.4,0.5,2.2,0.6,2.7,1.7c0.4,1.1-0.1,1.8-0.7,3.1l1.9,1.9c1.3-0.6,2-1.1,3.1-0.7h0
|
||||
c1.1,0.4,1.2,1.3,1.7,2.7h2.7c0.5-1.4,0.6-2.2,1.7-2.7h0c1.1-0.4,1.8,0.1,3.1,0.7l1.9-1.9c-0.6-1.3-1.1-2-0.7-3.1
|
||||
C72.8,12,73.6,11.8,75,11.3L75,11.3z M65,13.3c-1.8,0-3.3-1.5-3.3-3.3s1.5-3.3,3.3-3.3c1.8,0,3.3,1.5,3.3,3.3
|
||||
S66.8,13.3,65,13.3L65,13.3z"/>
|
||||
<path class="st6" d="M12.1,1C4.5,1,0,10,0,10s4.5,9,12.1,9c7.4,0,11.9-9,11.9-9S19.5,1,12.1,1L12.1,1z M12,16c-3.3,0-6-2.7-6-6
|
||||
c0-3.3,2.7-6,6-6c3.3,0,6,2.7,6,6C18,13.3,15.3,16,12,16L12,16z M15,10c0,1.7-1.3,3-3,3s-3-1.3-3-3s1.3-3,3-3S15,8.3,15,10
|
||||
L15,10z"/>
|
||||
<path class="st6" d="M31,15v4h4L45.6,8.4l-4-4L31,15L31,15z M35,17.7h-2.6V15h1.3v1.3H35V17.7L35,17.7z M48.6,5.4l-1.7,1.7
|
||||
l-4-4l1.7-1.7C44.9,1.1,45.2,1,45.6,1c0.4,0,0.7,0.1,0.9,0.4l2.1,2.1C49.1,4,49.1,4.8,48.6,5.4L48.6,5.4z"/>
|
||||
</g>
|
||||
<g>
|
||||
<path class="st7" d="M75,11.3V8.7C73.6,8.2,72.8,8,72.3,7v0c-0.4-1.1,0.1-1.8,0.7-3.1L71.1,2c-1.3,0.6-2,1.1-3.1,0.7h0
|
||||
C67,2.2,66.8,1.4,66.3,0h-2.7C63.2,1.4,63,2.2,62,2.7h0c-1.1,0.4-1.8-0.1-3.1-0.7L57,3.9c0.6,1.3,1.1,2,0.7,3.1
|
||||
C57.2,8,56.4,8.2,55,8.7v2.7c1.4,0.5,2.2,0.6,2.7,1.7c0.4,1.1-0.1,1.8-0.7,3.1l1.9,1.9c1.3-0.6,2-1.1,3.1-0.7h0
|
||||
c1.1,0.4,1.2,1.3,1.7,2.7h2.7c0.5-1.4,0.6-2.2,1.7-2.7h0c1.1-0.4,1.8,0.1,3.1,0.7l1.9-1.9c-0.6-1.3-1.1-2-0.7-3.1
|
||||
C72.8,12,73.6,11.8,75,11.3L75,11.3z M65,13.3c-1.8,0-3.3-1.5-3.3-3.3s1.5-3.3,3.3-3.3c1.8,0,3.3,1.5,3.3,3.3
|
||||
S66.8,13.3,65,13.3L65,13.3z"/>
|
||||
<path class="st6" d="M12.1,1C4.5,1,0,10,0,10s4.5,9,12.1,9c7.4,0,11.9-9,11.9-9S19.5,1,12.1,1L12.1,1z M12,16c-3.3,0-6-2.7-6-6
|
||||
c0-3.3,2.7-6,6-6c3.3,0,6,2.7,6,6C18,13.3,15.3,16,12,16L12,16z M15,10c0,1.7-1.3,3-3,3s-3-1.3-3-3s1.3-3,3-3S15,8.3,15,10
|
||||
L15,10z"/>
|
||||
<path class="st6" d="M31,15v4h4L45.6,8.4l-4-4L31,15L31,15z M35,17.7h-2.6V15h1.3v1.3H35V17.7L35,17.7z M48.6,5.4l-1.7,1.7
|
||||
l-4-4l1.7-1.7C44.9,1.1,45.2,1,45.6,1c0.4,0,0.7,0.1,0.9,0.4l2.1,2.1C49.1,4,49.1,4.8,48.6,5.4L48.6,5.4z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="repos" transform="translate(0.000000, 98.000000)">
|
||||
<g id="node" transform="translate(0.000000, 84.000000)">
|
||||
<text transform="matrix(1 0 0 1 33 19)" class="st8 st3 st9">dev/node</text>
|
||||
<path class="st10" d="M27.6,5.9c0.4,0.6,0.5,1.4,0.3,2.2l-4.6,15.2C23,24,22.6,24.6,22,25.1c-0.6,0.5-1.3,0.7-2.1,0.7H4.4
|
||||
c-0.9,0-1.7-0.3-2.5-0.9s-1.4-1.3-1.7-2.2c-0.3-0.8-0.3-1.5,0-2.1c0,0,0-0.2,0.1-0.5s0.1-0.5,0.1-0.6c0-0.1,0-0.2-0.1-0.4
|
||||
c0-0.2-0.1-0.3-0.1-0.3c0-0.1,0.1-0.2,0.1-0.4c0.1-0.1,0.2-0.2,0.3-0.4s0.2-0.3,0.3-0.4c0.3-0.4,0.5-0.9,0.8-1.5
|
||||
c0.2-0.6,0.4-1.1,0.5-1.5c0-0.1,0-0.3,0-0.5c0-0.2,0-0.4,0-0.5c0-0.1,0.1-0.3,0.3-0.5c0.2-0.2,0.3-0.3,0.3-0.4
|
||||
c0.2-0.4,0.5-0.9,0.7-1.5c0.2-0.6,0.4-1.1,0.4-1.5c0-0.1,0-0.3,0-0.5c0-0.3,0-0.4,0-0.5c0-0.1,0.2-0.3,0.4-0.5
|
||||
C4.4,8,4.5,7.9,4.5,7.8C4.8,7.5,5,7,5.3,6.4s0.4-1.2,0.5-1.6c0-0.1,0-0.2-0.1-0.4S5.6,4,5.6,3.9c0-0.1,0.1-0.2,0.2-0.3
|
||||
C5.9,3.5,6,3.3,6.1,3.2C6.2,3,6.3,2.9,6.4,2.8c0.1-0.1,0.2-0.3,0.3-0.5c0.1-0.2,0.2-0.4,0.3-0.6s0.2-0.4,0.3-0.6
|
||||
c0.1-0.2,0.2-0.4,0.3-0.5S7.8,0.3,8,0.2S8.3,0,8.6,0S9,0,9.4,0.1l0,0.1C9.8,0.1,10.1,0,10.2,0H23c0.8,0,1.5,0.3,1.9,0.9
|
||||
c0.4,0.6,0.5,1.4,0.3,2.2l-4.6,15.2c-0.4,1.3-0.8,2.2-1.2,2.6c-0.4,0.4-1.1,0.6-2.2,0.6H2.6c-0.3,0-0.5,0.1-0.6,0.3
|
||||
c-0.1,0.2-0.1,0.4,0,0.7c0.3,0.8,1.1,1.2,2.4,1.2h15.5c0.3,0,0.6-0.1,0.9-0.3c0.3-0.2,0.5-0.4,0.6-0.7l5-16.6
|
||||
c0.1-0.2,0.1-0.6,0.1-1C27,5.3,27.3,5.6,27.6,5.9L27.6,5.9z M9.7,5.9c0,0.1,0,0.3,0,0.4C9.8,6.4,9.9,6.5,10,6.5h10.2
|
||||
c0.1,0,0.3-0.1,0.4-0.2c0.1-0.1,0.2-0.2,0.3-0.4l0.4-1.1c0-0.1,0-0.3,0-0.4c-0.1-0.1-0.2-0.2-0.3-0.2H10.7
|
||||
c-0.1,0-0.3,0.1-0.4,0.2c-0.1,0.1-0.2,0.2-0.3,0.4L9.7,5.9z M8.3,10.2c0,0.1,0,0.3,0,0.4c0.1,0.1,0.2,0.2,0.3,0.2h10.2
|
||||
c0.1,0,0.3-0.1,0.4-0.2c0.1-0.1,0.2-0.2,0.3-0.4l0.4-1.1c0-0.1,0-0.3,0-0.4c-0.1-0.1-0.2-0.2-0.3-0.2H9.3
|
||||
c-0.1,0-0.3,0.1-0.4,0.2S8.7,9,8.6,9.1L8.3,10.2z"/>
|
||||
</g>
|
||||
<g id="java" transform="translate(0.000000, 42.000000)">
|
||||
<text transform="matrix(1 0 0 1 33 19)" class="st8 st3 st9">dev/java</text>
|
||||
<path class="st10" d="M27.6,5.9c0.4,0.6,0.5,1.4,0.3,2.2l-4.6,15.2C23,24,22.6,24.6,22,25.1c-0.6,0.5-1.3,0.7-2.1,0.7H4.4
|
||||
c-0.9,0-1.7-0.3-2.5-0.9s-1.4-1.3-1.7-2.2c-0.3-0.8-0.3-1.5,0-2.1c0,0,0-0.2,0.1-0.5s0.1-0.5,0.1-0.6c0-0.1,0-0.2-0.1-0.4
|
||||
c0-0.2-0.1-0.3-0.1-0.3c0-0.1,0.1-0.2,0.1-0.4c0.1-0.1,0.2-0.2,0.3-0.4s0.2-0.3,0.3-0.4c0.3-0.4,0.5-0.9,0.8-1.5
|
||||
c0.2-0.6,0.4-1.1,0.5-1.5c0-0.1,0-0.3,0-0.5c0-0.2,0-0.4,0-0.5c0-0.1,0.1-0.3,0.3-0.5c0.2-0.2,0.3-0.3,0.3-0.4
|
||||
c0.2-0.4,0.5-0.9,0.7-1.5c0.2-0.6,0.4-1.1,0.4-1.5c0-0.1,0-0.3,0-0.5c0-0.3,0-0.4,0-0.5c0-0.1,0.2-0.3,0.4-0.5
|
||||
C4.4,8,4.5,7.9,4.5,7.8C4.8,7.5,5,7,5.3,6.4s0.4-1.2,0.5-1.6c0-0.1,0-0.2-0.1-0.4S5.6,4,5.6,3.9c0-0.1,0.1-0.2,0.2-0.3
|
||||
C5.9,3.5,6,3.3,6.1,3.2C6.2,3,6.3,2.9,6.4,2.8c0.1-0.1,0.2-0.3,0.3-0.5c0.1-0.2,0.2-0.4,0.3-0.6s0.2-0.4,0.3-0.6
|
||||
c0.1-0.2,0.2-0.4,0.3-0.5S7.8,0.3,8,0.2S8.3,0,8.6,0S9,0,9.4,0.1l0,0.1C9.8,0.1,10.1,0,10.2,0H23c0.8,0,1.5,0.3,1.9,0.9
|
||||
c0.4,0.6,0.5,1.4,0.3,2.2l-4.6,15.2c-0.4,1.3-0.8,2.2-1.2,2.6c-0.4,0.4-1.1,0.6-2.2,0.6H2.6c-0.3,0-0.5,0.1-0.6,0.3
|
||||
c-0.1,0.2-0.1,0.4,0,0.7c0.3,0.8,1.1,1.2,2.4,1.2h15.5c0.3,0,0.6-0.1,0.9-0.3c0.3-0.2,0.5-0.4,0.6-0.7l5-16.6
|
||||
c0.1-0.2,0.1-0.6,0.1-1C27,5.3,27.3,5.6,27.6,5.9L27.6,5.9z M9.7,5.9c0,0.1,0,0.3,0,0.4C9.8,6.4,9.9,6.5,10,6.5h10.2
|
||||
c0.1,0,0.3-0.1,0.4-0.2c0.1-0.1,0.2-0.2,0.3-0.4l0.4-1.1c0-0.1,0-0.3,0-0.4c-0.1-0.1-0.2-0.2-0.3-0.2H10.7
|
||||
c-0.1,0-0.3,0.1-0.4,0.2c-0.1,0.1-0.2,0.2-0.3,0.4L9.7,5.9z M8.3,10.2c0,0.1,0,0.3,0,0.4c0.1,0.1,0.2,0.2,0.3,0.2h10.2
|
||||
c0.1,0,0.3-0.1,0.4-0.2c0.1-0.1,0.2-0.2,0.3-0.4l0.4-1.1c0-0.1,0-0.3,0-0.4c-0.1-0.1-0.2-0.2-0.3-0.2H9.3
|
||||
c-0.1,0-0.3,0.1-0.4,0.2S8.7,9,8.6,9.1L8.3,10.2z"/>
|
||||
</g>
|
||||
<g id="golang">
|
||||
<text transform="matrix(1 0 0 1 33 19)" class="st8 st3 st9">dev/nginx</text>
|
||||
<path class="st10" d="M27.6,5.9c0.4,0.6,0.5,1.4,0.3,2.2l-4.6,15.2C23,24,22.6,24.6,22,25.1c-0.6,0.5-1.3,0.7-2.1,0.7H4.4
|
||||
c-0.9,0-1.7-0.3-2.5-0.9s-1.4-1.3-1.7-2.2c-0.3-0.8-0.3-1.5,0-2.1c0,0,0-0.2,0.1-0.5s0.1-0.5,0.1-0.6c0-0.1,0-0.2-0.1-0.4
|
||||
c0-0.2-0.1-0.3-0.1-0.3c0-0.1,0.1-0.2,0.1-0.4c0.1-0.1,0.2-0.2,0.3-0.4s0.2-0.3,0.3-0.4c0.3-0.4,0.5-0.9,0.8-1.5
|
||||
c0.2-0.6,0.4-1.1,0.5-1.5c0-0.1,0-0.3,0-0.5c0-0.2,0-0.4,0-0.5c0-0.1,0.1-0.3,0.3-0.5c0.2-0.2,0.3-0.3,0.3-0.4
|
||||
c0.2-0.4,0.5-0.9,0.7-1.5c0.2-0.6,0.4-1.1,0.4-1.5c0-0.1,0-0.3,0-0.5c0-0.3,0-0.4,0-0.5c0-0.1,0.2-0.3,0.4-0.5
|
||||
C4.4,8,4.5,7.9,4.5,7.8C4.8,7.5,5,7,5.3,6.4s0.4-1.2,0.5-1.6c0-0.1,0-0.2-0.1-0.4S5.6,4,5.6,3.9c0-0.1,0.1-0.2,0.2-0.3
|
||||
C5.9,3.5,6,3.3,6.1,3.2C6.2,3,6.3,2.9,6.4,2.8c0.1-0.1,0.2-0.3,0.3-0.5c0.1-0.2,0.2-0.4,0.3-0.6s0.2-0.4,0.3-0.6
|
||||
c0.1-0.2,0.2-0.4,0.3-0.5S7.8,0.3,8,0.2S8.3,0,8.6,0S9,0,9.4,0.1l0,0.1C9.8,0.1,10.1,0,10.2,0H23c0.8,0,1.5,0.3,1.9,0.9
|
||||
c0.4,0.6,0.5,1.4,0.3,2.2l-4.6,15.2c-0.4,1.3-0.8,2.2-1.2,2.6c-0.4,0.4-1.1,0.6-2.2,0.6H2.6c-0.3,0-0.5,0.1-0.6,0.3
|
||||
c-0.1,0.2-0.1,0.4,0,0.7c0.3,0.8,1.1,1.2,2.4,1.2h15.5c0.3,0,0.6-0.1,0.9-0.3c0.3-0.2,0.5-0.4,0.6-0.7l5-16.6
|
||||
c0.1-0.2,0.1-0.6,0.1-1C27,5.3,27.3,5.6,27.6,5.9L27.6,5.9z M9.7,5.9c0,0.1,0,0.3,0,0.4C9.8,6.4,9.9,6.5,10,6.5h10.2
|
||||
c0.1,0,0.3-0.1,0.4-0.2c0.1-0.1,0.2-0.2,0.3-0.4l0.4-1.1c0-0.1,0-0.3,0-0.4c-0.1-0.1-0.2-0.2-0.3-0.2H10.7
|
||||
c-0.1,0-0.3,0.1-0.4,0.2c-0.1,0.1-0.2,0.2-0.3,0.4L9.7,5.9z M8.3,10.2c0,0.1,0,0.3,0,0.4c0.1,0.1,0.2,0.2,0.3,0.2h10.2
|
||||
c0.1,0,0.3-0.1,0.4-0.2c0.1-0.1,0.2-0.2,0.3-0.4l0.4-1.1c0-0.1,0-0.3,0-0.4c-0.1-0.1-0.2-0.2-0.3-0.2H9.3
|
||||
c-0.1,0-0.3,0.1-0.4,0.2S8.7,9,8.6,9.1L8.3,10.2z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 249 KiB After Width: | Height: | Size: 72 KiB |
|
|
@ -1,141 +0,0 @@
|
|||
---
|
||||
title: Configure your Notary client
|
||||
description: Learn how to configure your Notary client to push and pull images from Docker Trusted Registry.
|
||||
keywords: registry, notary, trust
|
||||
---
|
||||
|
||||
The Docker CLI client makes it easy to sign images but to streamline that
|
||||
process it generates a set of private and public keys that are not tied
|
||||
to your UCP account. This means that you'll be able to push and sign images to
|
||||
DTR, but UCP won't trust those images since it doesn't know anything about
|
||||
the keys you're using.
|
||||
|
||||
So before signing and pushing images to DTR you should:
|
||||
|
||||
* Configure the Notary CLI client
|
||||
* Import your UCP private keys to the Notary client
|
||||
|
||||
This allows you to start signing images with the private keys in your UCP
|
||||
client bundle, that UCP can trace back to your user account.
|
||||
|
||||
## System requirements
|
||||
|
||||
The version of Notary you install, depends on the version of the Docker CLI
|
||||
you're using:
|
||||
|
||||
* Docker CLI 17.08 or older, use Notary 0.4.3.
|
||||
* Docker CLI 17.09 or newer, use Notary 0.6.0.
|
||||
|
||||
## Download the Notary CLI client
|
||||
|
||||
If you're using Docker Desktop for Mac or Docker Desktop for Windows, you already have the
|
||||
`notary` command installed.
|
||||
|
||||
If you're running Docker on a Linux distribution, you can [download
|
||||
Notary from Github](https://github.com/docker/notary/releases). As an example:
|
||||
|
||||
```bash
|
||||
# Get the latest binary
|
||||
curl -L <download-url> -o notary
|
||||
|
||||
# Make it executable
|
||||
chmod +x notary
|
||||
|
||||
# Move it to a location in your path. Use the -Z option if you're using SELinux.
|
||||
sudo mv -Z notary /usr/bin/
|
||||
```
|
||||
|
||||
## Configure the Notary CLI client
|
||||
|
||||
Before you use the Notary CLI client, you need to configure it to make it
|
||||
talk with the Notary server that's part of DTR.
|
||||
|
||||
There's two ways to do this, either by passing flags to the notary command,
|
||||
or using a configuration file.
|
||||
|
||||
### With flags
|
||||
|
||||
Run the Notary command with:
|
||||
|
||||
```bash
|
||||
notary --server https://<dtr-url> --trustDir ~/.docker/trust --tlscacert <dtr-ca.pem> --help
|
||||
```
|
||||
|
||||
Here's what the flags mean:
|
||||
|
||||
| Flag | Purpose |
|
||||
|:--------------|:----------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `--server` | The Notary server to query |
|
||||
| `--trustDir` | Path to the local directory where trust metadata will be stored |
|
||||
| `--tlscacert` | Path to the DTR CA certificate. If you've configured your system to trust the DTR CA certificate, you don't need to use this flag |
|
||||
|
||||
To avoid having to type all the flags when using the command, you can set an
|
||||
alias:
|
||||
|
||||
|
||||
<ul class="nav nav-tabs">
|
||||
<li class="active"><a data-toggle="tab" data-target="#tab3">Bash</a></li>
|
||||
<li><a data-toggle="tab" data-target="#tab4">PowerShell</a></li>
|
||||
</ul>
|
||||
<div class="tab-content">
|
||||
<div id="tab3" class="tab-pane fade in active" markdown="1">
|
||||
```
|
||||
alias notary="notary --server https://<dtr-url> --trustDir ~/.docker/trust --tlscacert <dtr-ca.pem>"
|
||||
```
|
||||
<hr>
|
||||
</div>
|
||||
<div id="tab4" class="tab-pane fade" markdown="1">
|
||||
```
|
||||
set-alias notary "notary --server https://<dtr-url> --trustDir ~/.docker/trust --tlscacert <dtr-ca.pem>"
|
||||
```
|
||||
<hr>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
### With a configuration file
|
||||
|
||||
You can also configure Notary by creating a `~/.notary/config.json` file with
|
||||
the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"trust_dir" : "~/.docker/trust",
|
||||
"remote_server": {
|
||||
"url": "https://<dtr-url>:<dtr-port>",
|
||||
"root_ca": "<dtr-ca.pem>"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To validate your configuration, try running the `notary list` command on a
|
||||
DTR repository that already has signed images:
|
||||
|
||||
```bash
|
||||
notary list <dtr-url>/<account>/<repository>
|
||||
```
|
||||
|
||||
The command should print a list of digests for each signed image on the
|
||||
repository.
|
||||
|
||||
## Import your UCP key
|
||||
|
||||
The last step in configuring the Notary CLI client is to import the private
|
||||
key of your UCP client bundle.
|
||||
[Get a new client bundle if you don't have one yet](/datacenter/ucp/2.2/guides/user/access-ucp/cli-based-access.md).
|
||||
|
||||
Import the private key in your UCP bundle into the Notary CLI client:
|
||||
|
||||
```bash
|
||||
notary key import <path-to-key.pem>
|
||||
```
|
||||
|
||||
The private key is copied to `~/.docker/trust`, and you'll be prompted for a
|
||||
password to encrypt it.
|
||||
|
||||
You can validate what keys Notary knows about by running:
|
||||
|
||||
```bash
|
||||
notary key list
|
||||
```
|
||||
|
||||
The key you've imported should be listed with the role `delegation`.
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
---
|
||||
title: Delegate image signing
|
||||
description: Learn how to grant permission for others to sign images in Docker Trusted Registry.
|
||||
keywords: registry, sign, trust
|
||||
---
|
||||
|
||||
Instead of signing all the images yourself, you can delegate that task
|
||||
to other users.
|
||||
|
||||
A typical workflow looks like this:
|
||||
|
||||
1. A repository owner creates a repository in DTR, and initializes the trust
|
||||
metadata for that repository
|
||||
3. Team members download a UCP client bundle and share their public key
|
||||
certificate with the repository owner
|
||||
4. The repository owner delegates signing to the team members
|
||||
5. Team members can sign images using the private keys in their UCP client
|
||||
bundles
|
||||
|
||||
In this example, the IT ops team creates and initializes trust for the
|
||||
`dev/nginx`. Then they allow users in the QA team to push and sign images in
|
||||
that repository.
|
||||
|
||||
|
||||
|
||||
## Create a repository and initialize trust
|
||||
|
||||
A member of the IT ops team starts by configuring their
|
||||
[Notary CLI client](../../access-dtr/configure-your-notary-client.md).
|
||||
|
||||
Then they create the `dev/nginx` repository,
|
||||
[initialize the trust metadata](index.md) for that repository, and grant
|
||||
write access to members of the QA team, so that they can push images to that
|
||||
repository.
|
||||
|
||||
## Ask for the public key certificates
|
||||
|
||||
The member of the IT ops team then asks the QA team for their public key
|
||||
certificate files that are part of their UCP client bundle.
|
||||
|
||||
If they don't have a UCP client bundle,
|
||||
[they can download a new one](/ee/ucp/user-access/cli.md).
|
||||
|
||||
## Delegate image signing
|
||||
|
||||
When delegating trust, you associate a public key certificate with a role name.
|
||||
UCP requires that you delegate trust to two different roles:
|
||||
|
||||
* `targets/releases`
|
||||
* `targets/<role>`, where `<role>` is the UCP team the user belongs to
|
||||
|
||||
In this example we'll delegate trust to `targets/releases` and `targets/qa`:
|
||||
|
||||
```bash
|
||||
# Delegate trust, and add that public key with the role targets/releases
|
||||
notary delegation add dtr.example.org/dev/nginx targets/releases \
|
||||
<user-1-cert.pem> <user-2-cert.pem> --all-paths --publish
|
||||
|
||||
# Delegate trust, and add that public key with the role targets/admin
|
||||
notary delegation add dtr.example.org/dev/nginx targets/qa \
|
||||
<user-1-cert.pem> <user-2-cert.pem> --all-paths --publish
|
||||
```
|
||||
|
||||
Now members from the QA team just have to [configure their Notary CLI client
|
||||
with UCP private keys](../../access-dtr/configure-your-notary-client.md)
|
||||
to be able to [push and sign images](index.md) into the `dev/nginx` repository.
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Manage trusted repositories](manage-trusted-repositories.md)
|
||||
|
|
@ -2,175 +2,245 @@
|
|||
title: Sign an image
|
||||
description: Learn how to sign the images you push to Docker Trusted Registry.
|
||||
keywords: registry, sign, trust
|
||||
redirect_from:
|
||||
- /ee/dtr/user/manage-images/sign-images/delegate-image-signing/
|
||||
- /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/
|
||||
---
|
||||
|
||||
By default, when you push an image to DTR, the Docker CLI client doesn't
|
||||
sign the image.
|
||||
2 Key components of the Docker Trusted Registry is the Notary Server and Notary
|
||||
Signer. These 2 containers give us the required components to use Docker Content
|
||||
Trust right out of the box. [Docker Content
|
||||
Trust](/engine/security/trust/content_trust/) allows us to sign image tags,
|
||||
therefore whoever pulls the image can validate that they are getting the image
|
||||
you create, or a forged one.
|
||||
|
||||
As part of Docker Trusted Registry both the Notary server and the Registry
|
||||
server are accessed through a front end Proxy, with both components sharing the
|
||||
UCP's RBAC Engine. Therefore no additional configuration of the Docker Client
|
||||
is required to use trust.
|
||||
|
||||
Docker Content Trust is integrated into the Docker CLI, allowing you to
|
||||
configure repositories, add signers and sign images all through the `$ docker
|
||||
trust` command.
|
||||
|
||||
|
||||
|
||||
You can configure the Docker CLI client to sign the images you push to DTR.
|
||||
This allows whoever pulls your image to validate if they are getting the image
|
||||
you created, or a forged one.
|
||||
|
||||
To sign an image, you can run:
|
||||
|
||||
```bash
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
docker push <dtr-domain>/<repository>/<image>:<tag>
|
||||
```
|
||||
|
||||
This pushes the image to DTR and creates trust metadata. It also creates
|
||||
public and private key pairs to sign the trust metadata, and pushes that metadata
|
||||
to the Notary Server internal to DTR.
|
||||
|
||||
|
||||
|
||||
|
||||
## Sign images that UCP can trust
|
||||
|
||||
With the command above you'll be able to sign your DTR images, but UCP won't
|
||||
trust them because it can't tie the private key you're using to sign the images
|
||||
to your UCP account.
|
||||
UCP has a feature which will prevent [untrusted
|
||||
images](/ee/ucp/admin/configure/run-only-the-images-you-trust/) from being
|
||||
deployed on the cluster. To use this feature, we first need to upload and sign
|
||||
images into DTR. To tie the signed images back to UCP, we will actually sign the
|
||||
images with private keys of UCP users. Inside of a UCP Client bundle the
|
||||
`key.pem` can be used a User's private key, with the `cert.pem` being a public
|
||||
key within a x509 certificate.
|
||||
|
||||
To sign images in a way that UCP trusts them, you need to:
|
||||
|
||||
* Configure your Notary client
|
||||
* Initialize trust metadata for the repository
|
||||
* Delegate signing to the keys in your UCP client bundle
|
||||
1. Download a Client Bundle for a User you want to use to sign the images.
|
||||
2. Load the private key of the User into your workstations trust store.
|
||||
3. Initialize trust metadata for the repository.
|
||||
4. Delegate signing for that repository to the UCP User.
|
||||
5. Sign the Image.
|
||||
|
||||
In this example we're going to pull an NGINX image from Docker Hub,
|
||||
re-tag it as `dtr.example.org/dev/nginx:1`, push the image to DTR and sign it
|
||||
in a way that is trusted by UCP. If you manage multiple repositories, you'll
|
||||
have to do the same procedure for every one of them.
|
||||
In this example we're going to pull a nginx image from the Docker Hub, re-tag it
|
||||
as `dtr.example.com/dev/nginx:1`, push the image to DTR and sign it in a way
|
||||
that is trusted by UCP. If you manage multiple repositories, you'll have to do
|
||||
the same procedure for each repository.
|
||||
|
||||
### Configure your Notary client
|
||||
### Import a UCP User's Private Key
|
||||
|
||||
Start by [configuring your Notary client](../../access-dtr/configure-your-notary-client.md).
|
||||
This ensures the Docker an Notary CLI clients know about your UCP private keys.
|
||||
|
||||
### Initialize the trust metadata
|
||||
|
||||
Then you need to initialize the trust metadata for the new repository, and
|
||||
the easiest way to do it is by pushing an image to that repository. Navigate to
|
||||
the **DTR web UI**, and create a repository for your image.
|
||||
In this example we've created the `dev/nginx` repository.
|
||||
|
||||
From the Docker CLI client, pull an NGINX image from Docker Hub,
|
||||
re-tag it, sign and push it to DTR.
|
||||
Once you have download and extracted a UCP User's client bundle into your local
|
||||
directory, you need to load the Private key into the local Docker trust store
|
||||
`(~/.docker/trust)`. The name used here is purely metadata to help keep track of
|
||||
which keys you have imported.
|
||||
|
||||
```bash
|
||||
# Pull NGINX from Docker Hub
|
||||
docker pull nginx:latest
|
||||
|
||||
# Re-tag NGINX
|
||||
docker tag nginx:latest dtr.example.org/dev/nginx:1
|
||||
|
||||
# Log into DTR
|
||||
docker login dtr.example.org
|
||||
|
||||
# Sign and push the image to DTR
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
docker push dtr.example.org/dev/nginx:1
|
||||
$ docker trust key load --name jeff key.pem
|
||||
Loading key from "key.pem"...
|
||||
Enter passphrase for new jeff key with ID a453196:
|
||||
Repeat passphrase for new jeff key with ID a453196:
|
||||
Successfully imported key from key.pem
|
||||
```
|
||||
|
||||
This pushes the image to DTR and initializes the trust metadata for that
|
||||
repository.
|
||||
### Initialize the trust metadata and add the Public Key
|
||||
|
||||
Next, we need to initiate trust metadata for a DTR repository. If you have not
|
||||
done so already, navigate to the **DTR web UI**, and create a repository for
|
||||
your image. In this example we've created the `prod/nginx` repository.
|
||||
|
||||
As part of initiating the repository, we will add the public key of the UCP User
|
||||
as a signer. You will be asked for a number of passphrases to protect the keys.
|
||||
Please keep note of these passphrases, and to learn more about managing keys
|
||||
head to the Docker Content Trust documentation
|
||||
[here](/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server).
|
||||
|
||||
|
||||
```bash
|
||||
$ docker trust signer add --key cert.pem jeff dtr.example.com/prod/nginx
|
||||
Adding signer "jeff" to dtr.example.com/prod/nginx...
|
||||
Initializing signed repository for dtr.example.com/prod/nginx...
|
||||
Enter passphrase for root key with ID 4a72d81:
|
||||
Enter passphrase for new repository key with ID e0d15a2:
|
||||
Repeat passphrase for new repository key with ID e0d15a2:
|
||||
Successfully initialized "dtr.example.com/prod/nginx"
|
||||
Successfully added signer: jeff to dtr.example.com/prod/nginx
|
||||
```
|
||||
|
||||
We can inspect the trust metadata of the repository to make sure the User has
|
||||
been added correctly.
|
||||
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/prod/nginx
|
||||
|
||||
No signatures for dtr.example.com/prod/nginx
|
||||
|
||||
List of signers and their keys for dtr.example.com/prod/nginx
|
||||
|
||||
SIGNER KEYS
|
||||
jeff 927f30366699
|
||||
|
||||
Administrative keys for dtr.example.com/prod/nginx
|
||||
|
||||
Repository Key: e0d15a24b741ab049470298734397afbea539400510cb30d3b996540b4a2506b
|
||||
Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
|
||||
```
|
||||
|
||||
### Sign the Image
|
||||
|
||||
Finally, we will sign an image tag. These steps download the Image from the
|
||||
Docker Hub, retag the Image to the DTR repository, push the image up to DTR, as
|
||||
well as signing the tag with the UCP User's keys.
|
||||
|
||||
```bash
|
||||
$ docker pull nginx:latest
|
||||
|
||||
$ docker tag nginx:latest dtr.example.com/prod/nginx:1
|
||||
|
||||
$ docker trust sign dtr.example.com/prod/nginx:1
|
||||
Signing and pushing trust data for local image dtr.example.com/prod/nginx:1, may overwrite remote trust data
|
||||
The push refers to repository [dtr.example.com/prod/nginx]
|
||||
6b5e2ed60418: Pushed
|
||||
92c15149e23b: Pushed
|
||||
0a07e81f5da3: Pushed
|
||||
1: digest: sha256:5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 size: 948
|
||||
Signing and pushing trust metadata
|
||||
Enter passphrase for jeff key with ID 927f303:
|
||||
Successfully signed dtr.example.com/prod/nginx:1
|
||||
```
|
||||
|
||||
We can inspect the trust metadata again to make sure the image tag has been
|
||||
signed successfully.
|
||||
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/prod/nginx:1
|
||||
|
||||
Signatures for dtr.example.com/prod/nginx:1
|
||||
|
||||
SIGNED TAG DIGEST SIGNERS
|
||||
1 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 jeff
|
||||
|
||||
List of signers and their keys for dtr.example.com/prod/nginx:1
|
||||
|
||||
SIGNER KEYS
|
||||
jeff 927f30366699
|
||||
|
||||
Administrative keys for dtr.example.com/prod/nginx:1
|
||||
|
||||
Repository Key: e0d15a24b741ab049470298734397afbea539400510cb30d3b996540b4a2506b
|
||||
Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
|
||||
```
|
||||
|
||||
Or we can have a look at the signed image from within the **DTR UI**.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
DTR shows that the image is signed, but UCP won't trust the image
|
||||
because it doesn't have any information about the private keys used to sign
|
||||
the image.
|
||||
### Adding Additional Delegations
|
||||
|
||||
### Delegate trust to your UCP keys
|
||||
If you wanted to sign this image with multiple UCP Users, maybe if you had a use
|
||||
case where an image needed to be signed by a member of the `Security` team and a
|
||||
member of the `Developers` team. Then you can add multiple signers to a
|
||||
repository.
|
||||
|
||||
To sign images in a way that is trusted by UCP, you need to delegate trust, so
|
||||
that you can sign images with the private keys in your UCP client bundle.
|
||||
|
||||
When delegating trust you associate a public key certificate with a role name.
|
||||
UCP requires that you delegate trust to two different roles:
|
||||
|
||||
* `targets/releases`
|
||||
* `targets/<role>`, where `<role>` is the UCP team the user belongs to
|
||||
|
||||
In this example we'll delegate trust to `targets/releases` and `targets/admin`:
|
||||
To do so, first load a private key from a UCP User of the Security Team's in to
|
||||
the local Docker Trust Store.
|
||||
|
||||
```bash
|
||||
# Delegate trust, and add that public key with the role targets/releases
|
||||
notary delegation add --publish \
|
||||
dtr.example.org/dev/nginx \
|
||||
targets/releases \
|
||||
--all-paths <ucp-cert.pem>
|
||||
|
||||
# Delegate trust, and add that public key with the role targets/admin
|
||||
notary delegation add --publish \
|
||||
dtr.example.org/dev/nginx \
|
||||
targets/admin \
|
||||
--all-paths <ucp-cert.pem>
|
||||
$ docker trust key load --name security key.pem
|
||||
Loading key from "key.pem"...
|
||||
Enter passphrase for new security key with ID 5ac7d9a:
|
||||
Repeat passphrase for new security key with ID 5ac7d9a:
|
||||
Successfully imported key from key.pem
|
||||
```
|
||||
|
||||
To push the new signing metadata to the Notary server, you'll have to push
|
||||
the image again:
|
||||
Upload the Public Key to the Notary Server and Sign the Image. You will be asked
|
||||
for both the Developers passphrase, as well as the Security Users passphrase to
|
||||
sign the tag.
|
||||
|
||||
```none
|
||||
docker push dtr.example.org/dev/nginx:1
|
||||
```bash
|
||||
$ docker trust signer add --key cert.pem security dtr.example.com/prod/nginx
|
||||
Adding signer "security" to dtr.example.com/prod/nginx...
|
||||
Enter passphrase for repository key with ID e0d15a2:
|
||||
Successfully added signer: security to dtr.example.com/prod/nginx
|
||||
|
||||
$ docker trust sign dtr.example.com/prod/nginx:1
|
||||
Signing and pushing trust metadata for dtr.example.com/prod/nginx:1
|
||||
Existing signatures for tag 1 digest 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 from:
|
||||
jeff
|
||||
Enter passphrase for jeff key with ID 927f303:
|
||||
Enter passphrase for security key with ID 5ac7d9a:
|
||||
Successfully signed dtr.example.com/prod/nginx:1
|
||||
```
|
||||
|
||||
## Under the hood
|
||||
Finally, we can check the tag again to make sure it is now signed by 2
|
||||
signatures.
|
||||
|
||||
Both Docker and Notary CLI clients interact with the Notary server to:
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/prod/nginx:1
|
||||
|
||||
* Keep track of the metadata of signed images
|
||||
* Validate the signatures of the images you pull
|
||||
Signatures for dtr.example.com/prod/nginx:1
|
||||
|
||||
This metadata is also kept locally in `~/.docker/trust`.
|
||||
SIGNED TAG DIGEST SIGNERS
|
||||
1 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 jeff, security
|
||||
|
||||
```none
|
||||
.
|
||||
|-- private
|
||||
| |-- root_keys
|
||||
| | `-- 993ad247476da081e45fdb6c28edc4462f0310a55da4acf1e08404c551d94c14.key
|
||||
| `-- tuf_keys
|
||||
| `-- dtr.example.org
|
||||
| `-- dev
|
||||
| `-- nginx
|
||||
| |-- 98a93b2e52c594de4d13d7268a4a5f28ade5fc1cb5f44cc3a4ab118572a86848.key
|
||||
| `-- f7917aef77d0d4bf8204af78c0716dac6649346ebea1c4cde7a1bfa363c502ce.key
|
||||
`-- tuf
|
||||
`-- dtr.example.org
|
||||
`-- dev
|
||||
`-- nginx
|
||||
|-- changelist
|
||||
`-- metadata
|
||||
|-- root.json
|
||||
|-- snapshot.json
|
||||
|-- targets.json
|
||||
`-- timestamp.json
|
||||
List of signers and their keys for dtr.example.com/prod/nginx:1
|
||||
|
||||
SIGNER KEYS
|
||||
jeff 927f30366699
|
||||
security 5ac7d9af7222
|
||||
|
||||
Administrative keys for dtr.example.com/prod/nginx:1
|
||||
|
||||
Repository Key: e0d15a24b741ab049470298734397afbea539400510cb30d3b996540b4a2506b
|
||||
Root Key: b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
|
||||
```
|
||||
|
||||
The `private` directory contains the private keys the Docker CLI client uses
|
||||
to sign the images. Make sure you create backups of this directory so that
|
||||
you don't lose your signing keys.
|
||||
For more advanced use cases like this, more information can be found [here](/engine/security/trust/trust_delegation/)
|
||||
|
||||
The Docker and Notary CLI clients integrate with Yubikey. If you have a Yubikey
|
||||
plugged in when initializing trust for a repository, the root key is stored on
|
||||
the Yubikey instead of in the trust directory.
|
||||
When you run any command that needs the `root` key, Docker and Notary CLI
|
||||
clients look on the Yubikey first, and use the trust directory as a fallback.
|
||||
## Delete trust data
|
||||
|
||||
The `tuf` directory contains the trust metadata for the images you've
|
||||
signed. For each repository there are four files.
|
||||
If an Administrator wants to delete a DTR repository that contains Trust
|
||||
metadata, they will be prompted to delete the trust metadata first before the
|
||||
repository can be removed.
|
||||
|
||||
| File | Description |
|
||||
|:-----------------|:--------------------------------------------------------------------------------------------------------------------------|
|
||||
| `root.json` | Has data about other keys and their roles. This data is signed by the root key. |
|
||||
| `targets.json` | Has data about the digest and size for an image. This data is signed by the target key. |
|
||||
| `snapshot.json` | Has data about the version number of the root.json and targets.json files. This data is signed by the snapshot key. |
|
||||
| `timestamp.json` | Has data about the digest, size, and version number for the snapshot.json file. This data is signed by the timestamp key. |
|
||||
To delete trust metadata we need to use the Notary CLI. For information on how
|
||||
to download and configure the Notary CLI head
|
||||
[here](/engine/security/trust/trust_delegation/#configuring-the-notary-client)
|
||||
|
||||
[Learn more about trust metadata](/notary/service_architecture.md).
|
||||
|
||||
```bash
|
||||
$ notary delete dtr.example.com/prod/nginx --remote
|
||||
Deleting trust data for repository dtr.example.com/prod/nginx
|
||||
Enter username: admin
|
||||
Enter password:
|
||||
Successfully deleted local and remote trust data for repository dtr.example.com/prod/nginx
|
||||
```
|
||||
|
||||
If you don't include the `--remote` flag, Notary deletes local cached content
|
||||
but will not delete data from the Notary server.
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [Delegate image signing](delegate-image-signing.md)
|
||||
* [Automating Docker Content
|
||||
Trust](/engine/security/trust/trust_automation/)
|
||||
* [Using Docker Content Trust with a Remote UCP](./trust-with-remote-ucp.md)
|
||||
|
|
@ -1,156 +0,0 @@
|
|||
---
|
||||
title: Manage trusted repositories
|
||||
description: Learn how to use the Notary CLI client to manage trusted repositories
|
||||
keywords: dtr, trust, notary, security
|
||||
---
|
||||
|
||||
Once you
|
||||
[configure the Notary CLI client](../../access-dtr/configure-your-notary-client.md),
|
||||
you can use it to manage your private keys, list trust data from any repository
|
||||
you have access to, authorize other team members to sign images, and rotate
|
||||
keys if a private key has been compromised.
|
||||
|
||||
## List trust data
|
||||
|
||||
List the trust data for a repository by running:
|
||||
|
||||
```bash
|
||||
notary list <dtr_url>/<account>/<repository>
|
||||
```
|
||||
|
||||
You can get one of the following errors, or a list with the images that have
|
||||
been signed:
|
||||
|
||||
| Message | Description |
|
||||
|:--------------------------------------------|:-----------------------------------------------------------------------------------------------------------------|
|
||||
| `fatal: client is offline` | Either the repository server can't be reached, or your Notary CLI client is misconfigured |
|
||||
| `fatal: <dtr_url> does not have trust data` | There's no trust data for the repository. Either run `notary init` or sign and push an image to that repository. |
|
||||
| `No targets present in this repository` | The repository has been initialized, but doesn't contain any signed images |
|
||||
|
||||
## Initialize trust for a repository
|
||||
|
||||
There's two ways to initialize trust data for a repository. You can either
|
||||
sign and push an image to that repository:
|
||||
|
||||
```bash
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
docker push <dtr_url>/<account>/<repository>
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
notary init <dtr_url>/<account>/<repository> --publish
|
||||
```
|
||||
|
||||
## Manage staged changes
|
||||
|
||||
The Notary CLI client stages changes before publishing them to the server.
|
||||
You can manage the changes that are staged by running:
|
||||
|
||||
```bash
|
||||
# Check what changes are staged
|
||||
notary status <dtr_url>/<account>/<repository>
|
||||
|
||||
# Unstage a specific change
|
||||
notary status <dtr_url>/<account>/<repository> --unstage 0
|
||||
|
||||
# Alternatively, unstage all changes
|
||||
notary status <dtr_url>/<account>/<repository> --reset
|
||||
```
|
||||
|
||||
When you're ready to publish your changes to the Notary server, run:
|
||||
|
||||
```bash
|
||||
notary publish <dtr_url>/<account>/<repository>
|
||||
```
|
||||
|
||||
## Delete trust data
|
||||
|
||||
Administrator users can remove all signatures from a trusted repository by
|
||||
running:
|
||||
|
||||
```bash
|
||||
notary delete <dtr_url>/<account>/<repository> --remote
|
||||
```
|
||||
|
||||
If you don't include the `--remote` flag, Notary deletes local cached content
|
||||
but will not delete data from the Notary server.
|
||||
|
||||
|
||||
## Change the passphrase for a key
|
||||
|
||||
The Notary CLI client manages the keys used to sign the image metadata. To
|
||||
list all the keys managed by the Notary CLI client, run:
|
||||
|
||||
```bash
|
||||
notary key list
|
||||
```
|
||||
|
||||
To change the passphrase used to encrypt one of the keys, run:
|
||||
|
||||
```bash
|
||||
notary key passwd <key_id>
|
||||
```
|
||||
|
||||
## Rotate keys
|
||||
|
||||
If one of the private keys is compromised you can rotate that key, so that
|
||||
images that were signed with the key stop being trusted.
|
||||
|
||||
For keys that are kept offline and managed by the Notary CLI client, such the
|
||||
keys with the root, targets, and snapshot roles, you can rotate them with:
|
||||
|
||||
```bash
|
||||
notary key rotate <dtr_url>/<account>/<repository> <key_role>
|
||||
```
|
||||
|
||||
The Notary CLI client generates a new key for the role you specified, and
|
||||
prompts you for a passphrase to encrypt it.
|
||||
Then you're prompted for the passphrase for the key you're rotating, and if it
|
||||
is correct, the Notary CLI client contacts the Notary server to publish the
|
||||
change.
|
||||
|
||||
You can also rotate keys that are stored in the Notary server, such as the keys
|
||||
with the snapshot or timestamp role. For that, run:
|
||||
|
||||
```bash
|
||||
notary key rotate <dtr_url>/<account>/<repository> <key_role> --server-managed
|
||||
```
|
||||
|
||||
## Manage keys for delegation roles
|
||||
|
||||
To delegate image signing to other UCP users, get the `cert.pem` file that's
|
||||
included in their client bundle and run:
|
||||
|
||||
```bash
|
||||
notary delegation add \
|
||||
<dtr_url>/<account>/<repository> targets/<role> user1.pem user2.pem \
|
||||
--all-paths --publish
|
||||
```
|
||||
|
||||
You can also remove keys from a delegation role:
|
||||
|
||||
```bash
|
||||
# Remove the given keys from a delegation role
|
||||
notary delegation remove \
|
||||
<dtr_url>/<account>/<repository> targets/<role> <keyID1> <keyID2> \
|
||||
--publish
|
||||
|
||||
# Alternatively, you can remove keys from all delegation roles
|
||||
notary delegation purge <dtr_url>/<account>/<repository> --key <keyID1> --key <keyID2>
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Notary CLI has a `-D` flag that you can use to increase the logging level. You
|
||||
can use this for troubleshooting.
|
||||
|
||||
Usually most problems are fixed by ensuring you're communicating with the
|
||||
correct Notary server, using the `-s` flag, and that you're using the correct
|
||||
directory where your private keys are stored, with the `-d` flag.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Learn more about Notary](/notary/advanced_usage.md)
|
||||
- [Notary architecture](/notary/service_architecture.md)
|
||||
|
|
@ -148,14 +148,14 @@ head to the Docker Content Trust documentation
|
|||
|
||||
|
||||
```
|
||||
$ docker trust signer add --key cert.pem cluster2admin dtr.example.com/admin/trustdemo:1
|
||||
Adding signer "cluster2admin" to dtr.example.com/admin/trustdemo:1...
|
||||
Initializing signed repository for dtr.example.com/admin/trustdemo:1...
|
||||
$ docker trust signer add --key cert.pem cluster2admin dtr.example.com/admin/trustdemo
|
||||
Adding signer "cluster2admin" to dtr.example.com/admin/trustdemo...
|
||||
Initializing signed repository for dtr.example.com/admin/trustdemo...
|
||||
Enter passphrase for root key with ID 4a72d81:
|
||||
Enter passphrase for new repository key with ID dd4460f:
|
||||
Repeat passphrase for new repository key with ID dd4460f:
|
||||
Successfully initialized "dtr.example.com/admin/trustdemo:1"
|
||||
Successfully added signer: cluster2admin to dtr.example.com/admin/trustdemo:1
|
||||
Successfully initialized "dtr.example.com/admin/trustdemo"
|
||||
Successfully added signer: cluster2admin to dtr.example.com/admin/trustdemo
|
||||
```
|
||||
|
||||
Finally we will sign an image tag. This pushes the image up to DTR, as well as
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
description: Delegations for content trust
|
||||
keywords: trust, security, delegations, keys, repository
|
||||
title: Delegations for content trust
|
||||
redirect_from:
|
||||
- /ee/dtr/user/access-dtr/configure-your-notary-client/
|
||||
---
|
||||
|
||||
Delegations in Docker Content Trust (DCT) allow you to control who can and cannot sign
|
||||
|
|
|
|||
Loading…
Reference in New Issue