Adding a Secret to A Lambda Deployment

ACM.315 Creating a Lambda-Specific Secret Resource Policy

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

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

🔒 Related Stories: Lambda | Container Security | Application Security

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

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

Now that I’ve locked down my Lambda function execution to a private network I feel a bit better about using a Secret with my Lambda function.

There’s one more protection I’m going to add. Recall that my Lambda function can access a secret with the same name as the Lambda function, if my policy works correctly.

This secret is going to have access to a token that offers read only access to a GitHub repository that has code for a public website. Remember I was working with the dev.rainierrhodendrons.com website a number of posts back. I need to create credentials that have read only access to that repository. I will store those credentials in a secret my function can access.

The code to create a secret exists here in my code base:

SecurityMetricsAutomation/AppSec/stacks/Secrets

I have example code in there to deploy a secret:

My code to deploy a Lambda function:

I should be able to add something like this:

That’s great but I need to modify my existing secret policy code. Currently it’s set up to deploy an IAM policy for a user to access the secret as I’m looking at it. That probably needs some modification after all the changes we’ve made.

For now, I’m going to add an if statement and a new parameter indicating if this is a user secret or not:

When I look at that stack I can’t remember exactly what I was doing. It looks like an IAM policy. In any case, I want to add a generic resource policy to secrets and pass in the list of ARNs that are allowed to read or write the secret as we did for KMS keys.

Here’s the secret policy documentation but it will be similar to other policies we’ve created.

I’m starting to think about lots of other things we can do generically as I’m going through this latest sub series but for now we’ll just create a SecretResourcePolicy.yaml file that looks like this and pass in the Lambda function role, giving it read-only access. I could get fancier but this works. I’m thinking about changing my environments a bit so I’m just making the [Environment Name]Admin the administrator of the secret for the moment.

This policy now allows the Lambda function to have read-only access to the secret where we’ll store read-only credentials to clone a GitHub repository. I quickly tested that the SandBox admin can access the secret and yes. There’s more I can do to protect this secret but it’s pretty good and need to get a move on. I have some ideas to revamp all of this in the near future.

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