Ratify has reached its first major release in over a year and has been widely adopted by users at scale. However, there are some know limitations in the current design and implementations of Ratify v1 that make it difficult to support more user scenarios/new features and enhance performance. These constraints make it challenging to attract more users and contributors. This discussion will compare the current architecture of Ratify v1 with the proposed v2 design to gather feedback and insights on the new approach.
The current architecture of Ratify v1:
From the above diagram, we can see a few limitations:
Ratify only supports CLI and K8s scenarios. But actually current Ratify is only well implemented/designed for K8s scenarios. There are some feature gaps between CLI and K8s implementations.
Ratify was designed to validate security metadata of any given artifacts. But right now Ratify is mainly focusing on the K8s scenarios with images being verified.
The plugin framework was designed to separate built-in and external plugins. Built-in plugins run in the same process of Ratify while each external plugin would be executed in a new subprocess. Therefore, external plugins cannot share the in-momory cache with the main process, which may result to performance degradation , data inconsistency and even race condition.
The built-in plugins are part of the main Ratify repository, which introduces a significant number of dependencies. This issue will become even more pronounced as support for additional cloud providers is added in the future.
Converting config.json from the CLI to Kubernetes CRs is not straightforward for users, increasing the learning cost for new users.
To address the above limitations, one possible v2 design is as below:
The key design principles are as follows:
Extract the Ratify core library to focus solely on its primary functionality: validating the security metadata of artifacts. Consequently, the mutation API may be removed from the core library.
The Ratify core library can support additional use cases, such as offering a gRPC service, running as a standalone service, or integrating as a library into other downstream services.
All plugins would be regarded as external plugins and moved out of the Ratify core repo.
The Ratify main process and external plugins would require some IPC mechanism to communicate. The above diagram shows an option through gRPC. We can also use pipe to communicate for better performance.
The configuration CRD needs to be redesigned to allow seamless conversion to config.json for other use cases.
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this feature?
What would you like to be added?
Ratify has reached its first major release in over a year and has been widely adopted by users at scale. However, there are some know limitations in the current design and implementations of Ratify v1 that make it difficult to support more user scenarios/new features and enhance performance. These constraints make it challenging to attract more users and contributors. This discussion will compare the current architecture of Ratify v1 with the proposed v2 design to gather feedback and insights on the new approach.
The current architecture of Ratify v1:
From the above diagram, we can see a few limitations:
To address the above limitations, one possible v2 design is as below:
The key design principles are as follows:
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this feature?