68 lines
2.7 KiB
XML
68 lines
2.7 KiB
XML
== System Design
|
|
|
|
=== Clients
|
|
|
|
The rvault server is compliant with any client acting in compliance with the hashicorp vault api specification.
|
|
To achieve this, tests are written using the official Hashicorp vault go client.
|
|
|
|
=== Webserver
|
|
|
|
The Webserver forwards client requests to different routers according to the request paths:
|
|
i.e. "/v1/auth" for the authorization router.
|
|
Those routers map request to their corresponding handlers.
|
|
|
|
Problem:
|
|
- TODO describe middleware
|
|
|
|
=== Engines
|
|
|
|
|
|
|
|
=== Storage
|
|
|
|
Engines:
|
|
|
|
Der Engines Ordner enthält Subfolder
|
|
für die jeweilige Engine unterteilt
|
|
in Logik, Structs unt Tests
|
|
|
|
|
|
Storage:
|
|
|
|
Momentan beschränken wir uns auf SQLite
|
|
über SQLX ohne ORM
|
|
|
|
#figure(
|
|
image("../../assets/Design.svg", width: 80%),
|
|
caption: [
|
|
The acting components of rvault.
|
|
],
|
|
)
|
|
|
|
=== Design decisions
|
|
|
|
|
|
|
|
// + The API to implement e.g. has the concept of mount points (similar to how filesystems can be mounted on UNIX-like systems).
|
|
// Mount points can contain multiple slashes.
|
|
// For example `/v1/some/mount/point/data/some/path/secret` may consist of a mount point `some/mount/point` and further, following routes of the mapped secret engine. //TODO
|
|
// In this example, `/data` is related to the Key-Value engine and `/some/path/secret` specifies a path within the secret engine instance mounted at the mount point.
|
|
// This implies a significant problem:
|
|
// How to determinate what part of the URL displays a mount point, where it is not certan, what the postfix of the URL will be (this problem follows).
|
|
|
|
// + Another problem is that based on the mount point, the request must be processed by the applicable secret engine.
|
|
// Based on context, stored on the DBMS, the request must be passed to the secret engine along with the determinated mount point.
|
|
|
|
=== Solution
|
|
|
|
// Secret Engines have their dedicated router.
|
|
// The main router has an instance of these routers along with the database pool wrapped within a struct in its state.
|
|
// The router instances have a reference to the database pool, which is internally wrapped by an Atomic Reference Counter (`Arc`).
|
|
|
|
// Upon a requst, the remaining path is obtained (via `/+mount_path`).
|
|
// Then, the path is looked up at the database, also requsting the engine type.
|
|
// If not found, the last last slash character and the following string is removed and looked up again. This is repeated, until the path either is found or has a length of zero, rejecting the request as "404 Not Found".
|
|
|
|
// If found, the router is called with the request and mount path is given to the router as an "Extension".
|
|
// The `call` #link("https://docs.rs/tower/0.4.13/tower/trait.Service.html#tymethod.call")[(link)]
|
|
// function which Axum routers inherit from the Tower crate, allows to hand the request over to engine's router.
|