Access control with IAM

This page describes how you can control access to Sensitive Data Protection resources.

Sensitive Data Protection uses Identity and Access Management (IAM) to control access to resources. IAM is a tool to manage fine-grained authorization for your Google Cloud resources. In other words, IAM lets you control who can do what on which resources.

To give users access to a resource with IAM, you grant them specific roles. IAM roles give the principals permissions to perform tasks on your Sensitive Data Protection resources.

For detailed information about IAM and its features, see the IAM documentation .

Managing access to Sensitive Data Protection resources

The most common way to manage access with IAM is to use allow policies . Allow policies list which principals have access to the resource and what actions they can perform on the resource.

The following sections describe how to grant and revoke a single role with allow policies using the Google Cloud console and the Google Cloud CLI. You can also grant and revoke multiple roles at the same time. For more information, see Manage access to projects, folders, and organizations in the IAM documentation.

These sections focus on granting and revoking access at the project level, which controls a user's access to the project and all resources within the project.

You can also use allow policies that are attached to different Google Cloud resources to manage access at other levels of the resource hierarchy. To learn more, see Using resource hierarchy for access control in the IAM documentation.

Not all resources support allow policies. To learn which resources you can attach allow policies to, see Resources that support allow policies in the IAM documentation.

To learn about other policies you can use to control access with IAM, such as deny policies, see IAM policy types in the IAM documentation.

Grant a single IAM role

To grant a single role to a principal, do the following:

Console

  1. In the Google Cloud console, go to the IAM page.

    Go to IAM

  2. Select a project, folder, or organization.
  3. Select a principal to grant a role to:
    • To grant a principal an additional role on the resource, find a row containing the principal, click Edit principal in that row, and click Add another role .

      To grant a role to a service agent , select the Include Google-provided role grants checkbox to see its email address.

    • To grant a role to a principal who doesn't have any existing roles on the resource, click Grant Access , then enter a principal identifier —for example, my-user@example.com or //iam.googleapis.com/locations/global/workforcePools/example-pool/group/example-group@example.com .
  4. Select a role to grant from the drop-down list. For best security practices, choose a role that includes only the permissions that your principal needs.
  5. Optional: Add a condition to the role.
  6. Click Save . The principal is granted the role on the resource.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. The add-iam-policy-binding command lets you quickly grant a role to a principal.

    Before using any of the command data below, make the following replacements:

    • RESOURCE_TYPE : The resource type that you want to manage access to. Use projects , resource-manager folders , or organizations .

    • RESOURCE_ID : Your Google Cloud project, folder, or organization ID. Project IDs are alphanumeric, like my-project . Folder and organization IDs are numeric, like 123456789012 .

    • PRINCIPAL : An identifier for the principal, or member, which usually has the following form: PRINCIPAL_TYPE : ID . For example, user:my-user@example.com or principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/example-group@example.com . For a full list of the values that PRINCIPAL can have, see Principal identifiers .

      For the principal type user , the domain name in the identifier must be a Google Workspace domain or a Cloud Identity domain. To learn how to set up a Cloud Identity domain, see the overview of Cloud Identity .

    • ROLE_NAME : The name of the role that you want to grant. Use one of the following formats:

      • Predefined roles: roles/ SERVICE . IDENTIFIER
      • Project-level custom roles: projects/ PROJECT_ID /roles/ IDENTIFIER
      • Organization-level custom roles: organizations/ ORG_ID /roles/ IDENTIFIER

      For a list of predefined roles, see Understanding roles .

    • CONDITION : The condition to add to the role binding. If you don't want to add a condition, use the value None . For more information about conditions, see the conditions overview .

    Execute the following command:

    Linux, macOS, or Cloud Shell

    gcloud  
     RESOURCE_TYPE 
      
    add-iam-policy-binding  
     RESOURCE_ID 
      
     \ 
      
    --member = 
     PRINCIPAL 
      
    --role = 
     ROLE_NAME 
      
     \ 
      
    --condition = 
     CONDITION 
    

    Windows (PowerShell)

    gcloud  
     RESOURCE_TYPE 
      
    add-iam-policy-binding  
     RESOURCE_ID 
      
     ` 
      
    --member = 
     PRINCIPAL 
      
    --role = 
     ROLE_NAME 
      
     ` 
      
    --condition = 
     CONDITION 
    

    Windows (cmd.exe)

    gcloud  
     RESOURCE_TYPE 
      
    add-iam-policy-binding  
     RESOURCE_ID 
      
    ^  
    --member = 
     PRINCIPAL 
      
    --role = 
     ROLE_NAME 
      
    ^  
    --condition = 
     CONDITION 
    

    The response contains the updated IAM allow policy.

Revoke a single IAM role

To revoke a single role from a principal, do the following:

Console

  1. In the Google Cloud console, go to the IAM page.

    Go to IAM

  2. Select a project, folder, or organization.
  3. Find the row containing the principal whose access you want to revoke. Then, click Edit principal in that row.
  4. Click the Delete button for the role that you want to revoke, and then click Save .

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To revoke a role from a user, run the remove-iam-policy-binding command:

    gcloud  
     RESOURCE_TYPE 
      
    remove-iam-policy-binding  
     RESOURCE_ID 
      
     \ 
      
    --member = 
     PRINCIPAL 
      
    --role = 
     ROLE_NAME 
    

    Provide the following values:

    • RESOURCE_TYPE : The resource type that you want to manage access to. Use projects , resource-manager folders , or organizations .

    • RESOURCE_ID : Your Google Cloud project, folder, or organization ID. Project IDs are alphanumeric, like my-project . Folder and organization IDs are numeric, like 123456789012 .

    • PRINCIPAL : An identifier for the principal, or member, which usually has the following form: PRINCIPAL_TYPE : ID . For example, user:my-user@example.com or principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/example-group@example.com .

      For the principal type user , the domain name in the identifier must be a Google Workspace domain or a Cloud Identity domain. To learn how to set up a Cloud Identity domain, see the overview of Cloud Identity .

    • ROLE_NAME : The name of the role that you want to revoke. Use one of the following formats:

      • Predefined roles: roles/ SERVICE . IDENTIFIER
      • Project-level custom roles: projects/ PROJECT_ID /roles/ IDENTIFIER
      • Organization-level custom roles: organizations/ ORG_ID /roles/ IDENTIFIER

      For a list of predefined roles, see Understanding roles .

    For example, to revoke the Project Creator role from the service account example-service-account@example-project.iam.gserviceaccount.com for the project example-project :

    gcloud  
    projects  
    remove-iam-policy-binding  
    example-project  
     \ 
      
    --member = 
    serviceAccount:example-service-account@example-project.iam.gserviceaccount.com  
     \ 
      
    --role = 
    roles/resourcemanager.projectCreator

To help avoid revoking any necessary roles, you can enable change risk recommendations . Change risk recommendations generate warnings when you try to revoke project-level roles that Google Cloud has identified as important.

Conditional access

IAM Conditions let you make your policies more granular by granting access to principals only when certain specified conditions are met. Conditions are based on attributes relating to the principal, resource, and request. For example, you can grant a principal access only if they're accessing the resource from a specific location or at a specific time.

Conditions in allow policies are based on the following types of attributes:

  • Resource attributes: Includes the service, type, or name of the resource. These attributes are typically used to change the scope of an access granted by a role binding.
  • Request attributes: Includes details of the request, like the time or access level of the principal who made the request. These attributes let you create conditions that evaluate details about the request, such as its access level, date and time, the destination IP address and port, or the expected URL path.

For more information about the condition attributes supported by Sensitive Data Protection, see the Attribute reference for IAM Conditions in the IAM documentation.

You can't grant conditional access directly on Sensitive Data Protection resources. However, you can grant conditional access to Sensitive Data Protection resource types by granting roles to principals on a container resource, such as a project, folder, or organization, and adding conditions to these role bindings. Conditions added to the allow policy of a container resource are inherited by the resources included in that container resource. For more information about inherited conditions, see Support for inherited conditions in the IAM documentation.

To learn how to add conditions to role bindings, see Managing conditional role bindings in the IAM documentation.

What's next

Create a Mobile Website
View Site in Mobile | Classic
Share by: