📄️ Caching in Ratify
Ratify supports memory caches and file-based blob caching.
🗃️ crds
5 items
📄️ Dynamic Plugins
While Ratify provides a number of built-in referrer stores and verifiers, there may be times that you need to add additional out-of-tree plugins to verify additional artifact types or check for specific conditions. Whether you've followed the plugin authoring guide, or you want to use a plugin that's provided by a third party, the next step is to make your plugin available to be called at runtime.
📄️ Errors in Ratify
Ratify can generate various errors, either from its core workflow or from external/internal plugins. To facilitate easier debugging, Ratify will throw an error with a code property in most cases. This code can be used to identify the error and provide a more meaningful error message.
📄️ Executor
The executor is the 'glue' that links all Ratify plugin-based components such as the verifiers, referrer stores, and policy providers. The executor handles all components of the verification process once a subject verification request is received either via CLI or server.
📄️ Instrumentation
This page outlines current instrumentation support in Ratify. It also contains guides for installing metrics providers and supported dashboards.
📄️ Logger
Overview
📄️ ORAS Authentication Provider
ORAS handles all referrer operations using registry as the referrer store. It uses authentication credentials to authenticate to a registry and access referrer artifacts. Ratify contains many Authentication Providers to support different authentication scenarios. The user specifies which authentication provider to use in the configuration.
📄️ Performance at Scale
Ratify’s security guarantees rely on its performance at various cluster scales. This document specifies the current ratify performance capabilities. It presents the most recent performance data findings and explains how the data was collected via an automated pipeline.
📄️ Store/Verifier Providers
The framework uses a provider model for extensibility to support different types of referrer stores and verifiers. It supports two types of providers.
📄️ Framework Overview
This specification outlines a workflow of artifact verification which can be utilized by artifact consumers and provides a framework for the Notary project to be consumed by clients that consume these artifacts. The RATIFY framework enables composition of various verifiers and referrer stores to build verification framework into projects like GateKeeper. This framework serves as an orchestrator of various verifiers that are coordinated to get a consolidated verification result using a policy. This verification result can be used to make decisions in admission controllers at different stages like build, deployment or runtime like Kubernetes using OPA Gatekeeper.
📄️ Rego Templates
Rego Policy is much more powerful than Config Poliy, but it's also more complex. To make it easier to write Rego Policy, we provide a few templates for common use cases.
📄️ Store Plugin
Overview
📄️ Usage
This page documents useful flags and options supported by Ratify
📄️ Verification Response
Verification Response is the data returned for external data request calls. As we add new features, the Verification Response may change its format. To make it easy for users and other developers to work with different formats, we have implemented versioning support. This document lists all the versions of the Verification Response that have ever existed and will be updated whenever we make a new change to the format.
📄️ Verifier Specification
Overview
