You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/container-registry/container-registry-tutorial-sign-build-push.md
+79-58Lines changed: 79 additions & 58 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author: dtzar
5
5
ms.author: davete
6
6
ms.service: container-registry
7
7
ms.topic: how-to
8
-
ms.date: 10/11/2022
8
+
ms.date: 12/12/2022
9
9
---
10
10
11
11
# Build, sign, and verify container images using Notary and Azure Key Vault (Preview)
@@ -24,20 +24,17 @@ In this tutorial:
24
24
25
25
## Prerequisites
26
26
27
-
> * Install, create and sign in to [ORAS artifact enabled registry](./container-registry-oras-artifacts.md#create-oras-artifact-enabled-registry)
27
+
> * Install, create and sign in to OCI artifact enabled registry ACR
28
28
> * Create or use an [Azure Key Vault](../key-vault/general/quick-create-cli.md)
29
29
>* This tutorial can be run in the [Azure Cloud Shell](https://portal.azure.com/#cloudshell/)
30
30
31
31
## Install the notation CLI and AKV plugin
32
32
33
-
> [!NOTE]
34
-
> The tutorial uses early released versions of notation and notation plugins.
35
-
36
-
1. Install notation 0.11.0-alpha.4 with plugin support on a Linux environment. You can also download the package for other environments from the [release page](https://github.com/notaryproject/notation/releases/tag/v0.11.0-alpha.4).
33
+
1. Install notation v1.0.0-rc.1 with plugin support on a Linux environment. You can also download the package for other environments from the [release page](https://github.com/notaryproject/notation/releases/tag/v1.0.0-rc.1).
# Copy the notation cli to the desired bin directory in your PATH
@@ -48,15 +45,15 @@ In this tutorial:
48
45
49
46
> [!NOTE]
50
47
> The plugin directory varies depending upon the operating system being used. The directory path below assumes Ubuntu.
51
-
> Please read the [notation config article](https://github.com/notaryproject/notation/blob/main/specs/notation-config.md) for more information.
48
+
> Please read the [notation config article](https://github.com/notaryproject/notaryproject.dev/blob/main/content/en/docs/how-to/directory-structure.md) for more information.
If you have an existing certificate, upload it to AKV. For more information on how to use your own signing key, see the [signing certificate requirements.](https://github.com/notaryproject/notaryproject/blob/main/specs/signature-specification.md#certificate-requirements)
101
+
If you have an existing certificate, upload it to AKV. For more information on how to use your own signing key, see the [signing certificate requirements.](https://github.com/notaryproject/notaryproject/blob/v1.0.0-rc.1/specs/signature-specification.md)
105
102
Otherwise create an x509 self-signed certificate storing it in AKV for remote signing using the steps below.
106
103
107
104
### Create a self-signed certificate (Azure CLI)
108
105
109
106
1. Create a certificate policy file.
110
107
111
-
Once the certificate policy file is executed as below, it creates a valid signing certificate compatible with **notation**in AKV. The EKU listed is for code-signing, but isn't required for notation to sign artifacts.
108
+
Once the certificate policy file is executed as below, it creates a valid signing certificate compatible with **notation**in AKV. The EKU listed is for code-signing, but isn't required for notation to sign artifacts. The subject is used later as trust identity that user tursts during verification.
112
109
113
110
```bash
114
111
cat <<EOF > ./my_policy.json
@@ -121,44 +118,60 @@ Otherwise create an x509 self-signed certificate storing it in AKV for remote si
121
118
"ekus": [
122
119
"1.3.6.1.5.5.7.3.3"
123
120
],
124
-
"subject": "CN=${KEY_SUBJECT_NAME}",
121
+
"keyUsage": [
122
+
"digitalSignature"
123
+
],
124
+
"subject": "$CERT_SUBJECT",
125
125
"validityInMonths": 12
126
126
}
127
127
}
128
128
EOF
129
129
```
130
130
131
-
1. Create the certificate.
131
+
2. Create the certificate.
132
132
133
133
```azure-cli
134
134
az keyvault certificate create -n $KEY_NAME --vault-name $AKV_NAME -p @my_policy.json
3. Choose [COSE](https://datatracker.ietf.org/doc/html/rfc8152) or JWS signature envelope to sign the container image.
180
-
181
-
- Sign the container image with the COSE signature envelope:
192
+
3. Sign the container image with the [COSE](https://datatracker.ietf.org/doc/html/rfc8152) signature format using the signing key added in previous step.
4. View the graph of signed images and associated signatures.
199
+
200
+
```bash
201
+
notation ls $IMAGE
202
+
```
194
203
195
-
ACR support for ORAS artifacts enables a linked graph of supply chain artifacts that can be viewed through the ORAS CLI or the Azure CLI.
204
+
## [Option] View the graph of artifacts with the ORAS CLI
205
+
206
+
ACR support for OCI artifacts enables a linked graph of supply chain artifacts that can be viewed through the ORAS CLI or the Azure CLI.
196
207
197
208
1. Signed images can be view with the ORAS CLI.
198
209
@@ -201,15 +212,15 @@ ACR support for ORAS artifacts enables a linked graph of supply chain artifacts
201
212
oras discover -o tree $IMAGE
202
213
```
203
214
204
-
## View the graph of artifacts with the Azure CLI
215
+
## [Option] View the graph of artifacts with the Azure CLI
205
216
206
217
1. List the manifest details for the container image.
207
218
208
219
```azure-cli
209
220
az acr manifest show-metadata $IMAGE -o jsonc
210
221
```
211
222
212
-
2. Generates a result, showing the `digest` representing the notary v2 signature.
223
+
2. Generates a result, showing the `digest` representing the notary v2 signature.
213
224
214
225
```json
215
226
{
@@ -230,29 +241,39 @@ ACR support for ORAS artifacts enables a linked graph of supply chain artifacts
230
241
231
242
## Verify the container image
232
243
233
-
1. The notation command can also help to ensure the container image hasn't been tampered with since build time by comparing the `sha` with what is in the registry.
The trust policy is a JSON document named `trustpolicy.jsoin`, which is stored under notation configuration directory. Users who verify signed artifact from a registry use the trust policy to specify trusted identities which sign the artifacts, and level of signature verification to use.
247
+
248
+
Use the following command to configure trust policy for this tutorial. Upon successful execution of the command, one trust policy named `wabbit-networks-images` is created. This trust policy applies to all the artifacts stored under repository `$REGISTRY/$REPO`. The trust identity that user trusts has the x509 subject `$CERT_SUBJECT` from previous step, and stored under trust store named `$STORE_NAME` of type `$STORE_TYPE`.
248
249
249
-
We can see that verification still passes because `notation verify` will implicitly pass with _any_ certificate in its trust store. To get a verification failure, we'll remove the certificate utilized to sign the image.
2. The notation command can also help to ensure the container image hasn't been tampered with since build time by comparing the `sha` with what is in the registry.
250
272
251
-
```azure-cli
252
-
notation cert rm $KEY_NAME
253
-
notation verify $IMAGE
254
-
2022/06/10 11:24:30 verification failure: x509: certificate signed by unknown authority
255
-
```
273
+
```bash
274
+
notation verify $IMAGE
275
+
```
276
+
Upon successful verification of the image using the trust policy, the sha256 digest of the verified image is returned in a successful output messages.
0 commit comments