Solved: VPC SC Perimeter split up

Nihanth · 01-17-2024 09:56 AM

The VPC SC Perimeter we manage has close to 700 projects, 35 Ingress rules and 30 Egress rules. For some security reasons, we wanted to split the projects in to two different perimeters.
We redirect violation logs to Splunk as well.
Since the perimeters are very sensitive and anything that is going wrong will have huge impact, I wanted to take some inputs on the process I am following to split up the perimeters.
First step is to modify the resources to protect. These 700 projectIds do follow a naming convention, I can easily find them by name and move them accordingly to appropriate perimeters. I am using dry run mode to do these changes. After all the changes, after reviewing it multiple times, would like to enforce it.
Next is Ingress rules. Based on the rules in the existing perimeter, and more specifically based on the projectIds in the To section of an ingress rule, I am splitting them to appropriate perimeters.
Wherever there is All Projects in the To section, I am having it in both the perimeters.
pretty much wanted to follow similar process for egress rules as well.
At the end, I will look at the Splunk logs for any dry run violations that are happening and would like to allow them in the Ingress/Egress rules. Although this seems to me a challenging way, will have to

I am very much worried on the surprises.
I have an automation in place to change any rules in the policies in the perimeter where the source of truth is Github. So Before enforcing the changes, I will take a backup in the github and be ready to combat any surprises. But would like to avoid going back and forth.
Any inputs?

Marvin_Lucero

Hi @Nihanth ,

Your approach to split the perimeters into two separate ones is a good idea. However, there are a few things you can consider to minimize the risk of surprises and ensure a smooth transition.

1. Before implementing the changes, it is important to thoroughly test them. You can create a test environment with a subset of your projects and rules to validate the changes. This will help you identify any potential issues before applying the changes to the production environment.

2. Document everything, especially the changes that you're making. This will help you and your team understand the reasons behind the changes and make it easier to troubleshoot any issues that may arise.

3. Continuously monitor the logs and metrics of your VPC service control perimeter to identify any unexpected behavior or violations. This will help you detect and address any issues promptly.

4. As you mentioned, having a backup in Github is a good idea. Additionally, consider taking a snapshot of your current perimeter configuration before making any changes. This will allow you to revert to the previous configuration if needed.

TIP: For splitting the resources, ingress, and egress rules, you can create new perimeters and apply the necessary resources, access levels, and rules. It is recommended to use the --dry-run flag while applying changes to verify the updates before enforcing them. Moreover, taking regular backups and monitoring the logs in Splunk will help you combat any surprises and ensure a smooth transition.

Let me know if this helps.

View solution in original post

Marvin_Lucero