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
@@ -159,15 +159,16 @@ The following steps show how to create a self-signed signing certificate for tes
159
159
2. Create the certificate.
160
160
161
161
```azure-cli
162
-
az keyvault certificate create -n $KEY_NAME --vault-name $AKV_NAME -p @my_policy.json
162
+
az keyvault certificate create -n $CERT_NAME --vault-name $AKV_NAME -p @my_policy.json
163
163
```
164
164
165
165
## Sign a container image with Notation CLI and AKV plugin
166
166
167
-
1. Build and push a new image with ACR Tasks.
167
+
1. Build and push a new image with ACR Tasks. Always use digest to identify the image for signing, because tags are mutable and and can be overwritten.
2. Authenticate with your individual Azure AD identity to use an ACR token.
@@ -181,10 +182,10 @@ The following steps show how to create a self-signed signing certificate for tes
181
182
> [!NOTE]
182
183
> If notation login is failing, you may need to Configure a credentials store. Alternatively in development and testing environments, you can use environment variables to authenticate to an OCI-compliant registry. See guide [Authenticate with OCI-compliant registries](https://notaryproject.dev/docs/how-to/registry-authentication/) for details.
183
184
184
-
3. Get the Key ID of the signing key.
185
+
3. Get the Key ID of the signing key. A certificate in AKV can have multiple versions, the following command get the Key Id of the latest version.
4. Sign the container image with the [COSE](https://datatracker.ietf.org/doc/html/rfc8152) signature format using the signing key id. To sign with a self-signed certificate, you need to pass a plugin configuration `self_signed=true` in the command line.
@@ -226,7 +227,7 @@ To verify the container image, you need to add the root certificate that signs t
226
227
227
228
4. Configure trust policy before verification.
228
229
229
-
Trust policies allow users to specify fine-tuned verification policies. Use the following command to configure trust policy. Upon successful execution of the command, one trust policy named `wabbit-networks-images` is created. This trust policy applies to all the artifacts stored in repositories defined in `$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`. See [Trust store and trust policy specification](https://github.com/notaryproject/notaryproject/blob/v1.0.0/specs/trust-store-trust-policy.md) for details.
230
+
Trust policies allow users to specify fine-tuned verification policies. Use the following command to configure trust policy. Upon successful execution of the command, one trust policy named `wabbit-networks-images` is created. This trust policy applies to all the artifacts stored in repositories defined in `$REGISTRY/$REPO`. Assuming that the user trusts a specific identity with the X.509 subject `$CERT_SUBJECT`, which is used for the signing certificate. The named trust store `$STORE_NAME` of type `$STORE_TYPE` contains the root certificates. See [Trust store and trust policy specification](https://github.com/notaryproject/notaryproject/blob/v1.0.0/specs/trust-store-trust-policy.md) for details.
0 commit comments