While AWS IAM can be a tricky beast, those of us in the cloud security practitioner world follow the best practices of reducing surface attack area by eliminating IAM user static credentials and relying on assume-role style access for our integrations with AWS APIs.

In Google Cloud, things aren't so great. Almost every reference document, 3rd party integration, API library you will run across gives the same advice: create a GCP service account and then download a static keyfile for that account and pass it around as needed. This is a huge step back on the security front, and very little discussion exists on how to improve the situation. Furthermore, if your organization uses Google Workspace, and even if you aren't running any workloads in Google Cloud, it's very likely you may have service accounts and static credentials floating around with access to key resources in your org - and not know it.

Fortunately, there are solutions.

In this talk, we'll review the state of affairs as to how IAM auth in Google Cloud compares to that of AWS, and how Google Cloud and Google Workspace credentials overlap. We'll especially look at improvements to the process using Google's Workload Identity Federation, with emphasis on how to eliminate static credentials. We'll see that some Google tooling doesn't even work with their own solutions for authentication, and how you can work around it. And finally we'll look at how you can even leverage AWS IAM as an identity provider for Google Cloud.