Switch from using AES256 to KMS for storing individual keys and the latest.json file. The SSM Store supports KMS Encryption and allows more segmentation for which keys a user is allowed to read.

Store the latest keys for each service by the KMS key they were written with. Doing so allows for Chamber to use KMS Encryption on the latest file as well as the individual keys in the service.

Store the KMS Key and the version in the latest file. This allows us to combine the latest files together (even though there is a __latest.json file per KMS Key).

Instead of attempting to migrate between KMS Keys and leaving the first KMS's latest file in an inaccurate state, we ask users to delete and recreate the chamber secret with the new key.

Before writing an existing secret with a new KMS Key, ask the user to delete the existing Chamber secret with the current key. Tell them which KMS key the secret is currently encrypted with.

When attempting to read the __latest.json for a KMS Key, treat AccessDenied as the file not existing. We do this because the user may not be able to read keys in the service that are encrypted with a KMS Key they don't have access to.

If we get a different kind of error then panic, this isn't my prefered way to handle the error but the S3 pages API doesn't allow to pass back err as a result.

The changes I've made to the __latest.json format (both schema changes and made multiple of these files, one per KMS Key used) are not backwards compadible with the previous implementation of the S3 backend.

Detail how to use it and it's features.

This seems to be more traditional and I was just working around the lack of err in the AWS ListObjectsPages method.

To avoid treating any secret names that start with kms as index files.

I coppied this from the S3Store interface but this was only being used as a proxy for NewS3StoreWithBucket. Since this backend is brand new it can just have the NewS3KMSStoreWithBucket method and doesn't need to expose the legacy method.

There is a lot of overlap bettween the S3Store and S3KMSStore (because I coppied and pasted the entire thing to begin with). I'm removing a lot of the shared code and just using method overriding for the methods that have changes.

Previously we used an environment variable or set a default. However, in order to added a flag to the UI it would be cleaner to pass in into the store interface.

To support making the command line more usable (and removing the setup of environment being the main interface) the S3-KMS backend now allows setting the KMS Key Alias via the command line interface. The environment variable will be prefered.

This reverts commit cbb5b4d.

This broke the List operations (because it removed the overriding of the base class. This caused an issue because the List operation now searches for keys in multiple kms key latest index files).

This can be shared with the S3Store interface via function overriding.

…nctions

Instead of maintaining two sets of code for the S3KMSStore and S3Store, instead share functions that are similar between the modules (eg, history, read).
The biggest differences are in List (Where we index of multiple latest files in the KMS version but only one in the S3Store), Write and Delete (where we must handle writing with different keys).

All kms key aliases need to be prefixed with "alias/"keyname

Allow passing in the KMS Key Alias to write and delete keys with to the SSM Backend as well as the S3KMSStore

This reverts commit 4967538.

This reverts commit 0cfab16.

Explode when --kms-key-alias is used with other backends that don't support it.