Cloud IAM Overview

Identity and Access Management (IAM) is a system for controlling who can access what in Google Cloud. It defines permissions for users, groups, and service accounts to interact with resources like Compute Engine, Cloud Storage, and BigQuery.

The organization node represents your company in the Google Cloud resource hierarchy. It's the top-level entity, and everything else is organized underneath it.

Folders are a way to group projects within an organization. They can be used to organize resources by department, team, or purpose.

Projects are containers for your Google Cloud services and resources, like Compute Engine instances, Cloud Storage buckets, and BigQuery datasets.

Resources are the individual components within a project, such as a virtual machine, a storage bucket, or a database table.

Policies determine what permissions are granted to users, groups, and service accounts. They control who can do what on specific resources.

The resource hierarchy helps organize Google Cloud resources in a tree-like structure. It starts with the Organization, then goes to Folders, Projects, and finally Resources.

IAM policies can be inherited down the resource hierarchy. This means that permissions granted at a higher level apply to all resources below it.

The highest level in the resource hierarchy. Grants control over all resources within the organization.

Allows viewing access to all resources within an organization.

Allows full control over folders, including creating and managing sub-folders.

Allows browsing the folder hierarchy and creating new folders. Can't manage existing folders.

Allows viewing access to folders and projects within a specific folder.

Allows creating new projects and automatically becomes the owner of those projects.

Grants the ability to delete projects.

A type of IAM role that grants predefined, coarse-grained access to resources, offering limited flexibility.

A root node in the Google Cloud resource hierarchy encompassing all Google Cloud resources. Example, "yourcompany.cloud.google.com".

The ability to create and manage projects is inherited by all resources within the organization.

Projects define boundaries within an organization, creating a trusted environment for services within them.

A Google Workspace or Cloud Identity account is directly associated with the Organization resource in Google Cloud.

The super administrator of Google Workspace or Cloud Identity can assign the Organization Admin role to users and act as the point of contact for recovery issues.

The Organization Admin can create and manage IAM policies, defining the structure of the resource hierarchy and delegating responsibilities for Networking, Billing, and Resource Hierarchy using IAM roles.

A Google account represents a developer, administrator, or any person interacting with Google Cloud. It can be any email address associated with a Google account, including gmail.com or other domains.

An account belonging to your application, not an individual user. When running code on Google Cloud, you specify this account for the code to run as.

A collection of Google accounts and service accounts. They have a unique email address and allow applying access policies to a group of users at once.

Different types of members in Identity and Access Management (IAM). These members determine who can access Google Cloud resources.

The ability to start and stop virtual machines (VMs) in Google Compute Engine but not change their configuration.

A system for managing user access to Google Cloud resources. It allows defining roles with specific permissions.

A collection of permissions for users to manage specific Google Cloud services. Examples include compute.instanceAdmin, storage.objectAdmin, and appengine.appAdmin.

Customizable user roles that allow specific actions on Google Cloud resources, such as starting and stopping VMs without reconfiguration.

A service account automatically created for each Google Cloud project. It is named after the project number, given the Editor role, and enabled on instances created with gcloud or the Google Cloud console.

The default Compute Engine service account can be overridden in an instance creation process. This includes specifying a custom service account or disabling the default service account altogether.

Scopes refer to the permissions granted to an authenticated identity. They determine what operations an application can perform on Google Cloud resources.

An access token, generated by the Google Authorization Server, carries specific scopes that define the level of access for an application to Google Cloud resources. The scopes determine actions like reading or modifying data in Cloud Storage.

Scopes define the permissions for an application to access a specific Google Cloud service. Each application can have a unique set of scopes, limiting access to specific actions like only reading data.

You can change the default scopes assigned to a Compute Engine instance after creation. This allows you to fine-tune the instance's access rights.

Instead of customizing scopes for user-created service accounts, use IAM roles for finer-grained access control. IAM roles offer a more flexible and structured way to manage permissions.

Authorization is the process of determining which authenticated identities have access to which specific resources. Scopes are used to define and verify these permissions based on access tokens granted to applications.

Grouping resources based on shared trust boundaries. This makes access control more logical and efficient.

Policies can be applied to a parent resource and automatically inherited by its child resources. For example, a policy applied to a folder will affect all projects within it.

The principle of least privilege encourages granting only the necessary permissions to users and groups. This minimizes the risk of unauthorized access and helps maintain security.

Using groups allows you to easily manage user permissions. Instead of granting roles to each individual, you can add or remove users from a group, which automatically updates their access rights.

Auditing ensures that you're aware of any changes made to your IAM policies and the membership of groups. This helps prevent unauthorized modifications and ensures that access is controlled.

By controlling who owns the Google group, you can ensure that only authorized personnel have the ability to add or remove members. This helps maintain control of the permissions associated with the group.

Creating multiple groups allows you to provide different levels of access based on specific roles. This can help ensure that only the necessary permissions are granted to each user or group.