Integrating with Hashicorp Vault

[Steven Cipolla]

Hi,

I am looking at a few different options for integrating with Hashicorp's Vault with TInk, and wanted some feedback. I am using the kv secrets engine.

1) Implement KeysetReader/KeysetWriter interface to read/write Keyset in Vault.

This is straightforward if I store the whole Keyset in vault at a known path, and it works pretty well. Clients of the library provide /path/to/secret and credentials. I have some concerns about the eventual Keyset size if keys are rotated frequently. I noticed that Android implements a KeysetManager to wrap interaction with the Android keystore, but I'm not sure how much utility that would add for my use-case, if any.

2) Envelope encryption

We are planning to use this encryption in a data pipeline where the service which encrypts the data is different than the service that decrypts the data. To use (Java) AeadKeyTemplates.createKmsEnvelopeAeadKeyTemplate I have to distribute the generated KeySet to all services which is inconvenient. The inputs they need to agree upon are the dekTemplate and the secret path (in Vault), so I've resorted to using something like this:

byte[] plaintext = ...;
KeysetReader reader = VaultKeysetReader.withPath("/some/path/in/vault");
KeysetHandle keysetHandle = CleartextKeysetHandle.read(reader);
Aead kekAead = keysetHandle.getPrimitive(Aead.class);
Aead aead = new KmsEnvelopeAead(AeadKeyTemplates.AES256_GCM, kekAead);
byte[] ciphertext = aead.encrypt(plaintext);

Do you see any concerns with this approach? I could resort to storing the envelope key template in a known location, to obviate the need to hardcode the dekTemplate, any thoughts on that approach?

Thank you!

[Sophie Ellen]

There actually is some Hashicorp Vault integration in the golang version of Tink, using Vault's remote encryption features to get the same integration that Tink has with GCP/AWS KMS, which you can use as a blueprint if you want (feel free to send a PR if you do so).

If you want to use secrets instead of remote encryption oracles, this would be implemented more or less the way you sketched in your email, although we usually do that kind of integration (services that give out a secret instead of providing a remote oracle) by making a specific KeysetHandle that contains a static method to construct it, instead of providing a Reader/Writer.

This has the benefit that you do not need users to use CleartextKeysetHandle (although you use it in the static method), allowing you to provide an interface that only uses KeysetHandle, so that users don't accidentally extract the cleartext keys. If you go that route, feel free to send a PR as well, support for more secret managers is one of our longer term goals.

--
You received this message because you are subscribed to the Google Groups "tink-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tink-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tink-users/773557c4-e777-4b60-9442-4188467bee6a%40googlegroups.com.

[Steven Cipolla]

Thank you for the pointers on which interface to provide to read Keysets -- I will incorporate those changes.

For the time being we aren't using Vault's remote encryption capabilities a la the other KMS integrations, but if that ever changes I'd be happy to send a PR. 

On Wednesday, March 4, 2020 at 8:30:14 PM UTC-8, Sophie Ellen wrote:

There actually is some Hashicorp Vault integration in the golang version of Tink, using Vault's remote encryption features to get the same integration that Tink has with GCP/AWS KMS, which you can use as a blueprint if you want (feel free to send a PR if you do so).

If you want to use secrets instead of remote encryption oracles, this would be implemented more or less the way you sketched in your email, although we usually do that kind of integration (services that give out a secret instead of providing a remote oracle) by making a specific KeysetHandle that contains a static method to construct it, instead of providing a Reader/Writer.

This has the benefit that you do not need users to use CleartextKeysetHandle (although you use it in the static method), allowing you to provide an interface that only uses KeysetHandle, so that users don't accidentally extract the cleartext keys. If you go that route, feel free to send a PR as well, support for more secret managers is one of our longer term goals.

Am Mi., 4. März 2020 um 10:57 Uhr schrieb Steven Cipolla <steven...@gmail.com>:

Hi,

I am looking at a few different options for integrating with Hashicorp's Vault with TInk, and wanted some feedback. I am using the kv secrets engine.

1) Implement KeysetReader/KeysetWriter interface to read/write Keyset in Vault.

This is straightforward if I store the whole Keyset in vault at a known path, and it works pretty well. Clients of the library provide /path/to/secret and credentials. I have some concerns about the eventual Keyset size if keys are rotated frequently. I noticed that Android implements a KeysetManager to wrap interaction with the Android keystore, but I'm not sure how much utility that would add for my use-case, if any.

2) Envelope encryption

We are planning to use this encryption in a data pipeline where the service which encrypts the data is different than the service that decrypts the data. To use (Java) AeadKeyTemplates.createKmsEnvelopeAeadKeyTemplate I have to distribute the generated KeySet to all services which is inconvenient. The inputs they need to agree upon are the dekTemplate and the secret path (in Vault), so I've resorted to using something like this:

byte[] plaintext = ...;
KeysetReader reader = VaultKeysetReader.withPath("/some/path/in/vault");
KeysetHandle keysetHandle = CleartextKeysetHandle.read(reader);
Aead kekAead = keysetHandle.getPrimitive(Aead.class);
Aead aead = new KmsEnvelopeAead(AeadKeyTemplates.AES256_GCM, kekAead);
byte[] ciphertext = aead.encrypt(plaintext);

Do you see any concerns with this approach? I could resort to storing the envelope key template in a known location, to obviate the need to hardcode the dekTemplate, any thoughts on that approach?

Thank you!

--
You received this message because you are subscribed to the Google Groups "tink-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tink-...@googlegroups.com.

[Thai Duong]

On Thu, Mar 5, 2020 at 10:02 AM Steven Cipolla <steven....@gmail.com> wrote:

Thank you for the pointers on which interface to provide to read Keysets -- I will incorporate those changes.

For the time being we aren't using Vault's remote encryption capabilities a la the other KMS integrations, but if that ever changes I'd be happy to send a PR. 

On Wednesday, March 4, 2020 at 8:30:14 PM UTC-8, Sophie Ellen wrote:

There actually is some Hashicorp Vault integration in the golang version of Tink, using Vault's remote encryption features to get the same integration that Tink has with GCP/AWS KMS, which you can use as a blueprint if you want (feel free to send a PR if you do so).

If you want to use secrets instead of remote encryption oracles, this would be implemented more or less the way you sketched in your email, although we usually do that kind of integration (services that give out a secret instead of providing a remote oracle) by making a specific KeysetHandle that contains a static method to construct it, instead of providing a Reader/Writer.

This has the benefit that you do not need users to use CleartextKeysetHandle (although you use it in the static method), allowing you to provide an interface that only uses KeysetHandle, so that users don't accidentally extract the cleartext keys. If you go that route, feel free to send a PR as well, support for more secret managers is one of our longer term goals.

+1 to implementing a VaultKeysetHandle.

If I may, I want to elaborate on why this is a better choice than adding a KeysetReader.

1/ Keyset is encoded in protobuf. This is an implementation detail that we don't want external users to depend on. It's a design mistake (it's my fault) to have it in public interfaces. This needs a new design, and don't quote me on this just yet :-), but in Tink 2.0 KeysetReader/KeysetWriter probably go away.

2/ From a KeysetReader, you obtain a KeysetHandle using CleartextKeysetHandle, but CleartextKeysetHandle is dangerous. At Google users can't depend on it without our approval. We restrict its usage using Bazel's visibility restriction. If you add a KeysetReader, you'd still want to restrict CleartextKeysetHandle. VaultKeysetHandle, however, can be public.

Am Mi., 4. März 2020 um 10:57 Uhr schrieb Steven Cipolla <steven...@gmail.com>:

Hi,

I am looking at a few different options for integrating with Hashicorp's Vault with TInk, and wanted some feedback. I am using the kv secrets engine.

1) Implement KeysetReader/KeysetWriter interface to read/write Keyset in Vault.

This is straightforward if I store the whole Keyset in vault at a known path, and it works pretty well. Clients of the library provide /path/to/secret and credentials. I have some concerns about the eventual Keyset size if keys are rotated frequently. I noticed that Android implements a KeysetManager to wrap interaction with the Android keystore, but I'm not sure how much utility that would add for my use-case, if any.

2) Envelope encryption

We are planning to use this encryption in a data pipeline where the service which encrypts the data is different than the service that decrypts the data. To use (Java) AeadKeyTemplates.createKmsEnvelopeAeadKeyTemplate I have to distribute the generated KeySet to all services which is inconvenient. The inputs they need to agree upon are the dekTemplate and the secret path (in Vault), so I've resorted to using something like this:

byte[] plaintext = ...;
KeysetReader reader = VaultKeysetReader.withPath("/some/path/in/vault");
KeysetHandle keysetHandle = CleartextKeysetHandle.read(reader);
Aead kekAead = keysetHandle.getPrimitive(Aead.class);
Aead aead = new KmsEnvelopeAead(AeadKeyTemplates.AES256_GCM, kekAead);
byte[] ciphertext = aead.encrypt(plaintext);

Do you see any concerns with this approach? I could resort to storing the envelope key template in a known location, to obviate the need to hardcode the dekTemplate, any thoughts on that approach?

Thank you!

--
You received this message because you are subscribed to the Google Groups "tink-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tink-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tink-users/773557c4-e777-4b60-9442-4188467bee6a%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "tink-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tink-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tink-users/9796cb16-0f3e-4aff-8b0c-6313b4955d20%40googlegroups.com.