mirror of https://github.com/docker/docs.git
Merge pull request #8195 from ollypom/trustwithremoteucp
Added Using DTR Trust Data with a Remote UCP
This commit is contained in:
L-Hudson
GitHub
commit
2234622d5f
|
|
@ -1224,8 +1224,6 @@ manuals:
|
|||
title: Join Windows worker nodes to your cluster
|
||||
- path: /ee/ucp/admin/configure/join-nodes/use-a-load-balancer/
|
||||
title: Use a load balancer
|
||||
- path: /ee/ucp/admin/configure/integrate-with-multiple-registries/
|
||||
title: Integrate with multiple registries
|
||||
- path: /ee/ucp/admin/configure/deploy-route-reflectors/
|
||||
title: Improve network performance with Route Reflectors
|
||||
- sectiontitle: Monitor and troubleshoot
|
||||
|
|
@ -2199,10 +2197,8 @@ 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
|
||||
section:
|
||||
- title: Overview
|
||||
|
|
|
|||
|
|
@ -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.
|
After Width: | Height: | Size: 86 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 106 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)
|
||||
|
|
@ -0,0 +1,249 @@
|
|||
---
|
||||
title: Using Docker Content Trust with a Remote UCP Cluster
|
||||
description: Learn how to use a single DTR's trust data with remote UCPs.
|
||||
keywords: registry, sign, trust, notary
|
||||
redirect_from:
|
||||
- /ee/ucp/admin/configure/integrate-with-multiple-registries/
|
||||
---
|
||||
|
||||
For more advanced deployments, you may want to share one Docker Trusted Registry
|
||||
across multiple Universal Control Planes. However, customers wanting to adopt
|
||||
this model alongside the [Only Run Signed
|
||||
Images](../.../../ucp/admin/configure/run-only-the-images-you-trust.md) UCP feature, run into problems as each UCP operates an independent set of users.
|
||||
|
||||
Docker Content Trust (DCT) gets around this problem, since users from
|
||||
a remote UCP are able to sign images in the central DTR and still apply runtime
|
||||
enforcement.
|
||||
|
||||
In the following example, we will connect DTR managed by UCP cluster 1 with a remote UCP cluster which we are calling UCP cluster 2, sign the
|
||||
image with a user from UCP cluster 2, and provide runtime enforcement
|
||||
within UCP cluster 2. This process could be repeated over and over,
|
||||
integrating DTR with multiple remote UCP clusters, signing the image with users
|
||||
from each environment, and then providing runtime enforcement in each remote UCP
|
||||
cluster separately.
|
||||
|
||||
|
||||
|
||||
> Before attempting this guide, familiarize yourself with [Docker Content
|
||||
> Trust](engine/security/trust/content_trust/#signing-images-with-docker-content-trust)
|
||||
> and [Only Run Signed
|
||||
> Images](../.../../ucp/admin/configure/run-only-the-images-you-trust.md) on a
|
||||
> single UCP. Many of the concepts within this guide may be new without that
|
||||
> background.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Cluster 1, running UCP 3.0.x or higher, with a DTR 2.5.x or higher deployed
|
||||
within the cluster.
|
||||
- Cluster 2, running UCP 3.0.x or higher, with no DTR node.
|
||||
- Nodes on Cluster 2 need to trust the Certificate Authority which signed DTR's
|
||||
TLS Certificate. This can be tested by logging on to a cluster 2 virtual
|
||||
machine and running `curl https://dtr.example.com`.
|
||||
- The DTR TLS Certificate needs be properly configured, ensuring that the
|
||||
**Loadbalancer/Public Address** field has been configured, with this address
|
||||
included [within the
|
||||
certificate](../../../admin/configure/use-your-own-tls-certificates/).
|
||||
- A machine with the [Docker Client](/ee/ucp/user-access/cli/) (CE 17.12 /
|
||||
EE 1803 or newer) installed, as this contains the relevant `$ docker trust`
|
||||
commands.
|
||||
|
||||
## Registering DTR with a remote Universal Control Plane
|
||||
|
||||
As there is no registry running within cluster 2, by default UCP will not know
|
||||
where to check for trust data. Therefore, the first thing we need to do is
|
||||
register DTR within the remote UCP in cluster 2. When you normally
|
||||
install DTR, this registration process happens by default to
|
||||
a local UCP, or cluster 1.
|
||||
|
||||
> The registration process allows the remote UCP to get signature data from DTR,
|
||||
> however this will not provide Single Sign On (SSO). Users on cluster 2 will not be
|
||||
> synced with cluster 1's UCP or DTR. Therefore when pulling images, registry
|
||||
> authentication will still need to be passed as part of the service definition
|
||||
> if the repository is private. See
|
||||
> [Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-in-the-cluster-that-holds-your-authorization-token)
|
||||
> or [Docker
|
||||
> Swarm](https://docs.docker.com/engine/swarm/services/#create-a-service-using-an-image-on-a-private-registry) examples.
|
||||
|
||||
To add a new registry, retrieve the Certificate
|
||||
Authority (CA) used to sign the DTR TLS Certificate through the DTR URL's
|
||||
`/ca` endpoint.
|
||||
|
||||
```bash
|
||||
$ curl -ks https://dtr.example.com/ca > dtr.crt
|
||||
```
|
||||
|
||||
Next, convert the DTR certificate into a JSON configuration file
|
||||
for registration within the UCP for cluster 2.
|
||||
|
||||
You can find a template of the `dtr-bundle.json` below. Replace the host address with your DTR URL, and enter the contents of the DTR CA certificate between the new line commands `\n and \n`.
|
||||
|
||||
> ### JSON Formatting
|
||||
> Ensure there are no line breaks between each line
|
||||
> of the DTR CA certificate within the JSON file. Use your favorite JSON formatter for validation.
|
||||
|
||||
```bash
|
||||
$ cat dtr-bundle.json
|
||||
{
|
||||
"hostAddress": "dtr.example.com",
|
||||
"caBundle": "-----BEGIN CERTIFICATE-----\n<contents of cert>\n-----END CERTIFICATE-----"
|
||||
}
|
||||
```
|
||||
|
||||
Now upload the configuration file to cluster 2's UCP
|
||||
through the UCP API endpoint, `/api/config/trustedregistry_`. To authenticate
|
||||
against the API of cluster 2's UCP, we have downloaded a [UCP client
|
||||
bundle](/ee/ucp/user-access/cli/#download-client-certificates/), extracted it in
|
||||
the current directory, and will reference the keys for authentication.
|
||||
|
||||
```bash
|
||||
$ curl --cacert ca.pem --cert cert.pem --key key.pem \
|
||||
-X POST \
|
||||
-H "Accept: application/json" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d @dtr-bundle.json \
|
||||
https://cluster2.example.com/api/config/trustedregistry_
|
||||
```
|
||||
|
||||
Navigate to the UCP web interface to verify that the JSON file was imported successfully, as the UCP endpoint will not
|
||||
output anything. Select **Admin > Admin Settings > Docker
|
||||
Trusted Registry**. If the registry has been added successfully, you should see
|
||||
the DTR listed.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
Additionally, you can check the full [configuration
|
||||
file](/ee/ucp/admin/configure/ucp-configuration-file/) within cluster 2's UCP.
|
||||
Once downloaded, the `ucp-config.toml` file should now contain a section called
|
||||
`[registries]`
|
||||
|
||||
```bash
|
||||
$ curl --cacert ca.pem --cert cert.pem --key key.pem https://cluster2.example.com/api/ucp/config-toml > ucp-config.toml
|
||||
```
|
||||
|
||||
If the new registry isn't shown in the list, check the `ucp-controller` container logs on cluster 2.
|
||||
|
||||
## Signing an image in DTR
|
||||
|
||||
We will now sign an image and push this to DTR. To sign images we need a user's public private
|
||||
key pair from cluster 2. It can be found in a client bundle, with
|
||||
`key.pem` being a private key and `cert.pem` being the public key on an **X.509**
|
||||
certificate.
|
||||
|
||||
First, 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.
|
||||
|
||||
```
|
||||
$ docker trust key load --name cluster2admin key.pem
|
||||
Loading key from "key.pem"...
|
||||
Enter passphrase for new cluster2admin key with ID a453196:
|
||||
Repeat passphrase for new cluster2admin key with ID a453196:
|
||||
Successfully imported key from key.pem
|
||||
```
|
||||
|
||||
Next initiate the repository, and add the public key of cluster 2's user
|
||||
as a signer. You will be asked for a number of passphrases to protect the keys.
|
||||
Keep note of these passphrases, and see [Docker Content Trust documentation]
|
||||
(/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server) to learn more about managing keys.
|
||||
|
||||
|
||||
```
|
||||
$ 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"
|
||||
Successfully added signer: cluster2admin to dtr.example.com/admin/trustdemo
|
||||
```
|
||||
|
||||
Finally, sign the image tag. This pushes the image up to DTR, as well as
|
||||
signs the tag with the user from cluster 2's keys.
|
||||
|
||||
```
|
||||
$ docker trust sign dtr.example.com/admin/trustdemo:1
|
||||
Signing and pushing trust data for local image dtr.example.com/admin/trustdemo:1, may overwrite remote trust data
|
||||
The push refers to repository [dtr.olly.dtcntr.net/admin/trustdemo]
|
||||
27c0b07c1b33: Layer already exists
|
||||
aa84c03b5202: Layer already exists
|
||||
5f6acae4a5eb: Layer already exists
|
||||
df64d3292fd6: Layer already exists
|
||||
1: digest: sha256:37062e8984d3b8fde253eba1832bfb4367c51d9f05da8e581bd1296fc3fbf65f size: 1153
|
||||
Signing and pushing trust metadata
|
||||
Enter passphrase for cluster2admin key with ID a453196:
|
||||
Successfully signed dtr.example.com/admin/trustdemo:1
|
||||
```
|
||||
|
||||
Within the DTR web interface, you should now be able to see your newly pushed tag with the **Signed** text next to the size.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
You could sign this image multiple times if required, whether it's multiple
|
||||
teams from the same cluster wanting to sign the image, or you integrating DTR with more remote UCPs so users from clusters 1,
|
||||
2, 3, or more can all sign the same image.
|
||||
|
||||
## Enforce Signed Image Tags on the Remote UCP
|
||||
|
||||
We can now enable **Only Run Signed Images** on the remote UCP. To do this,
|
||||
login to cluster 2's UCP web interface as an admin. Select **Admin > Admin Settings > Docker Content
|
||||
Trust**.
|
||||
|
||||
See [Run only the images you trust](/ee/ucp/admin/configure/run-only-the-images-you-trust/) for more information on only running signed images in UCP.
|
||||
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
Finally we can now deploy a workload on cluster 2, using a signed
|
||||
image from a DTR running on cluster 1. This workload could be a simple `$ docker
|
||||
run`, a Swarm Service, or a Kubernetes workload. As a simple test, source a
|
||||
client bundle, and try running one of your signed images.
|
||||
|
||||
```
|
||||
$ source env.sh
|
||||
|
||||
$ docker service create dtr.example.com/admin/trustdemo:1
|
||||
nqsph0n6lv9uzod4lapx0gwok
|
||||
overall progress: 1 out of 1 tasks
|
||||
1/1: running [==================================================>]
|
||||
verify: Service converged
|
||||
|
||||
$ docker service ls
|
||||
ID NAME MODE REPLICAS IMAGE PORTS
|
||||
nqsph0n6lv9u laughing_lamarr replicated 1/1 dtr.example.com/admin/trustdemo:1
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If the image is stored in a private repository within DTR, you need to pass credentials to the
|
||||
Orchestrator as there is no SSO between cluster 2 and DTR. See the relevant
|
||||
[Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-in-the-cluster-that-holds-your-authorization-token) or [Docker
|
||||
Swarm](https://docs.docker.com/engine/swarm/services/#create-a-service-using-an-image-on-a-private-registry)
|
||||
documentation for more details.
|
||||
|
||||
### Example Errors
|
||||
|
||||
```
|
||||
image or trust data does not exist for dtr.example.com/admin/trustdemo:1
|
||||
```
|
||||
|
||||
This means something went wrong when initiating the repository or signing the
|
||||
image, as the tag contains no signing data.
|
||||
|
||||
```
|
||||
Error response from daemon: image did not meet required signing policy
|
||||
|
||||
dtr.example.com/admin/trustdemo:1: image did not meet required signing policy
|
||||
```
|
||||
|
||||
This means that the image was signed correctly, however the user who signed the
|
||||
image does not meet the signing policy in cluster 2. This could be because you
|
||||
signed the image with the wrong user keys.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Learn more about Notary](/notary/advanced_usage.md)
|
||||
- [Notary architecture](/notary/service_architecture.md)
|
||||
|
|
@ -1,73 +0,0 @@
|
|||
---
|
||||
title: Integrate with multiple registries
|
||||
description: Integrate UCP with multiple registries
|
||||
keywords: trust, registry, integrate, UCP, DTR
|
||||
redirect_from:
|
||||
- /datacenter/ucp/3.0/guides/admin/configure/integrate-with-multiple-registries/
|
||||
---
|
||||
|
||||
Universal Control Plane can pull and run images from any image registry,
|
||||
including Docker Trusted Registry and Docker Hub.
|
||||
|
||||
If your registry uses globally-trusted TLS certificates, everything works
|
||||
out of the box, and you don't need to configure anything. But if your registries
|
||||
use self-signed certificates or certificates issues by your own Certificate
|
||||
Authority, you need to configure UCP to trust those registries.
|
||||
|
||||
## Trust Docker Trusted Registry
|
||||
|
||||
To configure UCP to trust a DTR deployment, you need to update the
|
||||
[UCP system configuration](ucp-configuration-file.md) to include one entry for
|
||||
each DTR deployment:
|
||||
|
||||
```
|
||||
[[registries]]
|
||||
host_address = "dtr.example.org"
|
||||
ca_bundle = """
|
||||
-----BEGIN CERTIFICATE-----
|
||||
...
|
||||
-----END CERTIFICATE-----"""
|
||||
|
||||
[[registries]]
|
||||
host_address = "internal-dtr.example.org:444"
|
||||
ca_bundle = """
|
||||
-----BEGIN CERTIFICATE-----
|
||||
...
|
||||
-----END CERTIFICATE-----"""
|
||||
```
|
||||
|
||||
You only need to include the port section if your DTR deployment is running
|
||||
on a port other than 443.
|
||||
|
||||
You can customize and use the script below to generate a file named
|
||||
`trust-dtr.toml` with the configuration needed for your DTR deployment.
|
||||
|
||||
```
|
||||
# Replace this url by your DTR deployment url and port
|
||||
DTR_URL=https://dtr.example.org
|
||||
DTR_PORT=443
|
||||
|
||||
dtr_full_url=${DTR_URL}:${DTR_PORT}
|
||||
dtr_ca_url=${dtr_full_url}/ca
|
||||
|
||||
# Strip protocol and default https port
|
||||
dtr_host_address=${dtr_full_url#"https://"}
|
||||
dtr_host_address=${dtr_host_address%":443"}
|
||||
|
||||
# Create the registry configuration and save it
|
||||
cat <<EOL > trust-dtr.toml
|
||||
|
||||
[[registries]]
|
||||
# host address should not contain protocol or port if using 443
|
||||
host_address = $dtr_host_address
|
||||
ca_bundle = """
|
||||
$(curl -sk $dtr_ca_url)"""
|
||||
EOL
|
||||
```
|
||||
|
||||
You can then append the content of `trust-dtr.toml` to your current UCP
|
||||
configuration to make UCP trust this DTR deployment.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Integrate with LDAP by using a configuration file](external-auth/enable-ldap-config-file.md)
|
||||
|
|
@ -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