Conditions and Parameters in IAM and Resource Policies
ACM.272 The quest for a generic policy document CloudFormation template
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: AWS Security | Application Security | CloudFormation | IAM
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I was considering the implementation of a Transit Gateway and a NAT for an organization. I looked at costs and components in that and prior posts. For now, I am not going to deploy an AWS Network Firewall due to the cost, and I will use packet capture on an as-needed basis. Although I can set up a Transit Gateway long term for now I am “simply” going to deploy a VPC and a NAT to test my Lambda function.
So in the next post I was “just” going to “quickly” deploy a NAT but I hit a glitch with the VPCEndpoint template I created earlier. A friend once told me that any time you use “just” in a sentence you’re likely in trouble.
Here’s the prior template where I created a VPCEndpoint for CloudFormation.
I don’t expect to be calling CloudFormation from my Lambda at this time but I do need to access CodeCommit, so I’m going to revise this code to deploy a VPC Endpoint for CodeCommit instead of CloudFormation.
Remember this is what I hope to achieve as I wrote about in a prior post. The Lambda function needs to reach out to GitHub and push the code to CodeCommit. Using the endpoint will keep the traffic off the NAT and hopefully save me some money. Also the traffic will remain on the AWS backbone rather than traversing the Internet when it routes through the NAT (i.e. more secure!)
The only thing I changed in my deployment script for the VPC Endpoint:
What’s in that deploy_vpce function? I always forget what I wrote before. Let’s make sure that handles AWS CodeCommit. Nothing specific to a service here so we’re ok, though I’m just guessing “codecommit” is the right thing to pass for the service. As a reminder this is in the file: network_functions.sh in the same folder and sourced by our script.
Let’s take a peek at that VPCEndpoint.yaml file in the cfn (CloudFormation) folder. And it looks like as long as “codecommit” is the right value to pass in we should be good to go here except…
This script is expecting an IAM Group and Role to exist:
So that’s not good. We’re going to want to modify the template to pass in the list of roles that are allowed to use the VPC Endpoint. You may recall, if following along, that I did something similar with our KMS Key template by passing in a list of roles that are allowed in the key policy. And I love reusing code rather than re-writing it from scratch.
Then I use those parameters in my template:
We can do the same here, but we’d need to go back and modify the other code that is expecting these roles. But this leads me to another problem. Look at the permissions assigned to those roles.
That is very specific to CloudFormation. What we really need to do is separate the policy from the endpoint deployment so we can create different policies for different accounts and endpoints. Can we do that?
Well, the policy is not required, but the default policy will be pretty broad.
Unfortunately it doesn’t appear that we have a standalone policy document in CloudFormation for VPCEndpoints. #AWSWishlist
The other thing I notice is that this template is looking for CloudFormation outputs with names that don’t exist in this account:
We can fix that by passing in the VPC prefix and using a Sub to formulate the output name.
Creating a CloudFormation Template that uses generic output names
How can we fix all that?
Let’s start with the easy change. VPCPrefix, type String.
Add !Sub to formulate the VPC name so this will work for any VPC.
Of course all of the above depends on standardized templates and naming conventions as I’ve written about throughout this series. If you use my networking templates you’ll get those standard naming conventions.
Now for the hard part.
Initial attempt to deal with the inflexible policy document parameter
Next I thought about adding some conditions based on the service for which the VPC Endpoint is created.
I can use those conditions to add different statements to my policy based on the service:
Now as you can imagine, this is going to get extremely ugly as more and more services are added. It’s error prone and likely to lead to security problems if someone makes a mistake. You’ll have to modify the template for each new service for which you deploy an endpoint. Ugh.
A generic policy document template
Next I wanted to make the template more generic by allowing the caller to pass in the principals and resources to which the policy applies. Hopefully the people deploying VPCEndpoints in our organization know what they are doing and will create appropriate policies and restrictions as this is a critical security function. VPCEndpoints also need to be tested after deployment to make sure they work properly, as with any cloud infrastructure you deploy.
Well if we are going to parameterize all that, why not just parameterize everything, including he actions?
Generally principals get more broad read only permissions and more restrictive write permissions. What if we do something like this:
Will that work? Because this is an aha moment that simplifies a lot of other policies potentially.
I need to pass in the parameters:
I’m going to default the action to Allow but let someone pass in Deny. That’s because it’s easier to add the Deny statement than it is to create all the condition logic to optionally add the read or write statement. If no write permissions are allow just pass in some write condition and deny it.
Well, let’s test it out. I’m going to try to use this template to deploy a VPC Endpoint for CodeCommit and then I can go back and modify my code for CloudFormation later. For now this is a separate template so I don’t break the old code.
I’ll try this out in the next post because I have to deploy the related networking this resource depends on before I can test this out. I presume it will work since I pass in principals as a comma-delimited list in a key policy but we’ll find out. I’m bracing myself for lots of CloudFormation error messages in the process, but once it works it should come in handy in other places as well.
Now, this isn’t ideal. What if you need a more complex policy? This is a bandaid fix for a bigger problem — AWS needs to stop treating PolicyDocuments as a blob. For every place where people deploy a policy, they need to be able to also deploy a list of statements within that policy. The policy in the above case should be a standalone resource, and every statement in a policy should be a standalone resource that you can deploy separately. That would eliminate a whole host of problems, error messages due to one-off templates, and reduce code complexity in a lot of different ways. #awswishlist
I added this to my CloudFormation wishlist:
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 LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow 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
