Add a Coverage to an AWS VPC Endpoint | by Teri Radichel | Cloud Safety | Nov, 2022

By Admin

November 12, 2022

0

2

ACM.109 Combining IAM and community controls to enhance cloud safety defenses

It is a continuation of my collection of posts on Automating Cybersecurity Metrics.

In a previous put up we created an AWS VPC Endpoint to make use of with CloudFormation.

Then we valiated that the visitors traverses a non-public route.

VPC Endpoint Coverage

Now let’s add a coverage to our VPC endpoint. A coverage on a VCP endpoint is an IAM management. It bases entry on the id of the principal that wishes to entry the endpoint, relatively than the useful resource’s deal with on the community.

Principals for our VPC Endpoint Coverage

Who can we need to permit to entry our CloudFormation endpoint? Now we have plenty of roles, teams, and customers that deploy completely different elements of our infrastructure in our cloud setting in our present implementation.

Long run, I need to have completely different roles function out of various accounts. For now I’m going to grant the next roles permission to entry the VPC Endpoint, and thereby entry CloudFormation to deploy applicaitons utilizing developer credentials:

There are some cross-region limitations with VPC EndPoints however I don’t see limitations with cross-account entry within the documentation. We’ll take care of any associated issues with this method once I get round to implementing all that.

Actions in VPC Endpoint Insurance policies

What kind of restrictions would possibly we need to make with reference to actions on the endpoint coverage? The documentation doesn’t actually say something about endpoint coverage actions.

We are able to get some hints on what is feasible by taking a look at pattern endpoint insurance policies for the API gateway:

We’re utilizing our coverage for CloudFormation instructions that routed to the VPC endpoint for CloudFormation, so I presume the coverage applies solely to these associated instructions. I presume different AWS actions taken for another service relatively than CloudFormation wouldn’t be affected even when we deny them in our coverage, However the documentation is just not clear on that time. For now, we’ll create a coverage that offers our roles the identical CloudFormation permission that exists within the corresponding IAM Coverage.

Who will deploy our VPC endpoint insurance policies?

It doesn’t seem that the coverage doc will be deployed individually from the VPC endpoint, so our community position will deploy the Coverage Doc together with the endpoint. The coverage doc is a useful resource coverage on the endpoint so this sort of is sensible. The community staff manages useful resource insurance policies for community sources.

What’s attention-grabbing about this method:

Now community groups can be dealing with id associated useful resource insurance policies, not simply community configurations.
If you wish to restrict what CloudFormation stacks folks can edit, your IAM and community staff have to coordinate so each IAM and VPC Endpoint insurance policies align and supply the required permissions.
With this method you’ve got a sort of multi-factor coverage. Two folks on two completely different groups should make a change to provide somebody entry to a brand new useful resource.
That is good for safety, however you’ll additionally need to ensure you have this automated and a course of for shortly adjusting these insurance policies as wanted. If this had been to grow to be a highway block many executives would order this out of existence or give all of the permission to 1 staff to get it accomplished sooner.

Set it up, take a look at it, and plan for change, however it’s a excellent method to restrict errors and inadvertent coverage adjustments that grant an excessive amount of entry. Let’s say an attacker stole your IAM administrator’s credentials. They nonetheless wouldn’t be capable of deploy to stacks they need to not since altering the IAM Coverage alone wouldn’t grant them entry.

Our app deployment position restricts actions to sure stacks with specific names, nonetheless they don’t forestall somebody from deploying a useful resource they shouldn’t inside these stacks. You’re nonetheless depending on the IAM Insurance policies for that. However the attacker couldn’t delete and redeploy a stack with a special identify comparable to one which began with Community or IAM so they may not have an effect on present sources.

Create a VPC Endpoint Coverage

It’s unlucky that the VPC Endpoint documentation doesn’t hyperlink to an precise coverage doc construction. Right here’s what exists within the documentation for the PolicyDocument property:

Fortunately we will scroll to the underside to search out an instance:

Appears to be like like a normal coverage. I can principally copy the related portion from the IAM roles and add it to my coverage doc. Be aware that I added permission for this position to explain any stack as a result of in any other case the consumer would want so as to add a filter to the describe stacks motion each time. Chances are you’ll or might not need to try this in your setting.

Add the PolicyDocument property to the VPC Endpoint.

The unlucky factor in regards to the above is that it our template is now not generic. Now we have a PolicyDocument property particular to our endpoint. It has two statements. We might simplify that down to 1 single easier both extra restrictive or much less restrictive assertion.It could be higher of AWS would simply allow you to create the coverage doc in a separate stack and reference the output for it in CloudFormation.

Redeploy the VPC endpoint.

Properly, that didn’t work. The error message doesn’t inform us what’s mistaken with our coverage so it doesn’t assist us an excessive amount of.

Ah, sure, forgot to place AWS: in entrance of the Principal identify, and actually it must be an ARN.

As a aspect be aware whereas attempting to resolve the above downside I discovered these examples of utilizing a corporation ID in a VPC endpoint coverage:

Lastly — this deploys:

I wrote about how AWS might present nicer error messages for PolicyDocuments right here:

Take a look at the VPC Endpoint

Login into the Developer VM with the position profile assigned to it as we did on this put up:

https://medium.com/cloud-security/creating-a-role-for-an-ec2-instance-with-cloudformation-b699f39c0e0c

Run the next command to make sure the position assigned to the EC2 occasion can nonetheless describe stacks:

aws cloudformation describe-stacks

That works.

Now what did we permit this position to do in our account? One factor the AppDeploy position is allowed to do is deploy a developer VM however we don’t need to redeploy the VM we’re utilizing. We additionally allowed this position to deploy Lambda capabilities. Let’s attempt to redeploy our Lambda operate created within the following put up and confirm that works.

We have to set up git once more and whereas we’re at it replace this occasion and clone our GitHub repo.

sudo yum replace -y
sudo yum set up git -y
git clone https://github.com/tradichel/SecurityMetricsAutomation.git

Subsequent what I needed to do is transfer the code to deploy the lambda to a separate script as a result of I even have the AppSec profile within the lambda deploy.sh script. I’ve a plan to repair that later. The code to deploy my Lambda operate:

The opposite downside is that my code wants a profile named “AppDeploy” to deploy the Lambda code. I’m utilizing the AWS default profile which is related to the position that’s assigned to the EC2 occasion.

I wanted so as to add a brand new position profile and reference the default profile credentials like this in my ~/.aws/config file:

Appears to be like like it really works.

Take a look at not solely what’s allowed, however what is just not allowed

To finish testing, you’ll additionally want to check the next to ensure you have an efficient coverage:

Take a look at deploying a CloudFormation stack with out “AppDeploy” within the identify.
Take a look at a CloudFormation deployment with credentials not allowed by the VPC Endpoint.

Possibly you’ll be able to consider another bypass circumstances which you could take a look at to make sure your insurance policies solely permit what they need to.

Within the subsequent put up we’re going to take a more in-depth take a look at the AWS visitors that’s nonetheless not maintained inside our personal community.

Comply with for updates.

Teri Radichel

For those who appreciated this story please clap and observe:

Medium: Teri Radichel or E mail Listing: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers through LinkedIn: Teri Radichel or IANS Analysis