search

ratify-project / ratify

Artifact Ratification Framework
https://ratify.dev
Apache License 2.0
210 stars 58 forks source link

Enable Service-to-Service Communication using gRPC or HTTP(s) #191

Open lee0c opened 2 years ago

lee0c commented 2 years ago

This could be either alongside or in replacement to the current plugin system. Let's discuss further gRPC vs HTTP(s) and which we'd prefer.

This supports K8s-native function and allows for better extensibility in a K8s ecosystem where moving binaries around is much more of a hassle.

susanshi commented 2 years ago

This would make debugging verifier significantly easier. Would be great to have data on performance comparison between subprocess ( current) / gRPC/ HTTPS to understand performance implication.

cmaclaughlin commented 1 year ago

Although initial proto files have been committed, this issue is no longer being actively worked. Since time was spent thinking through implementation, here are a few things we feel would benefit from additional thought and discussion if/when someone picks this up again.

  1. Make sure the feature has enough demand that it is worth the effort to implement. These aren’t small changes.
  2. Discoverability and configuration. What should Ratify plugin discovery look like? Should the full address of the gRPC plugin be provided when the plugin is registered or should the plugin be deployed so Ratify can use named sockets? The named sockets approach would align with the current iteration over paths + names used for binary plugins (see the Kubernetes Secret Store CSI Driver provider client). For plugin-specific custom configuration, in an ideal world, all plugins (binary or service, verifier or store) would be developed to support multi-tenancy out of the box. In that case, there could be a requirement to identify the appropriate version of a plugin's configuration based on the request – like an auth provider for ORAS. Having different configurations of the same plugin available at the same time would need to be considered for binary plugins as well and is likely a larger conversation. We do think it makes sense for the various plugin configurations to be in the same form as what the deployed instance of Ratify is already using – currently this is either JSON or CRDs, but there are other possibilities depending on how and where Ratify is running: environment variables/secrets/YAML.
  3. Authentication. What, if any, authentication should there be between Ratify and gRPC service plugins? The CSI Driver provider interface only secures connections through filesystem ACLs. If there is a desire to support TLS/mTLS like Gatekeeper, this introduces additional complexity. The overhead would probably be the responsibility of the operator running Ratify and the plugin, but this would need to be clearly documented/communicated/stated. If mTLS was chosen or preferred, when the plugin is registered with Ratify, the appropriate CA bundle would need to be provided to Ratify as Ratify does when registering as an external data provider for Gatekeeper.
  4. Scalability. Gatekeeper runs as a singleton in a Kubernetes cluster. Unless that changes, presumably Ratify would run as a singleton as well. To ensure plugins can handle requisite loads, what, if any, design guidelines or technical specifications are required? Along the same lines, due to the Gatekeeper timeout limits, service plugins must be running in-cluster. Presumably, OPA Agents would have similar time constraints for external data providers. How does this translate to deployment or operations requirements?
  5. Other open questions. Will Ratify always support gRPC plugins or will there be specific cases/environments e.g. when an http server is running? Are there specific scenarios where gRPC is preferred over binary subprocesses? Should gRPC plugins always be deployed as standalone services or does it make sense to run them in a sidecar to Ratify?