This topic shows you how to configure Identity and Access Management (IAM) permissions fora set of sample billing scenarios. It provides guidance on whichIAM roles to grant to the billing-related functional roles inyour company for the scenarios. These examples are mainly targeted at billingadministrators and employees who manage billing tasks for an organization.
This document does not explain in detail the billing roles and permissions. Fora detailed description of roles and permissions for Billing API, read theAccess Control for Billing page.
Small company configuring billing permissions
In this scenario a small company is trying to configure and use Google billingaccounts. They have a handful of engineers who develop and maintain theirapplications, but none of them manage their billing. They have an office manager,who is responsible for matching payments to invoices, but for compliance reasonsthe office manager is not permitted to have access to Google Cloudresources in the projects. The CEO also holds and manages the credit carddetails.
The table below explains the billing IAM roles that theOrganization Administrator (which is the CEO in this scenario) can grant to theother personas in the company, and the resource level at which she grants theroles.
| Role: | Organization Administrator | The Organization Administrator role gives the CEO the ability to assign permissions to the Office Manager. |
|---|---|---|
| Resource: | Organization | |
| Principal: | CEO |
| Role: | Billing Account Administrator | The Billing Account 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 | |
| Principals: | Office Manager, CEO |
The allow policy attached to the organization resource for this scenario willlook similar to the following:
{ "bindings": [ { "role": "roles/resourcemanager.organizationAdmin", "members": [ "user:ceo@example.com" ] }, { "role": "roles/billing.admin", "members": [ "group:finance-admins-group@example.com" ] } ]}The best practice is to use groups to manage principals. In the exampleabove, for the second binding, you would add the CEO and office manager to thefinance-admins-group. When you need to modify who is able to carry out thefunction, you simply need to adjust the group membership, negating the need toupdate the allow policy. So the two individual user accounts do not appear inthe role bindings.
Finance teams managing budgets
In this scenario, a large organization wants the finance team in each divisionto be able to set budgets and view team spending in the division, but not haveaccess to the Google Cloud resources. They don't mind if the developerssee the spend for their own projects, but a broad view of expenses should not beallowed to the developers.
Grant the roles in table below to the finance manager of each division and thedevelopers:
| Role: | Billing Account 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 | |
| Principals: | Finance manager of each division |
| Role: | Billing Account Viewer | The Billing Account Viewer role allows the developers to view the expenses for a billing account. |
|---|---|---|
| Resource: | Billing Account | |
| Principals: | Developers of the project. |
For this scenario, use the billing console to grant the Billing AccountAdministrator role to the finance managers on the billing account. In addition,grant the Billing Account Viewer role to the developers on the billing account.
When you are done, the allow policy for the billing account looks similar to thefollowing:
{ "bindings": [ { "role": "roles/billing.admin", "members": [ "group:finance-admins-group@example.com" ] }, { "role": "roles/billing.viewer", "members": [ "group:developers@example.com" ] } ], "etag": "BwUjMhCsNvY=", "version": 1}Customer self-service portal, Developers cannot adjust billing
In this scenario, a customer's central IT team provides Google Cloudresources to their developers as part of their self service portal. Developersrequest access to Google Cloud projects and other approved cloud servicesvia the portal. The cost center of the developer pays the central IT team forthe 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 Google Cloudresources being consumed, but shouldn't be able to turn billing off, associatebilling with projects, and view the credit card information.
| Role: | Billing Account Administrator | The Billing Account 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 | |
| Principal: | IT department |
| Role: | Billing Account User | The Billing Account 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 | |
| Principal: | Service account that is used for automating project creation. |
| Role: | Billing Account Viewer | The Billing Account Viewer role allows the developers to view the expenses for a billing account. |
|---|---|---|
| Resource: | Billing Account | |
| Principals: | Developers of the project. |
For this scenario you will need two separate operations to assign theappropriate allow policies as they are attached at different levels of thehierarchy.
Use the billing console to grant the Billing Account Administrator role to theIT department on the billing account. In addition, grant the Billing AccountViewer role to the developers on the billing account.
You then need to attach an allow policy at the organization level. This allowpolicy grants the Billing Account User role to the service account. It issimilar to the following:
{ "bindings": [ { "role": "roles/billing.user", "members": [ "serviceAccount:my-project-creator@shared-resources-proj.iam.gserviceaccount.com" ] } ], "etag": "BwWKmjvelug=", "version": 1}Developers creating billed projects
A large digital native wants to allow all their developers to create billedprojects on their organization's invoiced account without giving them BillingAccount Administrator rights.
A project needs to have billing enabled to ensure that APIs beyond the defaultcan be enabled. Thus if a developer creates a project, they need to associate itwith a billing account to enable the APIs.
| Role: | Billing Account User | The Billing Account User role enables the developers to attach the billing account to new projects within the organization. |
|---|---|---|
| Resource: | Organization | |
| Principals: | Developers |
The allow policy for this scenario needs to be attached at the organizationlevel, and it will look similar to the following:
{ "bindings": [ { "role": "roles/billing.user", "members": [ "group:developers@example.com" ] } ], "etag": "BwUjMhCsNvY=", "version": 1}Cost aggregation
In this scenario, a company wants to calculate and keep track of how much eachteam, department, service, or project is costing them. For example, keep trackof 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 projectIDs are included in billing export.
- Annotate projects with labels that represent additional groupinginformation. For example,
environment=test. Labels are included in billingexport to allow you to slice and dice further. However, labels on a projectare permissioned the same way as the rest of the project's metadata whichmeans a project owner can change labels. You can educate your employees aboutwhat not to change and then monitor (through audit logs), or grant them onlygranular permissions so they can't change project metadata.
You can export to JSON and CSV, but exporting directly to BigQuery is thesolution we recommend. This is easily configurable from the billing exportsection of the billing console.
If each cost center must pay a separate invoice or pay in a separatecurrency for some workloads, then a separate billing account for each costcenter is required. However this approach would require an affiliate agreementsigned for each billing account.
