Get startedGet started for free

Authorization with Cloud IAM

1. Authorization with Cloud IAM

First, we review IAM authorization. IAM lets you manage access control by defining who (the principal) has what access (role) for which resource. You can grant more granular access to Google Cloud resources by using the security principle of least privilege, which means that you should only grant access to resources that are necessary. You can specify who has access to your resources with IAM principals. A Google Account represents a developer, an administrator, or any other person who interacts with Google Cloud. A service account is an account for an application or compute workload instead of an individual end user. When you run code that's hosted on Google Cloud, the code runs as the account you specify. You can create as many service accounts as needed to represent the different logical components of your application. A Google group is a named collection of Google Accounts and service accounts. Every Google group has a unique email address that's associated with the group. Google Groups are a convenient way to apply access controls to a collection of users. You can grant and change access controls for a whole group at once instead of one at a time for individual users or service accounts. Google Groups don't have login credentials, and you cannot use Google Groups to establish identity to make a request to access a resource. A Google Workspace account represents a virtual group of all Google Accounts that it contains. Google Workspace accounts are associated with your organization's internet domain name, such as example.com. Like Google Groups, Google Workspace accounts cannot be used to establish identity, but they enable convenient permission management. A Cloud Identity domain is like a Google Workspace account, because it represents a virtual group of all Google Accounts in an organization. However, Cloud Identity domain users don't have access to Google Workspace applications and features. Like Google Workspace accounts, a Cloud Identity domain cannot be used to establish identity. Google groups, Google Workspace accounts, and Cloud Identity domains are convenient ways to apply access policies to collection of users. You can grant access to principals for a Google Cloud resource. Some examples of resources are projects, Compute Engine instances, Cloud Storage buckets, or Artifact Registry repositories. Permissions determine what operations are allowed on a resource. In the IAM world, permissions are represented in the form of . ., for example, pubsub.subscriptions.consume. You cannot assign a permission to a user directly. Instead, you grant the user a role. A role is a collection of permissions. When you grant a role to a user, you grant them all the permissions that the role contains. In this example, all users in the Google group named "staff" are granted the InstanceAdmin role on project_a. Each user would have all permissions contained in the role. IAM supports three different types of roles. Basic roles are highly permissive roles with broad access. For example, the viewer role gets read-only access to all resources in a project. Because basic roles are so broad, they are usually not recommended for production environments. Predefined roles provide granular access to specific Google Cloud resources. Predefined roles are created and maintained by Google. An example role is run.invoker, which lets the user invoke Cloud Run services. Custom roles are user-defined and typically maintained for specific needs. You should create and use custom roles when existing predefined roles are too permissive for your use case. Because you have full control over the permissions given, custom roles can help enforce the principle of least privilege. The principle of least privilege says that you should provide each principal exactly the permissions necessary for it to do its job. You can grant multiple roles to the same user.

2. Let's practice!

Create Your Free Account

or

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.