---
title: "Managing Britive profiles for GCP"
slug: "managing-britive-profiles-for-gcp"
updated: 2026-04-16T05:16:01Z
published: 2026-04-29T10:51:57Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.britive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Britive profiles for GCP

When you have onboarded the required GCP application, you can create user profiles in Britive that correspond to the groups or roles in GCP. Next, you can check out or check in Britive profiles from the onboarded GCP application using Britive.

When you create a Britive profile in the onboarded GCP application, then within the profile, you can only add the groups and roles as permissions from GCP. If you have configured Console Access and when you (the user) check out a GCP profile, Britive assigns that role to the user account in GCP. If you have configured Programmatic Access and when you check out a GCP profile, Britive creates a service account and assigns that role to the service account.

Note

GCP enforces the policy on assigning or revoking the role membership, and the enforcement may take a few minutes to reflect the access.

## Project ID for Creating Service Accounts

If the Programmatic Access is configured on the application, and when the user checks out a GCP profile, Britive creates a service account and grants access to the service account. An optional field is available on the profile setting to specify where the temporary service accounts (CLI credentials) need to be created. Britive uses the project ID value set on the application by default in case the value is not specified on the profile. The project ID value set on the profile setting overrides the application level setting. The credentials used for the application must have access to the specified project. Britive validates the project ID value on saving the setting.

To set the Project ID for creating service accounts:

1. Log in to Britive with administrator privileges.
2. Click on **System admin** -> **Tenant Applications**.
3. Click on the GCP application and select **Profiles** from the navigation menu.
4. Click on **Manage**for a particular profile.
5. Click **Edit**and uncheck **Use App Default Project ID** to enter the **Project ID for creating Service Accounts**in the **Additional Settings** section. Check **Use App Default Project ID** to use the Project ID value set at the application level (default) for creating the service accounts.
6. Click **Save**.

## Assigning granular access to GCP Roles

GCP provides the capability to limit the access of the roles to specific services, resource types, or resources etc. A Britive profile can be configured to grant the role access accordingly. Britive uses the GCP capabilities to grant the roles and limit access.

### Assigning granular access using the IAM condition

GCP limits the access of the roles using the IAM conditions. For more information about the overview and details of the IAM conditions in GCP, see the following GCP documentation links:

- [Overview of IAM Conditions](https://cloud.google.com/iam/docs/conditions-overview)
- [Attribute reference for IAM Conditions](https://cloud.google.com/iam/docs/conditions-attribute-reference)
- [Resource attributes for IAM Conditions](https://cloud.google.com/iam/docs/conditions-resource-attributes)

You can define the IAM conditions for the roles in the Britive profile. Britive grants the role membership to the user along with the associated IAM condition during profile check-out. As a result of this, the user gets the required access at GCP. The checking-in of the profile reverts the user access.

Note:

Legacy basic roles (Owner, Editor, Viewer) are not allowed to have IAM conditions.

To add the profile permissions with IAM conditions using Common Expression Language (CEL), see [Granting granular access in Britive profiles](/v1/docs/managing-britive-profiles-for-gcp#granting-granular-access-in-britive-profiles).

### Assigning granular access without an IAM condition

The use of BigQuery and Apigee resources described below is no longer necessary to enforce access limits on roles for these services, as both now support IAM conditions to restrict resource access. The information below is maintained for backward compatibility, but it is recommended to discontinue using this feature as it will eventually be deprecated.

The IAM condition can be used to limit the resource-level access for specific services and resource types only. For more information about the list of supported services and resource types, see [Resource types that accept conditional role bindings](https://cloud.google.com/iam/docs/conditions-overview#resources).

GCP provides an alternate way for limiting the role access at the resource level for such non-supported resource types. The approach for limiting access varies according to the service and resource type.

Britive supports limiting access for BigQuery roles at a dataset and table level and Apigee roles at the environment level. The constraints can be defined for the roles if it has the associated permissions.

#### Prerequisites

It is required to add the additional GCP permissions to the Britive integration role to support these constraints.

- For BigQuery dataset and table constraints:
  - bigquery.datasets.get
  - bigquery.datasets.update
  - bigquery.tables.get
  - bigquery.tables.getIamPolicy
  - bigquery.tables.setIamPolicy
- For Apigee environment constraints:
  - apigee.environments.get
  - apigee.environments.getIamPolicy
  - apigee.environments.setIamPolicy

For more information about adding other required permissions and creating the service accounts on GCP, see:

- [Creating a Custom Role for GCP Organization Application](https://docs.britive.com/docs/custom-role-in-gcp)
- [Creating a Custom Role for GCP Standalone Application](https://docs.britive.com/docs/creating-a-custom-role-for-gcp-standalone-application )

For adding the profile permissions with BigQuery constraints, see [Granting granular access in Britive profiles](/v1/docs/managing-britive-profiles-for-gcp#granting-granular-access-in-britive-profiles).

### Granting granular access in Britive profiles

1. Log in to Britive with administrator privileges.
2. Click on **System admin** -> **Tenant Applications**.
3. Search the GCP application and click **Manage** from the **Tenant Applications** page.
4. Click on **Profiles** from the menu.
5. Select the profile, click **Manage,** and click the **Permissions** tab.
6. Click the **Select Permission**button and add the required permissions.
7. Click on **Manage** to fine-tune the permissions. The **Manage** button is available for the role type of the permissions.
8. The **Permission Constraints**page is displayed. This page varies as per the selected permission, and you can edit the existing constraints.
  - **Adding the condition type of constraint.**For example, Storage Admin:
    1. Enter the **Condition Title** and **Description**.
    2. Paste the condition expression in the **Condition Editor**. It is recommended to craft the IAM condition on the GCP console using the condition builder or editor. Also, test this condition by assigning the role and ensuring that it grants the required access to the user. After that, you can copy the text from “CONDITION EDITOR” from the GCP console and put it in the Britive profile condition editor.
    3. Click **Run Linter**to verify the expression. Britive uses the GCP API to lint the condition and allows to add it only in case the lint result passes without any error. The lint operation checks the syntax and other basic validations only. It does not validate the applicability of the condition, such as the existence of the resource.

For an example of adding a condition type of constraint to a role such as Storage Admin, see the [Example of adding a condition type constraint](/v1/docs/managing-britive-profiles-for-gcp#example-of-adding-cel-type-of-constraint).
  - **Adding a non-condition type of constraint.**The supported constraint types are listed based on the permissions.****
    - The project value used in the constraint must be part of the profile associations. Britive validates the presence of the resource in the associated projects and allows it to be added only in case it is present.

Checking out a profile with a role having the non-condition type of constraint grants the role membership to a user at the resource level in GCP. The user gets the required permissions on the resource, but GCP does not grant any privileges outside of the resource, such as listing the resources, listing or selecting a project, etc. If it is required to grant any permissions outside of the resource along with the resource-level permissions, then add the role in the profile without any constraints along with the role with constraints. It is recommended to identify the roles for adding to the profile by assigning the roles in GCP and ensuring that it grants the required access to the user. For an example of adding a non-condition type of constraint such as a BigQuery constraint, see the [Example of adding a non-condition constraint](/v1/docs/managing-britive-profiles-for-gcp#example-of-adding-noncel-type-constraint).
      - Enter the BigQuery dataset and/or BigQuery table name: The format for adding the table and dataset constraint is consistent with the GCP resource ID value for the BigQuery dataset and table. It is recommended to copy the resource ID value from the GCP console and use it for adding the constraint. The format is as shown here:
        - *Table*: *<project_id>.<dataset_name>.<table_name>*
        - *Dataset: <project_id>.<dataset_name>*
      - Enter the Apigee environment: The environment value needs to be added in the following format: *<project_id>.<environment_name>*
9. Click **Add** to add this constraint.

Note

It is recommended not to use the condition and non-condition-supported constraints for the same role even though some role supports both types of constraints.

### Example of adding a condition type of constraint

Here is an example of the sample condition that can be used with Cloud Storage Admin. This condition grants the user to list all the buckets and do the administrative activities for the buckets whose name starts with example-bucket. For more information about this sample condition, see [resource.name attribute](https://cloud.google.com/iam/docs/conditions-attribute-reference#resource-name).

```Samplecondition
(resource.type != 'storage.googleapis.com/Bucket' && resource.type != 'storage.googleapis.com/Object') || resource.name.startsWith('projects/_/buckets/example-bucket')
```

### Example of adding a non-condition type constraint

Here is an example of using the BigQuery constraints. The profile needs to be configured with the below roles to grant read-only access to all the tables in the specific dataset along with permission to execute the SQL queries. For more information about access the user gets on assigning BigQuery roles at a different level, see [BigQuery predefined IAM roles](https://cloud.google.com/bigquery/docs/access-control#bigquery).

- *BigQuery Data Viewer* with adding the dataset constraint
- *BigQuery Job User* without having any constraint

The *BigQuery Data Viewer* role with adding the dataset constraint grants the user read-only access to the specified dataset. The role *BigQuery Job User* has the permissions as *resourcemanager.projects.get* and *bigquery.jobs.create* etc. This allows the user to select a project on the GCP cloud console and execute the read-only SQL queries on the specified datasets.

You can create a custom role as per your requirements and add it to the profile accordingly. As an example, if the user only needs permission to select the project and view the datasets but doesn't need permission to execute the SQL queries then create a custom role at the project level in GCP with permission *resourcemanager.projects.get*. This custom role should be added to the profile without having any constraints instead of the *BigQuery Job User* role.