Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop custom AES encryption contexts in favor of parameter store #9

Open
andrewkrug opened this issue Feb 14, 2018 · 1 comment
Open

Comments

@andrewkrug
Copy link
Member

Consider cutting out the code that loads and decrypts the key in favor of using parameter store:

def import_key kms_opts

@joelferrier
Copy link
Member

I'm not opposed to using parameter store where it makes sense but last time I checked parameter store has the same limitation as encrypting directly against a kms key and doesn't allow encrypted parameters larger than 4k.

If this has changed then we can store the gpg key directly in parameter store as an encrypted parameter.
If we can't use encrypted parameter store secrets I'm hesitant to stop using the data key generated from a kms key.

Either way the setup process could use some love, perhaps a sub-command or a better helper script to securely store a gpg key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants