What is right validator trustRoots key?

[jouros]

I'm newbie with these tools and got confused here in DCT and connaisseur configuration. I created docker content trust key with docker trust key generate [name] and got private key in ~/.docker/trust/private/61abc...key and corresponding pub key. Docker created .docker/trust/tuf/[MY REPO]/metadata/root.json plus some other json files. I did docker push with signed image to trust enabled Azure Container Registry without any errors. When I was configuring connaisseur validators trustRoots I tried my previously created pub key which I got from above docker trust key generate and I got error 'unable to find validator configuration' when I tried to do helm install for above signed container. Am I using right key here? Docker did not create any key for which role would be root, only my key for which role is name which I gave to it? Where I can find root key?

Another question is do need root key here in validators trustRoots config or is that my generated pub key which I already used correct key?

Any comments?

Thanks :)

[phbelitz]

Well, well, well. Welcome to the confusing world of Notaryv1.

When you enable Docker Content Trust and push an image, Docker will automatically sign it for you. For that a root and targets key are generated for you, for which you should have entered passphrases, when you first pushed and image with DCT. These keys reside in ~/.docker/trust/private. If you cat them, one of these will say role: root. From this private key, you can get the public one using openssl, BUT you need to remove the role: root annotation. So best copy the key, remove the role: root so the key is pem encoded and then do openssl ec -in <copy-of-root>.key -pubout -out root.pub. This will give you your public root key, which can be used by Connaisseur to validate your signatures.

The error you got from Connaisseur suggests some misconfiguratio on your part. Connaisseur essentially works in a way that there are policy rules (defined in the policy part of the helm/values.yaml) which define image patterns, that try to match to a certain image. If multiple rules would match the image, only the most specific one will win (more details here). This rule will tie the matched image to a validator, since a policy rule can reference the name of a validator (if no validator is referenced in the policy rule, the validator called default is used).

So an example configuration could look like this:

validators:
...
- name: myValidator
  type: notaryv1
  host: notary.docker.io
  trustRoots:
  - name: myRoot
    key: |
      <you-public-root-key>
policy:
...
- pattern: <you-image>:*
  validator: myValidator
  with:
    trustRoot: myRoot

Now thats the gist of it. There are many edge-cases to run into, but maybe this helps for a start, if not, feel free to ask further questions.

Cheers.

[jouros]

Thanks @phbelitz now I got some understanding and right keys into right place. Confusing part here in my case was, that I worked with build agent which does everything in temp folders and keys were missing before I looked into right place, also that openssl cmd was key point, thanks :)