VPC Endpoint for CloudFormation
ACM.106 Adding an Interface VPC Endpoint to A VPC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: AWS Security | Network Security | Cybersecurity
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I showed how you can provide access to GitHub from AWS with one rule in a security group with an AWS customer-managed prefix list.
Now, finally, we have arrived at the post where I hope to implement VPC Endpoints. I wrote about VCP Endpoints a while ago:
But in order to get to a point where we can test out a VPC Endpoint with CloudFormation we had to set up a number of other resources:
Creating a VPC endpoint with CloudFormation for CloudFormation
Let’s take a look at the CloudFormation documentation for VPC endpoints. They should not be too complicated to deploy.
PolicyDocument: If the service supports a policy document we can create one to limit access to the endpoint via IAM.
Remember this is not a network policy but an IAM policy. It offers a way to enforce authorization — an IAM control — in addition to network restrictions, which is better than one or the other. If you want to know why you need both, that was covered in many of the other blog posts with examples of how attackers can abuse one or the other, and in my book at the bottom of this post. PrivateDnsEnabled: We can ensure DNS requests also remain on the AWS network if we enable this.
RouteTableIds: only applies to gateway endpoints which CloudFormation endpoints are not so we won’t need this.
SecurityGroupIds: This is where we can apply network restrictions to our endpoint. CloudFormation is an interface type endpoint so we can add security groups to it.
ServiceName: This is where we add the specific service that we want to allow via the endpoint. For CloudFormation we enter:
com.amazonaws.region.cloudformationSubnetIDs: We’ll also need to specify subnets for our interface endpoint so we could also apply NACLs if we wanted.
VpcId: This value is also required for all types of endpoints.
Specific Considerations for CloudFormation Endpoints
When you create a VPC endpoint the way you access various resources may change from public to private IP addresses. This can have some effect on your ability to access certain resources. This page in the documentation explains things that might be affected by CloudFormation VPC endpoints.
I don’t think most of those issues apply to us except for this one:
The security group attached to the VPC endpoint must allow incoming connections on port 443 from the private subnet of the VPC.
We’ll add that rule to the security group we create for the endpoint.
VPC for our VPC Endpoint
We are going to create this VPC endpoint in our remote access VPC we created earlier so the Developer VM can use it to reach CloudFormation. We want the DeveloperVM to be able to reach the endpoint. We will just reuse the existing VPC.
Security group for our VPC Endpoint
We will create a new security group specifically for this endpoint and add the rule specified above. By default the endpoint has full outbound access. What if we remove that? Does the endpoint also need outbound access? It doesn’t say in the documentation above but I’m sure it does.
Notice that there are no CloudFormation specific IP ranges on this list:
https://ip-ranges.amazonaws.com/ip-ranges.json
For now we will leave outbound access open. We can review our network logs and may add further restrictions later. We can limit inbound access to from our Developer security group.
We can limit access to and from other security groups based on IDs or names. I prefer to use IDs. We’ll get the ID from our CloudFormation stack outputs.
Subnet for our VPC Endpoint
We also need to make sure our network ACLs on our subnet allow access. This page has some vague guidance.
It says “For Port Range, enter the same port as your endpoint service” — which I presume is 443 from the above documentation. But it’s not really clear on IP ranges and the subnet and security group applied to the endpoint itself.
In any case, our Developer VM already allows access to any IP on the Internet in its NACL so adding the endpoint to the same subnet should just work.
We could put the endpoint in it’s own subnet and restrict access on private IP ranges but we’ll start with this option for now because it is simpler.
Change existing networking to access the endpoint
In addition to adding our networking to our VPC endpoint we have to change our existing networking to allow resources to access the VPC endpoint. Since we are putting the VPC endpoint in the same subnet as the Developer VM we don’t have to add any rules for that. Any resources in the same subnet can communicate with each other and are not impacted by the NACL on that subnet. If you want to enforce rules using a NACL between those resources you would need to put them in different subnets.
When two items have the same security group applied they cannot communicate by virtue of that association. Remember the resources are not in a security group but rather the security group is a group of networking rules applied to the resource. In addition, we have a new security group for our VPC endpoint network interface. So we will need to ensure that our developer security group has access to the security group ID of the VPC endpoint on port 443.
So our networking is going to look like this:
Networking Dependencies
Now we have another circular dependency when creating our networking rules.
- We have to deploy the VPCE access security group before we can reference its ID from the outputs of that stack to deploy the VPCE interface security group.
- We have to deploy the VPCE interface security group before we can reference its ID from the outputs of that stack to deploy the VPCD access security group.
Currently we deploy all the rules for a group when we deploy the group in our deployment script. What’s the minimal code change we can make to this function to achieve our objective?
I ended up moving the creation of a security group to its own function:
I moved the code to get the parameters to deploy a security group rules template to a separate function since I found that I was referencing it from two places.
I decided to create two new security groups to make it obvious to people why the security groups exist based on the names.
Security group for the VPC Endpoint:
Security group to access the endpoint:
Then I call the functions like this from the deploy stack to create the two new security groups, followed by the rules that reference the outputs of the security group stacks:
At the point of initial testing of these stacks I realized I’m consistently getting this error I wrote about in a separate post. I’m not going to muddy up this post with the error but you can read about it here. Hopefully this is fixed in a more user-friendly way by the time you read this. I’ll deal with this later.
After deleting the stacks causing the above issues I got the code working. The two new security groups got deployed initially:
Next I added and deployed the rules and verified those work.
When I test deployments of my security group rules that works and I can validate my rules by checking them in the AWS Console. The VPC endpoint security group allows access inbound from the VCPE access security group.
It allows outbound to anywhere on port 443:
The access security group has no inbound rules:
It allows outbound to the VPCE interface security group on port 443:
Deploying the VPC Endpoint
Now that I have security groups in place I can deploy the VCP endpoint. I created the following template for that. The outputs are hard coded in this template but could be passed in if the need arises later.
Function to deploy the VPC Endpoint in network_functions.sh
Call the function from deploy.sh (after all related networking has been created):
Execute and view the results in the VPC console. Click endpoints on the left and you can see that a VPC endpoint got created of type Interface for the CloudFormation service.
In the next post we’ll update the EC2 instance to use the access security group we created and test out the endpoint.
If you are having problems with your VPC Endpoint check out these posts:
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2022
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
