Open yuvadm opened 6 months ago
Maybe use AWS Systems Manager and then fetch at runtime as a best practice, and a secure solution
@AmirFone interesting proposal, but right now I'm using a very lean deployment of Lambda/Chalice and would prefer a solution that does not involve any additional AWS products that will bloat my deployment.
An intermediary solution is to commit config.json.default
like this:
{
"stages": {
"prod": {
"environment_variables": {
"MY_SECRET_KEY": "$MY_SECRET_KEY"
}
}
}
}
Then, just before plan+deploy call (In ci/cd or manual script):
cat .chalice/config.json.default | envsubst > .chalice/config.json
This will replace $MY_SECRET_KEY with what is currently inside MY_SECRET_KEY env variable.
Of course, the secret will be present in the deployed archive, (make sure it is eventually destroyed) but at least it is not committed.
Documentation states that all environment variables, global or per-stage, should be set in
.chalice/config.json
.However, assuming
config.json
is committed to source control, this is a bad practice that commit secrets to a shared project.Setting environment variables directly through the AWS Lambda web UI is a non-solution since they will be deleted / overridden on the next
chalice deploy
.What's the best way to store env vars in a secure way that also allows committing
config.json
to source control?