Double-checking the expected behavior with rego policy & passthrough enabled

[cmaclaughlin]

The following is what I'm seeing using Ratify v1.1 (Helm chart v1.12.0):

• isSuccess is always false.
• If the subject image lacks any referrers, the response body is similar to that with passthrough-mode disabled: the only properties are version & isSuccess.
• If there were reference artifacts, the specific results are included with the verifierReports property. With isSuccess always false, it is (expectedly) up to the constraint template rego to handle differentiating between success and failure.

To be clear, the primary value I am currently finding with passthrough mode is to be able to expose the error message(s) as a part of Gatekeeper denial instead of needing to parse / view the logs.

[akashsinghal]

@cmaclaughlin yes your observations are inline with expected behavior based on current implementation. The primary purpose of passthroughEnabled property on the rego policy provider is to decide exactly where the rego policy is applied to determine the overall verification of the result. If pass through is enabled, the rego provided to Ratify directly (via the policy CRD) is ignored because it's assumed Gatekeeper will apply more involved rego (constraint template) to parse the verifier reports to determine the overall result on its own. You're right that if you try to use Gatekeeper with pass through enabled, then the GK constraint template can bubble up errors/policy violations more clearly.

Rego policy on its own without pass through is crucial for non K8s scenarios where GK is out of the picture.

[akashsinghal]

regarding the no referrers found error, it's a known confusion and we're trying to figure out a better way to return this error in the report. We have a tracking item and a note in the code to fix this issue. #1321 and there's a note in the code too: https://github.com/deislabs/ratify/blob/b0dfc90d38eb508977f988bb539d591f250bba2d/pkg/executor/core/executor.go#L66