PGP/GPG Transit Secrets Engine

[trishankatdatadog]

Is your feature request related to a problem? Please describe.

Vault does not currently support PGP/GPG operations out-of-the-box.

Describe the solution you'd like

Vault should provide a PGP/GPG Transit Secrets Engine.

Describe alternatives you've considered

Alternative solutions include a Vault plugin, but it may be more widely useful to have such a module added to the Transit Secrets Engine (which are basically official plugins anyway IIUC).

Explain any additional use-cases

Use cases include:

• Code signing with GPG.
• Encryption and decryption of messages.

Additional context

4308

4025

1347

[bbros-dev]

One of the outcomes from the Vault plugin discussion was convergence on a subset of PGP, specifically signing.

We wonder if a easier launch/initial point wouldn't be signify for signing - we use it to sign our git commits as notes - and we love it. It has allowed us now to (slowly) start to move to humans validating/verifying signatures instead of scripts - as we think it should be. We'd also like to move to signature chaining (where script vaidating/verifying makes some sense once the human has done the initial inspection) per openBSD but are not quite there yet.

Ideally we'd like to simplify our signing and encrypting stack/codebase, but constantly find ourselves in a chicken and egg situation in terms of extracting ourselves from PGP/openGPG. Supporting these simpler tools will help move the needle.

While less familiar with them, we've been wondering if moving in the direction of something like Age or similarly simple encryption tooling isn't also worth serious consideration.

Not I'm not suggesting don't support PGP implementations but I would be comfortable with having it as a second class citizen.

[trishankatdatadog]

Not I'm not suggesting don't support PGP implementations but I would be comfortable with having it as a second class citizen.

Understand your reasons, but here we are talking solely about PGP/GPG, which should be supported as a first-class citizen, considering how time-tested and useful it remains (even for bootstrapping Vault itself). A signifiy or Age transit secrets engine, if so needed, should be a separate issue.

[jmariondev]

Using Vault for PGP is a big use case at my day-job (a Vault Enterprise customer with multiple clusters). We currently use vault-gpg-plugin but maintaining a separate plugin binary makes deployments much more difficult than they need to be.

Having a native PGP engine in Vault would add significant value. This adds to the use-cases for Vault: automated release signing (like Hashicorp does for their own releases) and having a centralized store of team PGP keys (like Hashicorp's security key) are just two such examples.

Even importing @LeSuisse 's fantastic vault-gpg-plugin code as an engine to upstream Vault (#4308) would be a great step forward.

[trishankatdatadog]

Even importing @LeSuisse 's fantastic vault-gpg-plugin code as an engine to upstream Vault (#4308) would be a great step forward.

It's a great plugin. I'm planning to edit it to be more compatible with the Transit Secrets Engine API, add support for subkeys, etc.

[trishankatdatadog]

Given recent incidents, might there be interest to incorporate such a plugin into Vault itself? @jefferai

[trishankatdatadog]

Given recent incidents, might there be interest to incorporate such a plugin into Vault itself? @jefferai

ping would anyone at Hashicorp be interested in fixing this issue?

[dataO1]

@trishankatdatadog Any news on your plans to update the vault-gpg-plugin? Support for subkeys would be huge!

[trishankatdatadog]

@trishankatdatadog Any news on your plans to update the vault-gpg-plugin? Support for subkeys would be huge!

Unfortunately, not at the moment, we are busy with other projects... the community may fork our plugin, if they so desire.