trek10inc / serverless-secrets

An opinionated tool for safely managing and deploying Serverless projects and their secrets.
Other
165 stars 27 forks source link

s-resources.json Usage #4

Closed alexwillingham closed 7 years ago

alexwillingham commented 8 years ago

Looks like the decoding only hooks into lambda deployments. I'd like to use it to specify for example a Root password for an RDS instance defined in s-resources.json (at "sls resources deploy" time).

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html

Is this a legit future use-case for the plugin or am I barking up the wrong tree?

Thanks for all of your contributions to Serverless, @shortjared!

shortjared commented 8 years ago

Interesting use case. The real power of this plugin is that decryption only happens in the actual lambda runtime (and only for nodejs at this point), protecting unencrypted secrets from even being in local memory at any time.

We could fairly easily hook into the resources deploy and decrypt variables. However, it does mean that you have to have a proper role / credentials to run KMS decryption (or whatever other provider you use) at sls resource deploy runtime meaning that you do lose a bit of security.

I need to think on this to see if it's something we should build out, I will happily take a PR if you get bored though. I don't see it hurting anything to at least have the option.

alexwillingham commented 8 years ago

Thanks for the reply. I think I feel good about giving my serverless administrator IAM user the privileges to see the password of the RDS instance it is responsible for configuring.

I'm interested in

  1. keeping my _meta/variables files under version control.
  2. keeping secrets in those files unreadable where there aren't permissions to KMS.

Seems that having secrets on my box and in local memory is just like traditional dotenv solutions?

I like that the only configuration for our project would be setting up the user in ~/.aws/credentials. no need to keep some of the _meta/variables files out of VCS due to having secrets, which makes setup slower and will cause people to have out of sync _meta/variables. The "meta sync" plugin looks OK, but version control is way better!

If only it were a matter of being bored! I hope I can find the time. Please let me know if this sells you on it a bit more, or if you find my assertions about security concerning.

shortjared commented 8 years ago

I think I am sold on this, it makes perfect sense. I will investigate building this in either this weekend or next week.

Another note, to keep things more secure than just putting creds on your local machine with direct access... I recommend something like https://github.com/trek10inc/awsume (shameless plug) or https://github.com/remind101/assume-role for using AWS IAM Roles behind MFA... one more layer of security so even direct access to your machine does not mean an attacker gets credentials. Also very handy for bouncing around many different accounts rapidly from the CLI.

alexwillingham commented 8 years ago

Very cool! Looking forward to it.

Awsume looks useful. Nice work there. I'll look into it as we continue to use Serverless on more projects.

scotty-p commented 8 years ago

+1 on this!

My use case for decryption on deployment is because my lambda functions have VPC endpoints, so don't have internet access by default. To add to this, security has said I am not allowed to enable internet access on these lambdas due to the sensitive information they are touching. This means that I cannot get to the KMS API in order to decrypt the secrets. My only option here is to decrypt before they are packaged and uploaded.

shortjared commented 8 years ago

Interesting. Also a strong use case. I will have to think this through.

shortjared commented 7 years ago

Closing. Plugin is being deprecated.