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.