P0’s security features for GCP: A primer

P0 integrates with your Google Cloud projects in order to manage IAM access for your users. When an engineer needs an elevated level of access, they can request it through P0, and our tool manages provisioning the access and revoking it once an expiration time period has passed. This requires P0 to have a significant level of access to your production projects, so it is natural to be concerned about whether this could create security vulnerabilities for your organization. In this blog post, I’ll explain how our integration is secure by design: even if P0’s infrastructure is compromised, an attacker will not be able to use that to get access to your Google Cloud projects.

Installing our integration

Before I dive into our security model, let’s understand how our integration works.

To install, we ask you to run gcloud commands that give a P0 account a custom role containing the permissions our tool requires on each of the projects you would like to configure with our tool. This P0 account lives in our environment

It contains the following permissions on your project:

• Get the project metadata

• Get and set IAM policy on the project

• Get and set IAM policy on service accounts

• Create, delete, and read operations on custom IAM roles some text
  • Note that the ability to update custom roles is not granted to our service account. This means the P0 account cannot grant itself further permissions by updating its custom role.

These permissions are necessary for the core functionality of our tool: getting/setting the IAM policy is necessary for provisioning access, and we need the permissions on custom roles to create minimally-privileged roles that contain only the permissions a user needs.

Potential attack vectors

When providing this level of admin access to a third-party integration, a key concern is whether the permissions can be abused by malicious actors in a way that allows them to gain access to your environment.

There are several attack vectors to consider here:

• A user in your organization is able to hijack P0’s privileges to escalate their own privileges outside of the tool.

• An attacker compromises P0 and attempts to use our privileges to gain access to your projects.

• A different P0 organization attempts to use our tool to gain access to projects that you have configured with P0.

I’ll go through each possible attack and explain how P0’s Google Cloud integration is designed so that you are protected in all of these cases.  

Privilege escalation within your organization

To understand how this vulnerability can arise, let’s consider a hypothetical access management tool that requires creating a highly-privileged service account within your Google project: for example, maybe access is provisioned by an agent that runs in your environment. Now any user with existing permissions to act as or impersonate all service accounts (for example, someone with the Service Account Key Admin  role) effectively also has IAM admin permissions, since they can simply impersonate the privileged service account and grant themselves access.

‍

P0’s integration does not suffer from this problem, because we do not create any privileged resources in your Google Cloud projects. Instead, installation directly grants permissions to an account running on our environment. This means that nobody in your organization, regardless of their permissions on the project, will be able to use the privileges granted to the P0 account through any means other than our tool.

An attacker that gains access to P0’s systems

Now consider an attacker that is able to fully compromise P0, gaining admin access to our internal environments. They would have full control over the P0 account with IAM permissions on your Google projects.

‍

We utilize Google’s domain restricted sharing policy to ensure that even in this very extreme scenario, the attacker would not be able to abuse our privileges to gain access to your projects.

‍

Domain restricted sharing is an organization-level policy that whitelists the domains that can be used in IAM policies. For accounts with domains not part of the whitelist, their existing privileges are not affected, but they cannot be granted any further IAM roles or permissions.

‍

During our installation process, after you grant P0 the necessary roles, we will ask you to enable domain restricted sharing on the projects you have installed, restricting IAM policies to only your domain. This will not impact any existing permissions to other domains, but it ensures that any attempt to assign further permissions to an external domain will fail.

For example, if the P0 account attempts to assign itself any additional roles, saving the IAM policy will fail because you have not whitelisted the p0.dev domain. This means that P0 can never acquire any greater permissions than those assigned to it on installation, nor could the attacker use it to grant themselves permissions on your projects.

‍

If you’re familiar with the IAM systems of other cloud providers, you may be concerned about federated access. AWS, for example, allows you to grant access to an external federated identity entirely through attaching IAM policies.

‍

Google, however, works differently: in order to add federated users to IAM policies, you need to first configure a workforce or workload identity pool. Both of these require their own set of permissions in order to create/modify the identity pools. If the customer has enabled domain restricted sharing during their installation, P0 will never be able to have these permissions, nor can P0 give these permissions to any external attacker that may have compromised our systems.

Attacks from other P0 organizations

Since the installation process directly gives a P0 account access to your project, a potential attack is that another P0 customer may attempt to also add your account to their P0 tool, using the permissions you have already granted to P0.

‍

While the domain restriction policy already prevents individuals from outside your organization gaining access in this manner, we still needed an additional safeguard against this kind of attack, since an individual within your organization may try to set up another P0 tool that they have approval permissions on in order to grant themselves unauthorized access.

‍

We protect against this by forcing the user who is configuring the project to prove that they have admin access to it. This is done by only allowing users to proceed with installing a project if P0 does not already have permissions on it, meaning that they must be the ones to grant access, which functions as evidence of admin access. Furthermore, as an additional safeguard, we only allow the same Google project to be configured in a fixed number of P0 organizations, and each P0 organization configured for the same project will have to grant permissions to a unique P0 account. This means that no other P0 user can use the permissions you have granted to add the same project to their tool.

To dive deeper into P0 Security, explore our guided tour of workflows here, or refer to our detailed docs. You can also join our community Slack channel to engage with like-minded users.

‍