avatarTeri Radichel

Summary

The website content outlines the process of deploying a secret for use with an AWS Lambda function through CloudFormation, including the specification of a KMS key and modification of the Lambda policy to allow key usage, with a focus on using a single key per environment for cost efficiency and security.

Abstract

The article discusses the deployment of a secret in AWS using CloudFormation for Lambda functions, emphasizing the importance of specifying a KMS key for encryption and adjusting the Lambda policy to grant the necessary permissions. The author, Teri Radichel, references previous work on creating generic AWS IAM roles and policies for Lambda functions and provides insights into using a single KMS key for each environment to streamline the deployment process across different stages such as development, QA, and production. The article also touches on the need for unique output names for resources like secrets and roles, the potential for using the same templates for multiple functions, and the consideration of key policies when the KMS key is used across multiple services within an environment. Radichel plans to address the complexities of key policies in a subsequent post.

Opinions

  • The author suggests that using a single KMS key per environment is a balance between security and cost, as opposed to using separate keys for each process or step, which would be more secure but also more expensive.
  • Radichel emphasizes the reusability of code and templates for deploying Lambda roles, policies, and secrets across different environments, which can simplify the deployment process.
  • The article implies that the key policy must be carefully considered when a KMS key is used with multiple services, indicating that this is a new challenge the author is addressing.
  • The author values the uniqueness of resource names to avoid conflicts, suggesting that naming conventions should reflect the purpose and environment of the resources.
  • Radichel encourages readers to follow for updates, indicating an intent to continue sharing knowledge and solutions in the field of cybersecurity.

Deploying a Secret to Use With A Lambda Function Using CloudFormation

ACM.291 Specifying a KMS key and modifying the Lambda policy to allow it to use the key

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Security | Lambda Security | IAM

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post we started to create a generic AWS IAM role and policy for use with Lambda functions.

In that post, our policy references the role and a Secret CloudFormation stack. We cannot deploy the stack until we deploy the secret stack so we’ll do that first.

I already have a stack that can deploy a secret on AWS here:

SecurityMetricsAutomation/AppSec/stacks/Secrets/cfn/Secret.yaml

I’ll need to add an output where the name of the Secret returns the ARN.

Notice that the secret requires a KMS key. Which Key should we use?

Well, I already deployed a key for the Sandbox environment so we can use that key.

Using our existing functions we can look up the key ID by the alias name which matches the name of the environment and pass it into this function. In order to not have conflicting output names, I’ll need to add “Key” to the end of my key alias. Then I’ll add an output matching the Key alias name:

If we create a single key for every environment, then we could use the same code to deploy from dev to QA to production and pass in the environment name. Each environment should have a CloudFormation stack for a KMS key with an output name matching the environment. Or, you could look up the KMS key by the matching Alias name as shown above.

Some companies might opt to have a separate key for every process or even for every step name. That would actually be more secure. The issue would be the cost of the KMS keys. If you do that you’d need to modify your policy template to grant access to the name matching the process or the process step. Each organization can make that call as appropriate.

For now I’m using a key per environment for deployment purposes, so I need to modify my Lambda policy to allow the Lambda function to use the KMS key name for the environment, but the process will only be allowed to decrypt its own secret based on the policy.

Also, recall in the last post that we can’t have outputs with the same name, so I need to make sure my secret is the name of the process step with “Secret” at the end and the name of the role is the name of the process step with “Role” at the end to ensure they are unique.

In theory that will work, but I will test it all when I create my deploy script. Hopefully the same templates will work for every function in our process when we’re done. We’ll just have a different bit of code in our deploy script for each function.

Now there’s another snag I need to handle. The key policy. Since this key is used for the whole Sandbox environment and not with a specific service, I need to do something with this key I have not done before. I need to use it with multiple services. I need to ponder a bit so I’ll cover that in the next post.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
Lambda
Secret
Process
Iam
Policy
Recommended from ReadMedium