1st and 3rd Party Groups | Google Cloud Security Showcase

Key Takeaways

Welcome to the Google Cloud Security Showcase, a special web series where we'll focus on security use cases that customers can solve with Google Cloud. My name is Aspen Sherrell, and I'm a cloud security architect at Google. Today, we're discussing VPC Service Controls, or VPCSC in short, our solution for preventing data exfiltration from managed services in Google Cloud. The feature we'll be discussing today is VPCSC's recently launched for first and third-party groups. First, let's level set on what I mean by first and third-party groups. So, first-party groups are a named collection of identities defined in Google's Cloud Identity. Groups can contain users, service accounts, or even other groups. The group is then a single entity you can reference in controls like IAM or VPCSC. Third-party groups involve federated identities from third-party IDPs. These are identities used by workload or workforce identity federation, or WIF, which enable keyless authentication to our platform. Third-party identities can be a single principal or a collection of principals known as a principal set. Now, let's discuss why you might want to use groups versus managing individual identities. Before group support, organizations were burning through attribute quotas managing individual identities in their ingress and egress rules. That entailed pushing frequent small changes to their VPCSC configs. And some organizations were even forced to implement anti-patterns, making their rule base less granular just to recoup some attribute counts. Now, rules with many identities can be consolidated down as much as makes sense. This also lets you move toward managing group membership separately from managing the VPC SC perimeter. Meaning, it lets you delegate. So, teams can add and remove their own members from their own groups without the VPC SC admin having to be involved for every minute personnel change. And finally, organizations often already create specific groups for specific roles in IAM. So, that work can be leveraged in VPC SC without reinventing the wheel. Let's take a look at configuring rules with both first and third-party groups. For my first-party group example, under zero trust, I will come down to VPC service controls. And this is my RSA demo perimeter. Now, I'll edit my perimeter. I'll come down to ingress policies and add an ingress rule, and I will title it appropriately. In this case, I'm granting access to Googlers who need to reach my RSA demo media. For identity, I will come down to select identities and groups. I'll click add identities, and I will enter my group. Then, I'll click add identities. Now, coming from any source is fine, but I do want to scope down this access to just my RSA demo project. Here's my project. I'll click add selected projects. And under operations, I'll click select operations and add operations. And I'm going to search for cloud storage, cuz that's where my media is stored. I'll click that service. I will allow all methods, and I will save my rule. Here's the diff showing my RSA demo media access group specifying cloud storage in this project. And I'll go ahead and click confirm. And now my service perimeter is updated. Here's my rule with my group and my project and my service. For my third-party example, I will again, under zero trust, open VPC service controls. And I'm still in my RSA demo perimeter, so I'll click edit. I'll come down to ingress policies and click add an ingress rule. I'll title it appropriately. In this case, it's an ingress rule for GitHub and GitLab runners. So, I will now select identities and groups. Click add identities. I'll put in the principal set for my get runners. I'll click select sources. Add an access level. And then search for the access level that contains my runner IPs. Accessing all projects, perfectly fine in this case, all operations, perfectly fine. So, I'll go ahead and save my rule. Here's the diff showing the principal set has been added to the rule coming from that access level. And they can access any project in any service. I'll go ahead and click save. Scroll back down, and here is my runner ingress rule with the principal set coming from the access level I specified. Now, I'll cover a few strategies some orgs have used leveraging groups in real-world environments. Some internal use cases involve allow listing contractors or temps or even FTEs or machine accounts from things like acquisitions or mergers. We've also had orgs use groups to allow list their own identities from other clouds. Usually for something like a cross-cloud workload. Some external examples include allow listing in vendors such as MSSPs, GSIs, CSPMs, CNAPs, and any and all flavors of scanners. Also, Google managed service accounts for Google managed services such as Cloud Build and Cloud Functions and SCC. Also examples including IAC or CI/CD tooling like GitHub and GitLab runners. And many, many more. Finally, I want to touch on some points to consider and I'll end with some words of wisdom. First, I'll point out that Google's own IAM best practices recommend not putting service accounts in groups whether for VPC SC or any other purpose. That being said, many Google Cloud customers have use cases that dictate putting service accounts in groups. We added this capability to VPC SC because it was one of the top outstanding asks from our customers. So that said, can doesn't mean should. The capability exists if you need it. And the point is to let you consolidate identities in whatever way makes sense for your organization. Whether that's by human identities or by service accounts. Anytime you're using identities in VPC SC, we strongly recommend layering those identities with additional requirements like source cider ranges, uh Chrome Enterprise attributes, or even geos. You don't want a compromised identity to have easy access to perimeter resources. If you're using workload or workforce identity federation with dynamic resources or attributes, it will likely be easier to allow list principal sets than individual principals. Next, decide on a policy. Some organizations trust machine accounts more than human users, so they will only allow service accounts in groups for their VPC SC rules. Other orgs, meanwhile, prefer to only allow humans in groups. Lastly, find the middle ground between security and usability. Groups make it easier to manage your VPC SC environment, but still maintain good group hygiene, and don't compromise your security posture by allow listing carte blanche access to identities that don't need it. To recap, group support simplifies operationalizing and managing your VPC SC perimeters by letting you consolidate first and third-party identities in your ingress and egress rules where it makes sense. To learn more about VPC SC, watch our other videos or visit our product page.