1ATOMIC(1)                         August 2016                        ATOMIC(1)
2
3
4

NAME

6       atomic-sign- Create a signature for an image
7
8
9       WARNING
10
11
12       Only use atomic sign if you trust the remote registry which contains
13       the image (preferably by being the only administrator of it).
14
15
16

SYNOPSIS

18       atomic sign [-h|--help] [-d, --directory] [--sign-by] [-g, --gnupghome]
19       [ image ... ]
20
21
22

DESCRIPTION

24       atomic sign will create a local signature for one or more local images
25       that have been pulled from a registry. By default, the signature will
26       be written into a directory derived from the registry configuration
27       files as configured by registry_confdir in /etc/atomic.conf.
28
29
30

OPTIONS

32       -h --help
33         Print usage statement.
34
35
36       -d --directory
37         Store the signatures in the specified directory.  Default:
38       /var/lib/atomic/signature
39
40
41       --sign-by
42         Override the default identity of the signature. You can define a
43       default in /etc/atomic.conf
44         with the key default_signer.
45
46
47       -g --gnupghome
48         Specify the GNUPGHOME directory to use for signing, e.g. ~/.gnupg.
49       This
50         argument will override the value of gnupg_homedir in
51       /etc/atomic.conf.
52         Defaults to the homedir or the uid defined in /proc/self/loginuid if
53       it exists, or
54         $SUDO_UID if it is defined, or current UID.
55
56
57

EXAMPLES

59       Sign the foobar image from privateregistry.example.com
60
61
62              atomic sign privateregistry.example.com/foobar
63
64
65
66       Sign the foobar image and save the signature in /tmp/signatures/.
67
68
69              atomic sign -d /tmp/signatures privateregistry.example.com
70
71
72
73       Sign the busybox image with the identify of foo@bar.com with a user's
74       keyring
75
76
77       sudo atomic sign --sign-by foo@bar.com --gnupghome=~/.gnupg
78       privateregistry.example.com
79
80
81

83       The write (and read) location for signatures is defined in YAML-based
84       configuration files in /etc/containers/registries.d/.  When you sign an
85       image, atomic will use those configuration files to determine where to
86       write the signature based on the the name of the originating registry
87       or a default storage value unless overriden with the -d option. For
88       example, consider the following configuration file.
89
90
91       docker:
92         privateregistry.example.com:
93           sigstore: file:///var/lib/atomic/signature
94
95
96       When signing an image preceeded with the registry name
97       'privateregistry.example.com', the signature will be written into
98       subdirectories of
99       /var/lib/atomic/signature/privateregistry.example.com. The use of
100       'sigstore' also means the signature will be 'read' from that same
101       location on a pull-related function.
102
103
104       You can also scope the registry definitions by repository and even
105       name.  Consider the following addition to the configuration above.
106
107
108       privateregistry.exaple.com/john:
109           sigstore-staging: file:///mnt/export/signatures
110           sigstore: ⟨https://www.example.com/signatures/⟩
111
112
113       Now any image from the john repository will use the sigstore-staging
114       location of means that signatures should be written to that location
115       but read should occur from the http URL provided.
116
117
118       The user's keyring will be used during signing. When running as root
119       user this may not be desired. Another keyring may be specified using
120       environment variable GNUPGHOME, passed in via argument --gnupghome or
121       set in configuration file atomic.conf. For example:
122
123
124       gnupg_homedir: /home/USER/.gnupg
125
126
127

HISTORY

129       Initial revision by Brent Baude (bbaude at redhat dot com) August 2016
130       Updated by Brent Baude (bbaude at redhat dot com) September 2016
131       Updated by Aaron Weitekamp (aweiteka at redhat dot com) September 2016
132
133
134
135Brent Baude                     Atomic Man Pages                     ATOMIC(1)
Impressum