Vault- Encrypt/decrypt with transit backend

[Niks]

Referring to Documentation from Hashicorp:

"By default, Vault uses a technique known as Shamir's secret sharing algorithm to split the master key into 5 shares, any 3 of which are required to reconstruct the master key. The master key is used to protect the encryption key, which is ultimately used to protect data written to the storage backend."

Question.
Set up:

Datacenter 1

My Application-------> Vault1 for encrypt/decrypt

Datacenter 2
My Application ---> Vault 2 for encrypt/decrypt

Backend: File system
Transit backed for encrypt/decrypt

When DC 1 goes down, DC2 comes up and application should be able to decrypt data encrypted by vault 1 at DC1.
Assumption: 1) All encrypt keys created in vault 1 are also created in vault2 using HTTP end point
e.g. http://127.0.0.1:8200/v1/transit/encrypt/demo1
2) Data storage of application gives access of all encrypted data in DC2 as transit backed do not store data just encrypts in transit.

Child token is used to authenticate encrypt/decrypt i.e X-Vault-Token is a child token

questions:
1) Master keys will be obviously different in two instances of vault.
X-Vault-Token, as I understand, will also be different in vault 1 and vault 2.

Is it true that all encrypted data in DC 1 can be decrypted is DC2 and it's value will remain same?

Usually in cryptography, if cipher keys are same decrypt should give same result. But I have a doubt here because of the role of master key and X-Vault-Token.

Can someone please reply.

Thanks

[Jeff Mitchell]

Niks,

No -- the key used for encryption is a property of a given Vault
cluster, so two separate clusters with separate keyrings will not be
able to decrypt each others' data.

Vault does not yet have built-in multi-datacenter support; some people
have found some workarounds by disabling the in-built caches and using
consul-replicate, but this has to be done very carefully and will slow
things down quite a bit (especially transit).

--Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/22acf2de-d851-4b8e-b73c-f636f941f3b4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Niks]

Hi Jeff, 

Thanks for reply.

Do you mean, same key name , say myKey in two instances of vault, will result in different myKey value (because master key is different), stored in respective vault instances

 and hence they  cannot encrypt/decrypt  the same text say 

"plaintext":  "abc" consistently.

 Basically, 

Vault 1:

 mykey:

"plaintext":  "abc"

encrypt : Result  in say value1

--------------------------------

Vault 2:

 mykey:

"plaintext":  "abc"

encrypt: Results in say value2

decrypt: value1 (fetched from application storage) --> do not result in "abc"

Is this understanding correct?

Regards,

Niharika

[Jeff Mitchell]

Hi Niks,

That is essentially correct. It's a little more complex but in effect it's the same :-)

Best,
Jeff

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/7d6d6cfb-3ddf-4480-bebb-c2eb4e12c5f5%40googlegroups.com.

[Niks]

Thanks Jeff for quick response.

Got what you mean.

Niks

On Monday, May 16, 2016 at 12:59:04 PM UTC+1, Niks wrote:

[Niks]

Jeff,

I believe same holds true even if I use mySql DB as storage backend? encrypt decrypt will work only with same instance of Vault. 

How is this resolved when we use Vault in HA. Master tokens are still different for Active and standby Vault.

Does Vault handle it transparently? encrypt in active vault and decrypt for same data should work with standby Vault.

Niks

On Monday, May 16, 2016 at 12:59:04 PM UTC+1, Niks wrote:

[Niks]

Jeff,

Can you please address this? I need to make file backed work and should also support vault backup. Or is there any other way to backup Vault, copy the backend storage data and bring up other instance of vault?

Niks

On Monday, May 16, 2016 at 12:59:04 PM UTC+1, Niks wrote:

[Jeff Mitchell]

Hi Niks,

Vault is really just a runtime fronting a database, so this does
indeed hold true with MySQL.

In HA setups, the master tokens are *not* different for
standby/active, but standbys do not handle requests; they forward
clients with a 307 to the active instance.

If you're using the file backend, you can easily backup Vault by
making a backup of the file tree. However, I would strongly suggest
you do this in an atomic fashion -- for instance, taking a ZFS
snapshot.

Best,
Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/vault-tool/2af06d32-3c6a-4319-b7bf-f7213e0a9ea0%40googlegroups.com.

[Niks]

Thanks Jeff. Other thread and your inputs solved my issue :)

decrypt now works with another instance of vault, but when unsealed with same unseal keys as that of Vault server from which back up was taken.

Appreciate the quick responses from this group.

Niks

On Monday, May 16, 2016 at 12:59:04 PM UTC+1, Niks wrote: