Turbot DocsGetting StartedConceptsGuidesIntegrationsAWSAzureGCPImport ProjectServicesPermissionsDecommission TurbotReal-Time EventsBest PracticesMods7-minute LabsFAQsReferenceRelease NotesTurbot.comEnterprise

Managing GCP Permissions

Turbot provides a rich set of capabilities for managing authentication of users, as well as authorization to GCP services and resources. Turbot integrates with GCP IAM Identity and Access Management to provide a simple but flexible model for managing access to your GCP projects using native GCP IAM Roles.

Permissions policies are used to customize which levels are available to assign permissions, as well as the set of operations that those levels encompass. Refer to the permissions core concepts documentation for more information.

Enabling GCP permissions

To enable full GCP permissions management through Turbot with a default configuration, set the GCP > Turbot > Permissions policy to "Enforce: Role Mode":

resource "turbot_policy_setting" "gcp_permissions" {
  resource        = "id of project or parent folder or smart folder"  type            = "tmod:@turbot/gcp-iam#/policy/types/permissions"
  value           = "Enforce: Role Mode"
}

Permissions Modes

Turbot can be configured to operate in one of 3 permissions modes:

  • None: Turbot Managed GCP Permissions can be turned off. This allows you to use the other Turbot controls but manage GCP Authentication and Authorization entirely on your own.
  • Role Mode: Role Mode provides a full set of GCP permissions management capabilities using IAM roles. Turbot will create roles and bindings in each project to manage permissions. You can assign permissions to Turbot users, and Turbot will map the users the role(s) assigned to them.

Standard Levels

The Permissions > Levels policies configure which standard Turbot roles/groups/policies will be created. Levels enabled in this policy will appear in the UI, and can be assigned to a user in the Turbot console.

This gives you a large degree of control about what rights can be granted in your organization -- You can choose to disable levels that dont apply. Example use cases:

  • My Organization does not use the GCP/User, so I don't want it to appear in the UI
  • My Organization only assigns access using the GCP/* permissions, and I dont want the overhead of creating and managing all of the service-specific options (GCP/Storage/*, GCP/Compute/*, etc)

Standard permission levels are:

  • User
  • Metadata
  • ReadOnly
  • Operator
  • Admin
  • Owner
  • SuperUser [not applicable ton individual services]

Project-level permission level policies (GCP/Admin, GCP/Metadata, etc) can be configured in GCP > Permissions > Levels. By default, all levels are enabled.

Permission level policies for each service (GCP/Storage/Admin, GCP/Storage/Metadata, etc) can be configured in GCP > {service} > Permissions > Levels.

  • GCP > Storage > Permissions > Levels
  • GCP > Compute > Permissions > Levels

You can use the GCP > Permissions > Levels [Default] policy to configure the default levels for all services. By default, service-level permissions are not enabled.

Modifiers

Permission Level Modifiers provide a simple mechanism to modify the standard permissions policies generated by Turbot. Modifiers work with Turbot's IAM rules engine to modify the access directly in the Turbot IAM policies.

You can use Modifiers to:

  • Change what what permissions levels a specific api path is assigned
  • Remove access at a give permissions level
  • Add access to apis that are not defined by turbot

Modifier example use-cases:

  • I want to add access to a new API in Storage that turbot hasn’t added yet
  • I want to add an entirely new service that Turbot hasn’t added yet
  • I want to add a capability for my Compute Operators that Turbot normally reserves for Admins
  • Turbot assigns an GCP permission to to Compute/Operator that I consider privileged - I want to reassign that permission to Compute Admins

Modifiers leverage the existing turbot rules engine to modify the policies that Turbot generates. They do not generate separate policies

Modifiers can add, remove, and change permissions for any GCP service to any standard permission level. Modifiers effectively redefine (override) the permission level to which an api operation is defined.

  • Permissions defined in the Modifiers policy override the Turbot defaults
  • Permissions defined in the Modifiers policy override the Turbot Capability Modifier Policies

Modifiers are cumulative in the same way that levels are - if you add a permission to the Metadata level, it is also added to ReadOnly, Operator and Admin

Modifier policies exist for both GCP levels and per-service levels

  • Modifier policies at the provider level (GCP/Admin, etc) apply ONLY at the GCP level

    • GCP > Permissions > Levels > Modifiers

  • Modifier policies at the service level will “roll up” to the provider level too -- for example if you add a permission to GCP/Storage/Operator, it will be assigned to GCP/Operator as well.

    • GCP > Storage > Permissions> Levels> Modifiers
    • GCP > Computed > Permissions> Levels> Modifiers

Capability Modifier Policies

Capability Modifier policies allow you to either restrict access to certain sets of actions to Turbot, or to allow them to admin users as appropriate. Capability modifiers are essentially Modifiers that are pre-defined by Turbot. These policies are often used to force adminstration of resources through the Turbot control plane, and disallow direct access to the underlying GCP APIs from users.

The Capability Modifier Policies are applied after the built-in permissions but before the custom Modifiers:

  • Capability Modifier Policies override Turbot's default permissions assignments

  • Custom Modifiers override Capability Modifier Policies

    • GCP > Storage > Permissions > Levels > ACL Administration`
    • GCP > Storage > Permissions > Levels > Access Logging Administration

Custom Levels

Custom Levels provide another mechanism to provide flexibility in managing GCP permissions. Whereas Modifiers and Custom Policies allow you to customize the rights granted to Turbot built-in permissions levels, Custom Levels allow you to create your own levels that you can use to assign access through the Turbot console.

Custom Level example use-cases:

  • I have existing roles that I would like to leverage instead of / in addition to using Turbot’s standard roles/groups
  • I want to manage my project at the sub-project level with custom roles
  • I don’t want to use Turbot for authorization at all; I will manage GCP users, roles, groups, and policies

The Custom Levels policy allow you to map your existing IAM roles to turbot users to provide them access to GCP. The custom roles will appear in the UI in the project as “grantable” to a user. They are named {Provider}/Role/{RoleName}, for example GCP/Role/MyCustomRole

Custom levels can be specified via the GCP > Permissions > Levels > Custom Levels [Project] policies.