Serverless Secrets

Wed, 15 Jun 2016

The Serverless Framework is fantastic at managing AWS API Gateway, AWS Lambda, and helping wire up all the events and streams. It makes creating and managing complex infrastructures less painful and more straightforward. At Trek10, we have seen the Serverless paradigm driving an unprecedented amount of interest and traffic. But, nearly every prospective client we’ve talked with has one question in common: How do we secure sensitive information like RSA certs, API keys and client secrets?

There are several approaches to this:

• Just share plaintext secrets in your _meta folder and commit it to your private repos. This is okay, but then you still have plaintext secrets rolling around lord knows how many developers’ machines.
• Keep _meta out of your repo, and instead use the S3 meta sync plugin. This works, but the user experience is painful, especially if using CI and multiple developers. Should I update or resync today? Should I not? I dunno.
• Use a S3 folder encrypted at rest, and read it in at function runtime. This can cause a fair amount of latency, and then your configuration is separated entirely from your app. It is also easy (and likely) that a config will be forgotten or messed up.
• Commit the _meta folder, but all secrets and sensitive data are encrypted and protected via some mechanism and tooling. By far the most complicated to setup and tool.

The first 3 options work, but they all have risks around the actual workflow or security. The last option, the most technically challenging, can take hours or days to setup, even for a simple app to protect one or two secrets.

Since we work on multiple projects on a daily basis at Trek10, we needed something that was technically sound, secure, AND easy for everyone involved to use. So we built Serverless Secrets.

Serverless Secrets

The Serverless Secrets plugin can manage the encryption, runtime decryption, and caching of secrets seamlessly for you in your Serverless Framework apps. It comes with multi-provider support, including raw AWS Key Management Service (KMS), file based KMS, and a credstash compliant decryptor.

It solves the security and workflow problems by letting _meta securely live inside of your git repo, allowing true version control to maintain your configuration, which is good for developers. However, the secrets, instead of looking like superSecretTextHere, looks something like kms::arn:aws:kms:us-west-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab::exyeE4AdmEH2vbXvXS49/SG05O8PrVovmKISeYorw.

To add even more to security, you can set it up so only certain developers can encrypt secrets, and even further so that only particular functions or sets of functions even have permission to decrypt secrets. The potential attack vector is vastly constrained.

Each of the secrets is decrypted at runtime, and thanks to Lambda container reuse and some smart caching by Serverless Secrets, it only happens on the first run for each given container and never again during its lifetime. You do pay a small performance penalty of around 1 second for a cold container start time, but zero performance penalty thereafter.

Give Serverless Secrets a spin today, and let us know what you think. We’ll take any PR’s or issues you have too!