101

The GCP IAM 101 series is intended to give a brief, succinct overview of essential Google Cloud authorization concepts, answering questions like 'How does Alice gain access to the Bucket?' These pages are the TLDR; for Google Cloud IAM, supplemented with links to official, more verbose Google documentation

In GCP, access to resources is ultimately governed by Cloud IAM Permissions however, individual permissions are not directly assigned to principals. Instead, permissions are grouped together to create roles. These roles, rather than individual permissions, are then granted to principals in an IAM Policy. Roles can range from containing just

Users and Groups are two types of principals that can be granted access in GCP. When users and groups are members in IAM Policies, they are referenced by their Google email addresses. You won't find a directory in Google Cloud listing users or groups. Instead, users and groups

Service Accounts are identities used for authenticating infrastructure and resources, typically for non-human entities. Service Accounts do not utilize passwords. While you have the option to generate and export a private key for a service account, it's generally unnecessary and can pose a security risk in most cases.

Google Cloud is organized into a hierarchy with each level or node of this structure being a resource. At the top of the hierarchy is the Organization followed by any number of nested Folders which then house Projects. At the lowest level of the hierarchy are the widgets the compose

The GCP model for managing access to resources has three main parts: * Who: (the principal) * What: (the role) * Resource In Google Cloud Platform (GCP), permissions are granted by combining the WHO (principal) and the WHAT (role) to form a policy. This policy is then applied, or 'bound', to