GCP Enterprise Landing Zone | Access Controls using Deny Rules to maintain compliance

Identity and Access management is sensitive at maintaining a proper security posture in any organisation. An overly permissive role might lead to a high impact breach. An attacker can establish control of an entire cloud environment just by exploiting an IAM misconfiguration such as overly permissive roles.

As a best practice in any cloud environment, we should follow “least privileged access”. This is easier said than done.

In an enterprise landing zone, we have broadly two groups working on the landing zone ie the central team ( Infrastructure Team / SRE ) and the application infrastructure team ( SRE, DevOps ).

Central Team : The central team is responsible to maintain the Networking, Security and the core infrastructure to onboard any application infrastructure onto the landing zone. The central team would have privileged access because they would take care of the core infrastructure. These privilege access are given to small set of members and their activities are monitored. Their main goal is to maintain security, compliance and the core infrastructure.

Application Infrastructure Team : There can be many Application Infrastructure team based on the number of applications on-boarded on the landing zone. They are responsible to create infrastructure specific to their application. The team needs to comply to the standards set by central team

The following diagram shows a simple landing zone design to demonstrate the access distribution between the two groups :-

Figure 1.0

In the above figure, the central team would be responsible for the Shared VPC Host project. This would include the following components :-

1. Cloud Interconnect
2. Cloud Load Balancer
3. NGFW VMs
4. The VPC, Subnet and VPC Peering creation
5. Provisioning user and subnet access to the service project

On the other hand, the application infrastructure team would be responsible for the individual service project. This would include :-

1. Creation of services like GKE, VM, Serverless or more in the service project

Let’s assume that the above architecture is deployed by a company. As per the requirements of the company, the application infrastructure team should not be able to create any networking components in the service projects. They should use the networking made available to them by the central team; Additionally the application infrastructure should not be able to provide IAM access to any other user. This should be the responsibility of the central team

The above can be achieved by granting the least privilege access to the respective teams to ensure that they have access based on their responsibilities, but think of the following situations :-

1. A user in the Application team was give the compute admin role on the service project to manage the compute resources. This was a mistake by the engineer in the central team. He was supposed to provide compute instance admin but provided compute admin role. The compute admin role would enable the user to create and update VPC, Subnets in the service project. Hence, it would lead to violation of the company policies.
2. The central team was asked for the highest access in the development environment to enable the team to deploy applications faster. The central team provided owner access to the users in the development environment. This lead to a major issue, where it was observed that the application infrastructure team started providing multiple other users access to the development environment bypassing the central team

GCP has recently launched the deny rule policy for IAM. ( https://cloud.google.com/iam/docs/deny-overview )

We can make use of the deny rules to manage the access rules maturely. Using the deny rule policy, we can list the set of rules that are highly privileged and should be revoked from the application infrastructure team.

Based on the example presented above, these might include :-

1. compute.networks.*
2. resourcemanager.projects.setIamPolicy

These rules can be applied to all the users on-boarded as the application infrastructure team / non central team. This would ensure that the privileged access is not provided to them even after IAM misconfigurations.

Revisiting the scenarios discussed above,

Now, if the central team mistakenly provides the compute admin role to a user in the service project. This time the user won’t have access to create or update network. The deny rule would be evaluated first, and privileged access would be revoked. Hence keeping the system intact even after IAM misconfiguration

Authors | Ankit Awal | Bhavish Kumar | Roshan Y