Restricting Access to Call Lambda Functions to a VPC Endpoint in a Service Control Policy
ACM.314 An SCP policy with multiple conditions evaluated as NOT OR or NOR
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post, I was attempting to use IP addresses to restrict access to using the AWS IP restrictions in a Service Control Policy. It worked for public IPs but not private IP addresses.
I felt like I was forgetting something (it happens) and sure enough while reading around I ran across this post:
Create an identity-based policy with the IAM aws:SourceIp and aws:ViaAWSService condition keys that denies access to all actions outside the specified IP address range. Only public IP addresses or public IP ranges are supported. The aws:SourceIp condition key is always included in the request, except for requests that use [include] an Amazon VPC endpoint.
That last line isn’t true, because the SourceIP exists in the CloudWatch data events we were looking at in the last post, which made this entirely confusing.
But ah, yes, now I remember. When we added VPC endpoints to S3 buckets we had to restrict to the VPC Endpoint in the request. That really should be called out in this post, which shows private IPs in the policy but that won’t work when the traffic is coming from a VPC Endpoint.
Sent feedback on that.
Meanwhile, I found this post that has all available policy condition context keys, which is helpful.
There’s a key for source VPC endpoint:

From the linked documentation our policy condition will look like this:

Let’s see if our data event request has a VPC endpoint in it. Yes it does.

I’m going to add the VPCE condition to my policy along with the IP address restriction and test to see that it works.
How can we add multiple conditions to a policy that say deny the action if it is not this OR that?
When multiple values are specified for a single context key in a policy with negated matching condition operators, the effective permissions work like a logical
NOR. In negated matching, a logicalNORorNOT ORreturns true only if all values evaluate to false.
Multiple conditions are added to a policy in this format:

After adding that condition, I can both invoke the Lambda function from the EC2 instance in the VPC by way of the VPC Endpoint. I can also still view the Lambda function in the console and test it there by way of the public IP address. That is obviously not my public IP below. Also notice I have two VPC endpoints in the policy, as I expect to be calling functions from other functions in the future.

Why was this important? The Lambda functions I’m going to invoke are going to have credentials and access to my GitHub repositories. Now I have a way to restrict access both by IP address and a secret access token. I can still do one other thing to limit access to execution of the Lambda function when using MFA and updating secrets only when hardware MFA is in use.
If you are having problems with your VPC Endpoint check out these posts:
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






