serokell / coffer

Multi-backend password store with multiple frontends
4 stars 2 forks source link

Remote Backend #56

Open MagicRB opened 2 years ago

MagicRB commented 2 years ago

Clarification and motivation

A special backend which exposes a HTTP coffer instances backend as a local backend. The use case is having a remote coffer instance which accesses some internal service, for example vault and using that from the CLI. It would essentially be equivalent to the current web frontend but in the terminal.

Acceptance criteria

New functional remote backend and associated tests.

dcastro commented 2 years ago

The coffer server may itself have multiple other backends - how would that work?

The way I see it, it should work like this:

Say you have a config.toml:

main_backend = "bk1"

[[backend]]
type = "vault-kv"
name = "bk1"
address = "localhost:8200"
mount = "secret"
token = "<vault token>"

[[backend]]
type = "coffer-server"
address = "<some address>"
token = "<some credentials or whatever>"

What do you think?

dcastro commented 2 years ago

BTW, this issue is blocked by #37

dcastro commented 2 years ago

Actually, what I proposed above may lead to ambiguity, e.g., when config.toml contains config for two different coffer-servers, and both have a backend with the same name.

This means that a coffer-server config really does need a name, and that the user should specify which coffer-server and which of its backends they want to use, e.g.:

[[backend]]
type = "coffer-server"
name = "cs1"
...

[[backend]]
type = "coffer-server"
name = "cs2"
...
$ coffer view cs1/bk1#some/path
$ coffer view cs2/bk1#some/path
MagicRB commented 2 years ago

Yeah, i was thinking

[[backend]]
type = "coffer-server"
name = "cs1"
remote-name = "vault"

What were missing is authentication, that's a pretty big part

dcastro commented 2 years ago
remote-name = "vault"

That would imply the user would "have to" re-declare each and every backend, right? If the server has 3 configured backends, the user would have to declare 3 [[backend]]s on their local config file, right?

I think the auto-discovery I proposed would be a lot easier to configure. On the other hand, it would also make it slightly harder to use commands (e.g. coffer create cs1/bk1#path instead of coffer create cs1#path).

I guess both approaches have both pros and cons, I'm okay with either approach.

dcastro commented 2 years ago

@DK318 and @Heimdell: what do you think?

MagicRB commented 2 years ago

I guess both approaches have both pros and cons, I'm okay with either approach.

What i was thinking is that first we'd do approach one and then implicitly auto generate the remote backends and merge them implicitly with the users config file

MagicRB commented 2 years ago

So the auto import would be a continuation of this

dcastro commented 2 years ago

Let's postpone this issue until we have a fully ready MVP.