The framework should support cosign verification with ECR at this point and would focus on getting a walkthrough before we release an alpha of this project.

The goal here is to showcase that ratify successfully runs on AWS with current capabilities without having to host external components like a fork of distribution or going to ACR that supports Reference Artifacts.

AWS planning support for References artifacts and moving to Notary for EKS should be a config update from the sample perspective.

For e.g.

Enable policy evaluation using OPA as specified in the spec https://github.com/deislabs/hora/tree/main/docs#executor-policy-specification

• Define test CLI for inner loop
• Define the docs of how to locally validate.

default value in config.json is <cert folder> which is not valid when example cert is mount at /usr/local/wa-certs

time="2021-11-16T23:03:11Z" level=info msg="configuration successfully loaded."
time="2021-11-16T23:03:11Z" level=info msg="stores successfully created. number of stores 1"
Error: open <cert folder>: no such file or directory

where it gets copied: https://github.com/deislabs/ratify/blob/main/httpserver/Dockerfile#L26

Currently the tests aren't executing as a part of the PR validation. Makefile currently doesn't invoke all the tests .

The files are as per the old GK spec and is no longer relevant

We can consider kubectl apply directly without cloning the repo for the demo constraints and a published chart as per feedback from @sozercan
#98 (comment)

see example: https://github.com/open-policy-agent/gatekeeper/blob/master/test/externaldata/dummy-provider/manifest/provider.yaml

For being able to try our ratify quickly, we can provide a simple unified helm chart that combines the gatekeeper external data provider with Ratify.

In the current referrers list below there are multiple signatures -

❯ hora referrer list -s localhost:5000/net-monitor@sha256:e35755f713320922144f3bff9f0f78ceb53fc048b0a0b755d2bf296476b26f1c
sha256:e35755f713320922144f3bff9f0f78ceb53fc048b0a0b755d2bf296476b26f1c
└── ociregistry
    ├── [application/x.example.sbom.v0]sha256:a3da10a5c5ee46f9dbb05f98601497d6d42f95174940355a2d583b5362ed57db
    │   └── [application/vnd.cncf.notary.v2]sha256:407387541c983349b1b8b5d495ea67a664dfddce86ca507890d6a726a4a5eb89
    ├── [application/vnd.cncf.notary.v2]sha256:54c40024407516cb20fe6dd6897755fc75f936549dba716a163b8466b3c33c7c
    ├── [application/vnd.cncf.notary.v2]sha256:99f7614613f8d6656167cf356a1ef817775b941f7e144013f08a758bdefb3069
    └── [application/vnd.cncf.notary.v2]sha256:b710b362ba2483b457f623ef19049bf1bb5cd4c75691e4fb4305d993efa2cb07

There may be invalid signatures in this case but the only requirement here is that the is atleast one valid signature as per configuration policy.

There maybe a possibility of requiring multiple signatures. For e.g. we want to ensure that an image is signed by docker hub and also by your QA environment. We can track the multi signature configuration in another issue.

We can use the library as soon as the issue is tagged - notaryproject/notation-go#19

For. e.g.
`ratify plugin new --name PLUGIN_NAME --type [executable/GPRC] -o

see example on how to batch: https://github.com/open-policy-agent/gatekeeper/blob/master/test/externaldata/dummy-provider/policy/template.yaml#L17

Consider other fields in the verification results response

1. The response needs to identify that requesting digest
2. Success should indicate which is the reference that was actually verfified.

{
  "isSuccess": true,
  "verifierReports": [
    {
      "IsSuccess": false,
      "Name": "nv2verifier",
      "Results": [
        "verification failure: x509: certificate signed by unknown authority"
      ]
    },
    {
      "IsSuccess": false,
      "Name": "nv2verifier",
      "Results": [
        "verification failure: x509: certificate signed by unknown authority"
      ]
    },
    {
      "IsSuccess": true,
      "Name": "nv2verifier",
      "Results": [
        "Notary verification success"
      ]
    }
  ]
}

• agree on the release name (v0.1.1)
• create a branch named v0.1.1 with everything to be released
• #94
• create a signed tag named v0.1.1 and push
• verify release looks correct and publish

The store "oras" is made a built in plugin in the framework. This model breaks the access of this store to the external plugins like sbom verifier. Current code base for sbom verifier is not functional and has to be fixed

The referrers store can support looking at different locations. Cosign uses tag naming scheme and can be implemented through the referrers store which can discover the related tag and download the reference and provide to the verifier.

The quick-start process currently involves installing Gatekeeper from "source" (it uses prebuilt container images but needs the build process to render the Kubernetes manifests) and using our repo's makefile to install things in the correct order.

We should try to have a single chart experience so that it is easy for users to install Ratify.

This will involve the following:

• Having Gatekeeper added as a dependency of the Helm chart
• Having all Ratify resources installed as part of a single Helm chart
• Ensuring that proper resource deployment order is followed so that the ConstraintTemplate is deployed and ready before the Constraint is applied

Current blockers for this are:

• External data provider feature working in upstream Gatekeeper Helm chart
• A proper ordering mechanism for Helm to be able to manage Gatekeeper ConstraintTemplates and Constraints

1. agree on the release name (v0.1.0)
2. create a branch named v0.1.0 with everything to be released
3. create a signed tag named v0.1.0 and push
4. verify release looks correct and publish

Currently the CLI doesn't support showing the version. It would be useful to have the CLI and plugins show this information

➜ ratify version
Version:        0.2.0-alpha.1
Go version:     go1.16.2
Git commit:     f01d9.....
Git tree state: clean

As an extensibility scenario, create a prototype that show cases of how TUF metadata that is persisted in OCI registry using the artifacts model can be fetched and verified using TUF tools

Goals

1. Enable developers to get quickly started on AKS
2. Ensure they have an ability to deploy using simple commands. For e.g. helm install a complete e2e with the provider enabled and good defaults for signature validation.
3. Ensure there is a test image that they can validate and view logs to see the validation results.

https://hackmd.io/LFWPWM7wT_icfIPZbuax0Q

The concept here is to show a standalone deployment model that does not have any cloud provider requirements.

https://github.com/deislabs/ratify/blob/main/httpserver/Dockerfile#L17

Ideally this should be distroless/static or scratch

Scan results and other references may get updated. The framework should support ensuring that artifacts that have passed successful verification can be reverified on a timely manner.

This may involve keeping track of verified artifacts as a journal and reverify them.

This issue needs more details to identify how hora can handle stale artifacts. Should we depend on things like signature expiry or should we focus ensuring that the referrers store can return only the newest of an artifact?

If notation has the support to enable remote signature verification we would be able to leverage that. Currently notation doesn't have libraries that support Azure Key Vault. This model will also be used for remote signature verification for other cloud providers.

Need to checkin these into the repo under the docs folder -

Framework Spec: https://hackmd.io/9htAyk-OQmauWPnNqMTVIw?view
Store Plugin Spec: https://hackmd.io/wkAGhJgQSCaX4ln9CrXo_w
Verifier Plugin Spec: https://hackmd.io/ReuaHddWSDq4gaKyUofa7w

/cc @mnltejaswini

Ratify should default failure.

1. Update timeout to a shorter interval to fail the deployment.
2. Ensure that the signature is still requested so that the next deployment can succeed with a cached request.

Any references that should be excluded from the verification pipeline.
There needs to be configuration section that ensures that a warning is emitted since its successful though break glass exception processing and not through standard verification.

• https://github.com/deislabs/hora/tree/main/docs#break-glass

so users don't have to clone the repo to install the chart
example gh action: https://github.com/stefanprodan/helm-gh-pages

Write the threat model document for Hora. This is mainly along invoking plugins from the framework, trusting the outputs returned by them.

Only the sbom plugin is included in the current release packaging. We need to determine which plugins are released and where/how they are packaged.

Plugins can be custom (out or proc) executables and can be discovered by convention or path configured in the configuration provided to hora(CLI/Server)
Builtin plugins are executed as interfaces. We can consider if a custom plugin can communicate through GRPC which would require us to define a GPRC interface for plugins.

When config.json specifies

                "verificationCerts": [
                    "~/.config/notation/certificate/wabbit-networks.io.crt"
                  ]

ratify verify can't find that file:

$ ratify verify -s $IMAGE_DIGEST_REF                                                                                                                                                                                                                                                                    
Error: open ~/.config/notation/certificate/wabbit-networks.io.crt: no such file or directory

even if the file exists:

$ cat ~/.config/notation/certificate/wabbit-networks.io.crt                                                                                                                                                                                                                 
-----BEGIN CERTIFICATE-----
...

Changing to absolute path in config.json resolves this issue.

There are a few options here -

1. Use a mutation controller
2. Support the framework to resolve the tag.

These walkthrough #55 #59 will walkthrough.

Getting the capability in ORAS - would be a good option - oras-project/oras-go#40 (comment)

As part of the release we need to support publishing the image to GHCR.
The helm chart will also have to use the image.

Enable an extensible model so that plugin specific implementations resolve configuration dynamically. For e.g. the notary verifier might need to acquire keys from Vault or AzureKV and the values for these would have to be passed in during initialization and need not be hard coded in file. Another scenario is that they location of the vault might be different in different environment and so having a base configuration that can be injected with dynamic values enables developers to checkin a template configuration and environment configuration(variables) can provide the actual location of the vault endpoint.

• E.g. how to enable adding a break glass by adding exception to an image without redeploying a full configuration.

Items to accomplish this:

• #215 - File watcher based implementation
• #193