Roles
1. Roles
Let's talk more about roles, which define the "can do what on which resource" part of IAM. There are three types of roles in IAM, basic roles, predefined roles, and custom roles. Basic roles are the original roles that were available in the Google Cloud console, but they are broad. You apply them to a Google Cloud project, and they affect all resources in that project. In other words, IAM basic roles offer fixed, coarse-grained levels of access. The basic roles are the Owner, Editor, and Viewer roles. The Owner has full administrative access. This includes the ability to add and remove members and delete projects. The Editor role has modify and delete access. This allows the developer to deploy applications and modify or configure its resources. The Viewer role has read-only access. All of these roles are concentric. That is, the Owner role includes the permissions of the Editor role, and the Editor role includes the permissions of the Viewer role. There is also a Billing Administrator role to manage billing and add or remove administrators without the right to change the resources in the project. Each project can have multiple Owners, Editors, Viewers, and Billing Administrators. Google Cloud services offers their own sets of predefined roles, and they define where those roles can be applied. This provides members with granular access to specific Google Cloud resources and prevents unwanted access to other resources. These roles are collections of permissions because, to do any meaningful operations, you usually need more than one permission. For example, as shown here, a group of users is granted the InstanceAdmin role on project_a. This provides the users of that group with all the Compute Engine permissions listed on the right and more. Grouping these permissions into a role makes them easier to manage. The permissions themselves are classes and methods in the APIs. For example, compute.instances.start can be broken down into the service, resource, and verb that mean that this permission is used to start a stopped Compute Engine instance. These permissions usually align with the action's corresponding REST API. Compute Engine has several predefined IAM roles. Let's look at three of those. The Compute Admin role provides full control of all Compute Engine resources. This includes all permissions that start with compute, which means that every action for any type of Compute Engine resource is permitted. The Network Admin role contains permissions to create, modify, and delete networking resources, except for firewall rules and SSL certificates. In other words, the Network Admin role allows read-only access to firewall rules, SSL certificates, and instances, to view their ephemeral IP addresses. The Storage Admin role contains permissions to create, modify, and delete disks, images, and snapshots. For example, if your company has someone who manages project images, and you don't want them to have the Editor role on the project, grant their account the Storage Admin role on the project. For the full list of predefined roles for Compute Engine, refer to the link in the student PDF. Now, roles are meant to represent abstract functions and are customized to align with real jobs. But what if one of these roles does not have enough permissions, or you need something even finer-grained? That's what custom roles permit. A lot of companies use the "least-privilege" model, in which each person in your organization is given the minimal amount of privilege needed to do their job. Let's say you want to define an "Instance Operator" role to allow some users to start and stop Compute Engine virtual machines, but not reconfigure them. Custom roles allow you to do that.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.