Identity and Access Management (IAM) provides multiplepredefined roles for most Google Cloud services. Eachpredefined role contains the permissions that are needed to perform a task, or agroup of related tasks. This document helps you choose the right predefinedroles for a given task.

For some tasks, finding an appropriate predefined role is oftenstraightforward. For example, if a principal needs to view objects in aCloud Storage bucket, then the Storage Object Viewer role(roles/storage.objectViewer) is likely to be a good fit.

However, there are hundreds of predefined roles, which can make it difficult toidentify the most appropriate roles to grant to your principals. It can also bechallenging to find roles that follow the principle of least privilege, whichstates that principals should have no more permissions than they actually need.

Note: If you're getting started with Google Cloud, you can identify and grantcore IAM roles as part of theGoogle Cloud setup process.

This page walks you through the process of manually choosing the mostappropriate predefined roles:

1. Identify the necessary permissions.
2. Find roles that contain the permissions.
3. Choose the most appropriate roles.
4. Decide where to grant the roles.
5. Grant the roles to a principal.

Alternatively, you can ask Gemini to suggest the predefined rolesthat a principal needs to perform a given task. For more information about thisfeature, seeGet predefined role suggestions withGemini assistance.

Identify the necessary permissions

To identify the permissions that a principal needs, start by listing the tasksthat they need to perform, and the Google Cloud services that they'll usefor those tasks. For example, a principal might need to use Compute Engine tocreate virtual machine instances.

After you identify the tasks and services, there are a few strategies you canuse to identify the necessary permissions for each task:

• Check the documentation for the Google Cloud services.

  For some services, the task-oriented how-to guides list the roles orpermissions that you need for each task, either in a "Before you begin"section or with the instructions for each task. For example, see theCompute Engineprerequisites for importing and exporting VM images.

  Some other services identify required roles and permissions on a page aboutaccess control. For example, see the Pub/Subrequired permissions for calling Pub/Sub methods.

• Identify the REST or RPC API methods that you would use to complete the tasks,and check the API reference documentation for the required IAMpermissions.

  For some services, the REST and RPC API documentation lists the permissionsthat each method requires. For example, see the Compute Enginedocumentation for theinstances.get method.

• Look at the list of permissions for each service, and use your judgment tofind the relevant permissions.

  In most cases, the name of each permission also describes what thepermission lets you do with it. For example, the permission forcreating a Compute Engine VM instance is namedcompute.instances.create.

  To help you understand each permission name, remember that permission namesuse the formatSERVICE.RESOURCE_TYPE.ACTION.

In general, you don't need to identify every permission that's required forevery task. Instead, focus on identifying the most relevant permission for eachtask. If a predefined role contains that permission, it's likely to containrelated permissions as well.

As part of this process, you should also try to identify which of the requiredpermissions are the most powerful. In general, more powerful permissions areincluded in a smaller number of predefined roles. As a result, if you focus onthese permissions, you'll have a shorter list of potential roles to choose from.

For example, the following types of permissions are especially powerful:

• Permissions to create and delete resources
• Permissions to access sensitive data, such as encryption keys or personallyidentifiable information (PII)
• Permissions to set the allow policy or deny policy for a resource
• Permissions to update organizations, folders, and projects, which can causeother resources to inherit the updates

In contrast, the following types of permissions are less powerful:

• Permissions to list resources
• Permissions to access data that is not sensitive
• Permissions to update settings that have limited risk, such as the minimumCPU platform for Compute Engine virtual machine instances

Find roles that contain the permissions

Note: Identity and Access Management (IAM) offers predefined roles that are tailored to specific job functions. If you want to give a user the necessary permissions to perform a specific job function in your organization, consider granting one of these predefined roles. To determine if IAM offers a predefined role for your use case, seePredefined roles for job functions.

After you identify the required permissions, you can search for predefined rolesthat contain those permissions and make a list of roles that might be a goodfit. The easiest way to find these roles is by searching theIAMroles and permissions index for a permission andclicking on the permission name. The reference for each permission tells you theroles that contain the permission.

To follow the principle of least privilege, you might need to identify more thanone predefined role to grant, especially if the required permissions belong tomultiple Google Cloud services. For example, if a principal needs to viewCloud Storage objects and administer Cloud SQL databases, it'sunlikely that a single predefined role contains the appropriate permissions forboth services. If such a role exists, it might also include a large number ofunrelated permissions that the principal doesn't need. To reduce risk, look forone role that contains the required permissions for Cloud Storage, andanother role that contains the required permissions for Cloud SQL.

Choose the most appropriate roles

Now that you have a list of predefined roles that might be a good fit, you canchoose the most appropriate roles from the list.

Start by eliminating the following types of roles:

• For production environments: Basic roles, including Owner (roles/owner),Editor (roles/editor), and Viewer (roles/viewer).

  Basic roles include thousands of permissions across all Google Cloud services. In production environments, do not grant basic roles unless there is no alternative. Instead, grant the most limited predefined roles or custom roles that meet your needs.

• Service agent roles, which typically have titles that end in "Service Agent"and names that end inserviceAgent.

  These roles are intended forservice agents, which are aspecial type of service account that a Google Cloud service uses toaccess your resources. Service agent roles tend to contain permissions formultiple services, which might include services that your principal doesn'tneed to access.

Next, use thepredefined roles reference or theRoles page in the Google Cloud console to list the permissions that each role contains. Check each role for permissionsthat you don't want the principal to have, and eliminate any roles that containunwanted permissions.

If this process eliminates all of the predefined roles, consider creating acustom role to fit your use case. Otherwise,choose the role or roles that contain the fewest number of permissions, whilestill meeting your needs.

Decide where to grant the roles

When you grant a role, you always grant it on a specific Google Cloudresource, which belongs to aresource hierarchy.Lower-level resources, such as Compute Engine VM instances, inherit theroles granted on higher-level resources, such as projects, folders, andorganizations.

Note: Granting a role is also known as creating arole binding in anallowpolicy. Lower-level resources inherit the allow policies and role bindings ofhigher-level resources.

Choose where to grant the predefined roles that you identified:

• If the principal needs access to specific lower-level resources, grant theroles on those resources.

• If the principal needs access to many resources within a project, folder, ororganization, grant the roles on the project, folder, or organization. Choosethe lowest-level resource that meets the principal's needs.

  Also, consider using IAM Conditions togrant the roles only on specific resourceswithin the project, folder, or organization.

If you identified multiple predefined roles, consider whether you should grantthe roles at different levels of the resource hierarchy. For example, if aprincipal needs access to a single Cloud SQL database, but manydifferent Compute Engine VM instances, you might want to grant the rolefor Cloud SQL on the database and the role for Compute Engineon the project.

Grant the roles to a principal

Now you're ready to grant the roles to your principal. To learn how to grantroles, see the following:

• Manage access to projects, folders, and organizations
• Manage access to service accounts
• Manage access to other resources

After you grant the roles, you can use thePolicy Analyzer and Policy Troubleshooter to checkwhich resources the principal can access and troubleshoot access issues.

If the principal has the intended permissions on the correct resources, but theyare unable to complete their tasks, it's possible that you overlooked apermission that the principal needs. Iterate on your previous attempt by addingrequired permissions to the list; finding roles that contain those permissions;and choosing the most appropriate roles.

If you accidentally grant a role with too many permissions, then arole recommendation might suggest a less permissive rolethat would meet the principal's needs. Some role bindingsdon't get role recommendations.

What's next

• Learn how thePolicy Simulator can help you testchanges to a principal's roles.

• Find out how thePolicy Analyzer can tell you what access aprincipal has to a resource.

• Get details abouttroubleshooting access issues.