HashiCorp Vault feature

[soleinik-figment]

In brief

This change adds support for HashiCorp Vault, Transit Engine.

Currently there are few signing providers available - HSMs, SaaS and softsign. This change will add support for HashiCorp Vault - an identity-based secrets and encryption management system

What's the usecase?

Vault provides Encryption as a Service (EaaS) to enable security teams to fortify data during transit and at rest. So even if an intrusion occurs, your data is encrypted and the attacker would never get a hold of the raw data. In addition, Vault provides networked access, software based general purpose secure storage for any sensitive information, such as keys, password or certificates.

[mkaczanowski]

great feature, looking forward to see this PR reviewed and merged

[cloudnull]

This is a fantastic addition. Well done.

[tony-iqlusion]

It looks like this is pulling in an old version of hyper as a transitive dependency of reqwest, which is breaking the security audit.

It also looks like there's a PR open to update reqwest which has been open since July 2021 with no response from the maintainer: ChrisMacNaughton/vault-rs#57

Is the hashicorp_vault crate actually maintained?

[soleinik-figment]

let's see if I get PR merged

ChrisMacNaughton/vault-rs#59

[soleinik-figment]

"hashicorp_vault" dependency is replaced with "ureq" - A simple, safe HTTP client.

[tony-iqlusion]

@soleinik-figment thanks, that eliminates the concern with the unmaintained dependency.

I'll try to look at this in-depth soon.

[soleinik-figment]

@tony-iqlusion is there anything that I can help with to get this PR merged?

[helder-moreira]

@soleinik-figment would be great to have TLS support for production systems.

[soleinik]

@helder-moreira configuring api_endpoint configuration property with https
api_endpoint= "https://127.0.0.1:8200"
would enable TLS comm to Vault

[helder-moreira]

@helder-moreira configuring api_endpoint configuration property with https api_endpoint= "https://127.0.0.1:8200" would enable TLS comm to Vault

But a CA certificate is required. I have done it here.

[mkaczanowski]

It would be nice to let the access_token to be read from the file, for instance:

tmkms/src/config/provider/yubihsm.rs

Line 57 in ed24642

pub enum AuthConfig {

[tony-iqlusion]

@soleinik-figment are you still interested in landing this, and if so, can you rebase?

[mkaczanowski]

(if no one is interested I am willing to rebase this) I think this is great feature

[soleinik]

Go ahead Mateusz... I wont be able to work on this

[helder-moreira]

I also think this is a great feature. I tried to do it myself but I don't know Rust enough. This was actually my first contact with Rust.

I have a variation of this branch here if it helps somehow. Its the one we are using. It adds the option to specify a CA certificate, and replaces access_token with token_file to specify a path to a token instead of the token itself. Also, the upload command does not use tmkms.toml, and relies on env vars VAULT_TOKEN, VAULT_CACERT and VAULT_ADDR like the vault cli (its faster to quickly upload a key).

There are two additional things that I think would be a plus:

• Support VAULT_SKIP_VERIFY to not verify certificate.
• Re-connect when connection to Vault drops. Currently it just hangs and stops signing.

@mkaczanowski let me know if I can be of any help.

[mkaczanowski]

okay, I'll rebase and add the feature to read access token from disk later this week

[mkaczanowski]

thanks @helder-moreira I will definitely take a look

[mkaczanowski]

(fyi) I have a rebased, cleaned up branch with integration tests here:
https://github.com/mkaczanowski/tmkms/tree/hashicorp-feature-tmkms

(still WIP, as I am testing it out to address the connection issues)

[tony-iqlusion]

Closing in favor of #840