lol3rrr/hc-vault

A rust library to interact with hashicorp vault

hc-vault's Issues

Client as Trait

Is your feature request related to a problem? Please describe.
Right now when you obtain a Client from this crate, you always have to specify a type for the Auth Part as it is Generic and needs to always be specified, even if it is just as impl Auth.

Describe the solution you'd like
Define the Client interface as a Trait as well and then have every function accept the Client-Trait instead of the Client struct directly. This should remove the extra mental and code overhead when writing functions or types that need to accept a Client, because you can "ignore" the generic Auth type.

Additional context
This switch would lead to a new minor Release as this could Potentiale be a breaking change depending on usage.
This could also make this easier to mock, as you can create a mock implementation of the Trait and use that every where.

Right now you only receive the value itself but nothing related to the lease

Is your feature request related to a problem? Please describe.
Right now when you load something from Vault, like a secret, you only get the actual data itself which is fine most of the time but also gets in the way when this data is only valid for a certain amount of time and you need to know how long it is valid for.

Describe the solution you'd like
That all requests return the parsed Response from vault more directly, so you can easily read all the other data related to that secret from vault.

Additional context
This should mostly be an effort of changing to a uniform response type, as most requests already parse the entire response and could access the other information returned by vault but then only return the data itself with no other metadata related to that piece of information.

Add Renew as well

Is your feature request related to a problem? Please describe.
Right now the Auth-Trait as well as the rest of the system only support obtaining a new session, once the current one has expired. This approach is okay, especially for the beginning, but for certain situations you would ideally want to just renew your current session and not have to get an entirely new one.

Describe the solution you'd like
The RenewPolicy should actually have a Renew field as well, which will also hold the renew threshold. Then the Auth-Trait would need to implement a renew function as well as a function to check if a session needs to be renewed.
Possible functions would be:
fn renew(&self) -> Result<(), Error>, because you don't expect anything to be returned, except possible errors, and the Auth-Backend would internally update its start and duration for the session to align with the new values
fn needs_renew(&self, threshold: u64) -> bool, returns new if the session needs to be renewed, according to the threshold which is in max minutes left before the session expires in this case
fn needs_renew(&self, threshold: f32) -> bool, would act in nearly the same way, with the only difference being that the threshold would be the percentage of time left, so you could just say when the session has less than 25% of its initial duration left, it should be renewed.

This process of checking if the session needs to be renewed should run in a thread in the background, but its yet to be determined at what interval it needs to check