Vault: GPG/PGP secret backend?

[jmthackett]

It'd be great if it were possible to have vault act something like a smartcard for GPG. Specifically, being able to write (but not subsequently read) a key and then perform actions with it according to a set policy. I'm imagining use to be something like this:

Method
POST/PUT
URL
gpg/my-key?action={sign,encrypt,decrypt}
Parameters
Arbitrary string (eg, an email you're encrypting before sending or have just received)
Returns
String which has been signed/encrypted/decrypted/etc

The idea for this is not to store encrypted data, but key material itself. This would allow access for multiple devices to a single secret without allowing any of them direct access to it.

Is this or something like it ever likely to be part of Vault?

[jefferai]

It is...very likely.

Although one crucial difference is that (such as is the case with transit right now) it may not support you uploading your own key. Although there are use-cases where that would be convenient, there are also use-cases that revolve around the idea that nobody has _ever_ had access to the private key -- so it's generated within Vault and never leaves.

I'm closing this for now. Can't promise a timeline, but I'll simply say that it's of great interest.

[c-bb]

One year on, what's the status of this? Still very likely?

[jefferai]

We'd love to have it, but our original motivation for wanting to create it is not currently feasible. So if it was, it'd be very likely....

[stevenmanton]

Plus one for this. I love the idea of being able to store private keys in Vault. Like the transit backend, you could imagine a scenario where the master private key is never released by vault, but Vault could generate subkeys that _could_ be released and used for encryption/decryption.

I've also toyed with the idea of modifying the command-line utility to look for private keys in Vault rather than a local keyring.

[meirish]

Someone in the community built a plugin that may be of interest: https://github.com/LeSuisse/vault-gpg-plugin/

[jefferai]

Interesting, wonder why they didn't PR something against transit instead. It's significantly faster and there could be a lot of reuse.

[LeSuisse]

Hi @jefferai,

I started this around the Vault 0.8.0 release and the announce of the plugin backend. It seemed a good way to practice Go, play with Vault and at the same time solve one of my problem. Also, I know that a big PR out the blue might lead to tedious reviews and I was not sure it was you might accept as you seemed to already have some plans about it.

Now, if you feel it is appropriate I'm fine working on a PR against transit. Should we discuss it here, should I open a new issue or start a thread in the ML?
I feel adding GPG/PGP into transit might be confusing for the users due some specificity (e.g. name/email/comment at creation or signatures not respecting the format used by Vault) and the differences with the currently existing type of asymmetric keys currently provided by the backend. I also did not deal with subkeys in my plugin because it was not needed for my use case. I imagine some might have interests, not sure if it's mandatory for a first step though.
We should probably agree on the API before I submit anything :) .

[jefferai]

@LeSuisse One downside to going through the plugin interface is that it's much slower, so anyone wanting to encrypt/decrypt at speed with the backend will be far better served if it's something within Vault proper.

That said the API is definitely significantly different from transit so it's unclear whether it'd make sense inside transit, but could potentially as a separate backend that Vault includes internally. (In fact, Vault can include plugins internally but they can still be developed independently.)

[LeSuisse]

@jefferai I'm completely up for submitting a PR/doing the necessary changes to have it within Vault and getting the nice perf boost.

Unless you see a way to deal with the GPG/PGP specifics within the transit backend, it is probably better off as a separate backend.

How do you wish me to proceed? Should I just submit a PR with the documentation updated and we will deal with the rest during the reviews?

Any way, I'm going to drop the possibility to create a key in Vault from an existing GPG key before any inclusion. I didn't push the plugin too much playing with that feature but it's sketchy without dealing properly with subkeys so at least for now I think it can be put aside.

[jefferai]

@LeSuisse in 0.9 we added RSA support in the underlying library that powers transit so while I agree that it probably makes sense as a separate backend there might be the possibility of enhancing (or just using) that library for some code re-use.

I do wonder though if we'd need subkey support (or at least, an understanding of how it would work, API-wise and so on). The Vault code that can use PGP to wrap key shares on init/rekey doesn't handle subkeys and this is a.....longstanding source of frustration for users.

[code-ape]

I know this issue has been marked closed for some time, but seeing as conversation has continued going, I thought I’d add my quick $0.02:

I think PGP support would be a huge add for Vault, it’s the only operation primative I’ve wished it would offer that it hasn’t yet. While the ability to create subkeys does seem pretty necessary to me for Vault to fully deliver on the value of PGP, I’d happily take it without that as a stepping stone towards it! I’ll keep an eye on this and hope to see something land in the future :)

[bobchaos]

Another use case: A keybase-like service that allows:

• an API to generate PGP keypairs that operators can`t see, but can revoke
• Developers to access a sort of catalog of public keys so they can create private messaging systems
• Users can retrieve their own private keys, but no one else

Specifically, I'm using terraform to generate user credentials and the only way to send those securely in TF (AFAIK) is by encrypting them using a public PGP key. I`d use what i describe above to query the "catalog" for a public key matching the provided username, if not found, generate it, then encrypt the creds and ship them to my users by email (or something).

I understand currently suggested solutions don't store the private key in Vault, but my use case would require it (altho if the API endpoint returned the private key on generation it could be left to the Vault users to find a place to stash them)

Thoughts?