Encryption key stores

while jumpwire handles all of the orchestration for key management including generation and rotation an external key store is strongly recomended for production deployments relying on just the jumpwire engine can lead to keys being lost if the cluster is terminated there are several options for managing encryption keys, depending on your existing infrastructure and needs let us know if you're using something not listed below and we'll be happy to work with you! jumpwire hosted (default) encryption keys can be stored through the jumpwire hosted control plane in this setup, the keys are further encrypted and stored in an internal vault deployment when an engine cluster connects to the control plane, the keys are retrieved and sent to the cluster hashicorp vault vault is enabled by providing authentication credentials to the engine at runtime when the jumpwire engine is configured to use vault, encryption keys are generated locally and stored in vault's kv store the path is configurable as part of the engine's startup configuration key rotation generates new keys and keeps both the new and old keys in vault, allowing all keys to be retrieved for decrypting older data see the vault integration docid 3fkslprwse6pu2eytbp7b docs for more information aws kms with aws kms, a master key is automatically generated in kms if it doesn't already exist on startup, the engine cluster will create a new data key encrypted with the master kms key data fields are encrypted with the data key, and then the kms encrypted data key is prepended to the resulting text blob if the engine tries to decrypt a value that it doesn't have a data key cached for, it will decrypt that key using kms this allows the cluster to startup without having any data keys initially available kms can be enabled by setting jumpwire aws kms enable=true optionally, the key to use can be configured by setting jumpwire aws kms key name to either a name to use as an alias prefix or the full key id this defaults to the value jumpwire the jumpwire engine must have appropriate aws iam permissions credentials can be provided using the environment variables aws access key id and aws secret access key or through the instance role without any additional configuration when running in ecs or ec2 the following iam policy provides the minimum necessary permissions if you change the default alias using jumpwire aws kms key name make sure to also update the iam conditions to match iam example { "version" "2012 10 17", "statement" \[ { "effect" "allow", "action" \[ "kms\ generatedatakey ", "kms\ describekey", "kms\ encrypt", "kms\ decrypt" ], "resource" "arn\ aws\ kms key/ ", "condition" { "foranyvalue\ stringlike" { "kms\ resourcealiases" \[ "alias/jumpwire/ " ] } } }, { "effect" "allow", "action" "kms alias", "resource" "arn\ aws\ kms alias/jumpwire/ " }, { "effect" "allow", "action" "kms alias", "resource" "arn\ aws\ kms key/ " }, { "effect" "allow", "action" "kms\ createkey", "resource" " " } ] } restricting kms operations to a specific key requires knowing the key id in advance this can be done by either manually creating the key first, or updating the policy after jumpwire generates the key