enable `env_file` functionality for secrets

[huanjani]

From https://gitter.im/aws/copilot-cli?at=62d1b4ca1227f62be38290e5: "...My best case scenario is to throw all of the variables from the .env file into SecretsManager and load them in dynamically. I'd prefer to not link to specific keys for every secret since the .env file has 100+ env variables in there.

I already know of the env_file feature, however it'd be best to securely store it instead of locally...."

[iamsajithk]

@huanjani Did you got any solution for this?

[iamhopaul123]

Hello @iamsajithk. Sorry we haven't got to this yet. Would you mind to thumb up for this feature request so that we could better prioritize? Also do you have any workaround for this for now?

[iamsajithk]

@iamhopaul123 No, I didn't got any work around for this. Do you have any suggestions?

[iamhopaul123]

Hello @iamsajithk. If you just wanted to use secrets manager, the temporary workaround is either run copilot secret init to create new secrets one by one. Or(only for SSM secrets) by adding proper tags you could import existing secrets and refer to them in the manifest. It is just if you have tens of secrets, unfortunately the manifest could be relatively long.

[lennertcc]

+1 for this.

My list of secrets in the manifest is pretty long and we have a bunch of services all using the same secret. This makes for a lot of duplication that I would like to concentrate in a single file per environment say, env_secrets, behaving exactly like env_file.

[vskov147]

+1 for this feature request, currently it's a lot of copy/pasta-spaghetti code to update every time we add a new env var that's shared across our many separate service manifests

[ssyberg]

👍🏼 to this as well, we are having to store the whole .env in secrets manager and do some smelly script work to expose each in the dockerfile

[al-dpopowich]

compose_ecs had this feature: #5690 . Would be wonderful to have for copilot.