Skip to content

Resolver Plugin (Plugin System V0) #2

@joe0BAB

Description

@joe0BAB

The resolver part of the secrets engine needs to dynamically load providers which would expose information to the underlying secret store. A provider has the ability to set a TTL, do custom logic and map between what is asked for and what is available.

Image

Features:

Resolver

A resolver resolves secrets from registered providers. In some cases the secrets engine would register providers that are included by default, for example the Docker CLI might be a provider that is always registered. Custom providers could be executable binaries stored inside the predefined plugins directory or standalone services that register themselves with the Secrets Engine directly.

Provider

A provider is a thin wrapper around a key-value store. Where the store runs or how it functions is completely opaque to the secrets engine resolver. For example, a bitwarden provider might be an HTTP client doing requests to a remote endpoint.
Each provider has the responsibility of managing their own secrets, this includes doing OAuth access token refreshes, setting the correct Time-To-Live (TTL) and perhaps transforming keys into the expected format.

Plugins

Due to the dynamic nature of a provider, we need a way to have two way communication between the secrets engine and the provider without requiring that the provider be compiled inside the same binary. Nor should it be necessary for a provider to be of the same language as the secrets engine.

The plugin system would be a server-to-server architecture and manage plugins over GRPC. The communication data structure is defined with Protobuf, ensuring cross-language support while being strict on types. The lifecycle of a plugin is managed by the secrets engine and at any time can a plugin be shutdown or started.

It consists of two parts:

  • adaptation: essentially this is the daemon process that manages plugins and communication. It will start plugins, configure them and shut them down on exit
  • stub: This is a bit of library code that will be used for anyone who writes a plugin.

We are taking inspiration from how plugins are implemented in NRI but replace the custom TTRPC layer with standard GRPC / Protobuf edition 2023.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No fields configured for Epic.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions