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.

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 Project ID for creating service accounts:

1. Login to Britive with administrator privileges.
2. Click on Admin -> Application and Access Profile Management.
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 accesses of the roles to specific services, resource types or resources, etc. A Britive profile can be configured to grant the role accesses accordingly. Britive uses the GCP capabilities to grant the roles and limit the accesses.

Assigning granular access using the IAM condition

GCP limits the accesses 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
• Attribute reference for IAM Conditions
• Resource attributes for IAM Conditions

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 accesses at GCP. The checking-in of the profile reverts the user access. Currently, it is supported to define the IAM condition for the roles having any cloud-storage-bucket and Apigee related permissions only. See the list of the supported Apigee resources here.

This feature will be enabled in the future release for the roles containing the other resource types mentioned in the above GCP links. 

For adding the profile permissions with Common Expression Language (CEL) constraints, see Granting granular access in Britive profiles.

Assigning granular access without IAM condition

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.

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 the 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
• Creating a Custom Role for GCP Standalone Application

For adding the profile permissions with BigQuery constraints, see Granting granular access in Britive profiles.

Granting granular access in Britive profiles 

1. Login to Britive with administrator privileges.
2. Click on Admin -> Application and Access Profile Management.
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. The manage button is available only for the roles which can have granular access.
6. Click the ADD PERMISSIONS button and add the required permissions.
7. Click on Manage to fine-tune the permissions. The Manage button is enabled only if the added permission supports constraint management. Britive checks the GCP permissions associated with a role to check it. Currently, it supports the roles having the permissions related to cloud storage buckets, Apigee resources, BigQuery datasets, and BigQuery tables.
8. The Permission Constraints page is displayed. This page varies as per the selected permission and you can edit the existing constraints.
   • Adding CEL 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 CEL type of constraint such as Storage Admin, see Example of adding CEL type constraint.

   • Adding a non-CEL type of constraint. The supported constraint types are listed based on the permissions. 
     • • 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>
       
       

       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-CEL 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-CEL type of constraint such as a BigQuery constraint, see Example of adding non-CEL constraint.

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.

Supported Apigee Resources

The following resource types are supported to define the IAM condition for the roles:

• apigee.proxies
• apigee.proxyrevisions
• apigee.keyvaluemaps
• apigee.apiproducts
• apigee.apiproductattributes
• apigee.developers
• apigee.developerattributes
• apigee.developerapps
• apigee.developerappattributes
• apigee.keyvaluemapentries
• apigee.rateplans
• apigee.sharedflows
• apigee.sharedflowrevisions

For more information about Britive profile management, see Britive Profile Management.

Example of adding CEL 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.

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

Example of adding non-CEL 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.

• 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.