Reg: Best practices in managing VPC SC Perimeter rules

[Nihanth]

We are managing 16 perimeters in Dev and Prod environments together.

Managing all of them manually is getting tougher and not scalable. So we are planning to automate managing these perimeter configs.

We did build our automation to a certain extent. To build full fledged automation, we need to understand how to standardize the rules. Wanted to know what are the best practices to manage the ingress or egress rules inside perimeters.

I am not sure without standardising them, if it is possible to automate them.

As a first step, I am planning to develop a UI which takes input as VPC SC Unique Identifier and the backend service should be able to fetch the identities, sourceResource, targetResource, etc., and make a GCP api call to add a new rule or modify an existing rule.

• My core question here is, how do I figure out if a new rule is to be added or adjusted it in the existing rules.

• Above should be possible only if the rules are standardised is what I am assuming.

• When I meant standardise, if there are 10 restricted services in the perimeter, rule 1 is dedicated for allowing identities for service1, rule 2 is for service 2... rule 10 is for service 10 , next rule 11 is for identities requiring service 1 and service 2 together, rule 12 is for identities requiring service 2 and service 3 together, and so on.. I agree that this is a poor way of planning to standarise them, but I am not able to figure out what is the correct way of doing this.

• In a particular rule, for suppose if I am deciding the manage BQ service permissions and methods, do I have to manage one for read only permissions and one for read/write/delete permissions? How about the rules where trying to manage the combination of more than one service?

• The standardisation should be designed in such a way that it considers all the limitations GCP has on VPC SC. Like number of max rules, number of max identities with in a rule etc., ( considering the size of biggest perimeter we had 35ingress rules, 25 egress rules and its future growth)

• Important point to note, GCP does not support rules based on string indexes, it only supports integer based indexes. That means, if a rule in between gets deleted, it is difficult to figure out which rule is managed for which service(s).

• Most importantly, any of these design here should not violate security standards.

• Taking IAM permissions in to consideration, relaxing the least privilege access at VPC SC rules level is a good or bad idea?

• In our Org VPC SC is managed by CCOE team and IAM permissions are managed by individual project owners. Our motto is not to trust/rely on project owners to open permissions on least privilege basis.

[Nihanth]

@Marvin_Lucero Any thoughts on this?

[apurv_chandra]

You have just too many question in a single post 🙂.  Your idea of having a UI is unique and will have it's own quirks for development, generally can be kind of managed via custom terraform ,may be reading from a managed list or .Still for the standardisation let's take on a few of them, some of them are pure requirement based and can change.

• Start with naming standards, it can give an idea of what a rule is about rather than having an index based approach. 
• Decide whether to have one or multiple rules for a service because for different use cases you may need different set of permissions and in a single rule you can't manage it. 
• Don't use wildcards , however keep an approach as exceptions. 
• VPC SC and IAM are two separate entities don't mix them.