6

Encountered a few speicific use cases that I'm somewhat confused to use which:

  1. A large number of free, public API keys. Using lambda environment variable with encyption, other developer/admin can still expose their plaintext value right in the lambds console. Should Parameter Store be used instead?
  2. Login credentials to a third party platform. I assume that Secrets Manager is the only option?
  3. DB Connection strings. Secrets Manager? At $0.40/secret/month, the bill would add up for hundreds of DBs for simply storing credentials.
fika_fika
  • 111
  • 1
  • 10

2 Answers2

10

For storing any credentials you have three AWS managed choices:

Lambda Environment Variables

These will be passed into the Lambda function directly via the Lambda Service. You can prevent others accessing the string values by controlling their permissions to KMS via IAM. This will provide the best performance out of any options (there's no additional lookup in the code runtime).

By using this option be aware of the following pitfalls:

  • If you use versioning for your Lambda function the values are fixed, you would need to deploy a new version of the Lambda function to make changes.
  • Values are attached to an individual Lambda function, if the keys are used by multiple you will need to pass to each function individually.

Systems Manager Parameter Store

Using this option you would use the SDK to retrieve any key/values that you want. It can store both plain text values as well encrypted strings (the SecureString type). It provides basic functionality but if that is all you need then it will work great. It costs nothing to store the values, but the price is $0.05 per 10,000 Parameter Store API interactions. Unlike environment variables you can use the value across multiple Lambda functions.

By using this option you would need to be aware of the following:

  • There will be a hit to performance for retrieving the value everytime, to reduce this call the function in the global context so that it can be reused between invocations.
  • You will need an individual parameter per each key/value. For a database this would mean either creating individual parameters or storing the entire credential set as JSON object and decoding after you retrieve it.

Secrets Manager

Using this option a lot of the management is built into the service, a secret can contain either a string or a single line JSON object. The SDK will handle the retrieval of these values but you must be aware just like SSM you will take a performance hit so you'll want to take a look at a similar solution as the parameter store. The biggest advantage to secrets manager over SSM parameter store is its integrations with other AWS services allowing features such as secret rotation.

However if you don't need the features of secrets manager you may be paying for more than you actually require, this is the most expensive option of all three.

Chris Williams
  • 32,215
  • 4
  • 30
  • 68
1

A large number of free, public API keys. Using lambda environment variable with encyption, other developer/admin can still expose their plaintext value right in the lambds console.

For the issue of developers being able to see the environment variables in the console, you can use a non-default KMS CMK, and configure permissions on that key so that the other developers can't use it (doc). They will still be able to see the rest of the Lambda configuration.

A bigger issue is how you will configure these environment variables. If you're using Terraform, for example, the configuration is written to the state file, and you will need to use external state (stored in S3 or on HashiCorp's servers) to secure it. If you're using CloudFormation, you can configure them using a dynamic reference to a Secrets Manager secret, but not to a Parameter Store secure string.

One other choice is to use the environment variables to reference parameter store keys, and then programmatically retrieve the values. For example, you have an environment variable named DATABASE_PASSWORD, and its value is /dev/database/password; the actual database password is a SecureString in Parameter Store, accessed via that path.

Login credentials to a third party platform. I assume that Secrets Manager is the only option?

Parameter store also provides a SecureString.

DB Connection strings. Secrets Manager? At $0.40/secret/month, the bill would add up for hundreds of DBs for simply storing credentials.

Does your application actually connect to hundreds of DBs? If yes, is $40/month (for 100 connections) really a financial hardship for your company?

If yes, then Parameter Store might be the best choice, but beware that there are a limited number of "free" parameters per account.

Parsifal
  • 3,928
  • 5
  • 9
  • It looks like CloudFormation does support dynamic references to Parameter Store secure strings now via `{{resolve:ssm-secure:}}`. See: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-ssm-secure-strings – rob3c Sep 15 '21 at 06:58