IAM roles for Billing-related Job Functions

This topic shows you how to configure IAM permissions for a set of sample billing scenarios. It provides guidance on which IAM roles to grant to the billing-related functional roles in your company for the scenarios. These examples are mainly targeted at billing administrators and employees who manage billing tasks for an organization.

This document does not explain in detail the billing roles and permissions. For a detailed description of roles and permissions for Billing API, read the Access Control for Billing page.

Startup configuring billing permissions

In this scenario a small startup is trying to configure and use Google billing accounts. They have a handful of engineers who develop and maintain their applications, but none of them manage their billing. They have an office manager, who is responsible for matching payments to invoices, but for compliance reasons the office manager is not permitted to have access to the Cloud Platform resources in the projects. The CEO also holds and manages the credit card details.

The table below explains the billing IAM roles that the Organization Administrator (which is the CEO in this scenario) can grant to the other personas in the startup, and the resource-level at which she grants the roles.

Role: Organization Administrator The Organization Administrator role gives the CEO the ability to assign permissions to the Office Manager.
Resource: Organization
Member: CEO
Role: Billing Administrator The Billing Administrator role allows the office manager and the CEO to manage payments and invoices without granting them the permission to view the project contents.
Resource: Organization
Members: Office Manager, CEO

The IAM policy attached to the organization resource for this scenario will look similar to the following:

{
  "bindings": [
  {
    "members": [
      "user:ceo@example.com"
    ],
    "role": "roles/resourcemanager.organizationAdmin"
  },
  {
    "members": [
      "group:finance-admins-group@example.com"
    ],
    "role": "roles/billing.admin"
  }
  ]
}

The best practice is to use groups to manage members. In the example above, for the second binding, you would add the CEO and office manager to the finance-admins-group. When you need to modify who is able to carry out the function, you simply need to adjust the group membership, negating the need to update the policy. So the two individual user accounts do not appear in the members list.

Finance teams managing budgets

In this scenario, a large organization wants the finance team in each division to be able to set budgets and view team spending in the division, but not have access to the GCP resources. They don't mind if the developers see the spend for their own projects, but a broad view of expenses should not be allowed to the developers.

Grant the roles in table below to the Finance Manager of each division and the developers:

Role: Billing Administrator This role grants the Finance Manager of each division the permission to set budgets and view the spending for the billing accounts in their divisions, but does not give them permissions to view the project contents.
Resource: Billing Account
Members: Finance Manager of each division
Role: Viewer The Viewer role allows the developers to view the expenses for the projects they own.
Resource: Project
Members: Developers of the project.

For this scenario you will need two separate actions to assign the appropriate permissions IAM policies as they are attached at different levels of the hierarchy.

Assigning permissions to the billing account :

To grant a user the billing admin role to the billing account you need to do this via the billing console . From the account that has set up the billing account, grant the Finance Manager billing administrator rights for the billing account

The IAM policy which needs attaching to the project will look similar to the following:

{
  "bindings": [
  {
     "role": "roles/viewer",
     "members": [
               "group:developers@example.com"
     ]
  }
  ]
}

Customer self service portal, Developers cannot adjust billing

In this scenario, a customer's central IT team provides Google Cloud Platform resources to their developers as part of their self service portal. Developers request access to Cloud Platform projects and other approved cloud services via the portal. The cost center of the developer pays the Central IT team for the cloud resources consumed.

The Central IT team must be able to:

  • associate projects with billing accounts.
  • turn off billing for projects.
  • view the credit card information.

They must not have permissions to view the project contents.

Developers should be able to view the actual costs of the Cloud Platform resources being consumed, but shouldn't be able to turn billing off, associate billing with projects, and view the credit card information.

Role: Billing Administrator The Billing Administrator role grants the IT department the permissions to associate projects with billing accounts, turn off billing for the projects, and view the credit card information for the accounts that they resell to their customers.

It does not give them permissions to view the contents of the projects.

Resource: Billing Account
Member: IT department
Role: Billing User The Billing User role gives the service account the permissions to enable billing (associate projects with the organization's billing account for all projects in the organization) and thereby permit the service account to enable APIs that require billing to be enabled.
Resource: Organization
Member: Service account that is used for automating project creation.
Role: Viewer The Viewer role allows the developers to view the expenses for the projects they own.
Resource: Project
Members: Developers of the project.

For this scenario you will need two separate operations to assign the appropriate IAM policies as they are attached at different levels of the hierarchy.

To grant a user the billing admin role for the billing account, you need to do this via the billing console. From the account that has set up the billing account, grant the Finance manager billing administrator rights for the billing account.

You then need two separate IAM policies as you are attaching them at separate levels of the hierarchy.

The first IAM policy that needs to be attached at the organization level is to grant the service account billing user permissions. It will look similar to the following.

{
  "bindings": [
  {
     "role": "roles/billing.user",
     "members": [
       "serviceAccount:my-project-creator@shared-resources-proj.iam.gserviceaccount.com"
     ]
  }
  ]
}

The second IAM policy that needs to be attached at the project level is to grant the developers viewer permissions to the project

{
  "bindings": [
  {
     "role": "roles/viewer",
     "members": [
       "group:developers@example.com"
     ]
  }
  ]
}

Developers creating billed projects

A large digital native wants to allow all their developers to create billed projects on their Organization's invoiced account without giving them billing admin rights.

A project needs to be billing enabled to ensure that API's beyond the default can be enabled thus if a developer creates a project they need to associate it with a billing account to enable the API's.

Resource: Project The billing creator role will enable the developers to:
  • Create new billing accounts
  • Attach the billing accounts to the projects
Role: Billing Creator
Members: Developers

The IAM policy for this scenario which needs to be attached at the project level will look similar to the following:

{
  "bindings": [
  {
     "role": "roles/billing.creator",
     "members": [
               "group:developers@example.com"
     ]
  }
  ]
}

Cost aggregation

In this scenario, a company wants to calculate and keep track of how much each team, department, service or project is costing them. For example, keep track of how much does a test deployment cost them each month.

This can be tracked by using the following practices:

  • Use projects to organize resources. Cost is shown per project and project IDs are included in billing export
  • Annotate projects with labels that represent additional grouping information. For example, environment=test. Labels are included in billing export to allow you to slice and dice further. However, labels on a project are permissioned the same way as the rest of the project's metadata which means a project owner can change labels. You can educate your employees about what not to change and then monitor (through audit logs), or grant them only granular permissions so they can't change project metadata.

You can export to JSON and CSV, but exporting directly to BigQuery is the solution we recommend. This is easily configurable from the billing export section of the billing console.

If each cost center must pay a separate invoice or pay in a separate currency for some workloads, then a separate billing account for each cost center is required. However this approach would require an affiliate agreement signed for each billing account.

Send feedback about...

Cloud Identity and Access Management Documentation