Managing Azure Permissions

Turbot provides a rich set of capabilities for managing authentication of users, as well as authorization to Azure services and resources. Turbot integrates with Azure Role-Based Access Control to provide a simple but flexible model for managing access to your Azure subscriptions using Azure Custom 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 Azure permissions

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

To set this policy via Terraform:

resource "turbot_policy_setting" "azure_permissions" {
resource = "id of subscription or parent folder or smart folder" //highlight-line
type = "tmod:@turbot/azure-iam#/policy/types/permissions"
value = "Enforce: Role Mode"
}

Standard Levels

The Permissions > Levels policies configure which standard Turbot roles 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 don't apply. Example use cases:

  • My organization does not use the Azure/User, so I don't want it to be grantable in the UI
  • My organization only assigns access using the subscription level permissions (Azure/Admin, Azure/Operator, etc), and I don't want the overhead of creating and managing all of the service-specific options (Azure/Compute/Admin, Azure/Compute/Operator, Azure/Storage/ReadOnly, etc)

Standard permission levels are:

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

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

Permission level policies for each service are disabled by default, but can be configured in Azure > {service} > Permissions > Levels.

  • Azure > Storage > Permissions > Levels
  • Azure > Compute > Permissions > Levels

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

Note that permissions levels will not be created if no permissions are actually effective at that level, even if they are enabled by the Permissions > Levels policies. For example, if you enable permissions with all levels enabled (the default configuration), but no services are enabled, only the Azure/SuperUser is created - No other levels have any permissions defined, thus they will not be created. Enabling a service, (Azure > Storage > Enabled, for example) will result in creation of additional levels (Azure/Admin, Azure/Operator, Azure/ReadOnly, etc) which will then be grantable.

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 custom role definitions.

You can use Modifiers to:

  • Change what permissions levels a specific api is assigned to
  • Remove access at a given permissions level
  • Add access to APIs that are not defined by Turbot

Modifier example use-cases include:

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

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

Modifiers can add, remove, and change permissions for any Azure 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

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 provider levels and per-service levels

  • Modifier policies at the provider level (Azure/Admin, etc) apply ONLY at the Azure level
  • Modifier policies at the service level will “roll up” to the provider level too -- for example if you add microsoft.sql/locations/longtermretentionbackups/read to Azure/SQL/Operator, it will be assigned to Azure/Operator as well

To set a subscription-level Modifier, edit the Azure > Turbot > Permissions > Levels > Modifiers policy.

For a service-level modifier, edit the Azure > {service} > Permissions > Levels > Modifiers policy (for example, Azure > Storage > Permissions > Levels > Modifiers).

These policies should contain an array of permission: level assignments. For example:

- "microsoft.sql/locations/longtermretentionbackups/read": "operator"
- "microsoft.sql/locations/longtermretentionbackups/write": "operator"

Alternatively, you can set the policy with Terraform:

resource "turbot_policy_setting" "azure_permissions_modifiers" {
resource = "id of subscription or parent folder or smart folder" //highlight-line
type = "tmod:@turbot/azure-iam#/policy/types/permissionsLevelsModifiers"
value = jsonencode([
{"microsoft.sql/locations/longtermretentionbackups/read": "operator"},
{"microsoft.sql/locations/longtermretentionbackups/write": "operator"}
])
}
If multiple service-level polices assign an operation to different levels, the operation will be assigned at the lower permission level in the provider permissions. For example, if microsoft.network/networkwatchers/read is assigned to Azure/Network/Operator and also Azure/NetworkWatcher/User then it will be assigned to Azure/User
If an operation is set to None in a service-level modifier, but another service has the operation defined at that level, it will NOT be removed at the Azure level. For example, if microsoft.network/networkwatchers/delete is assigned to None in the Azure/Network/Admin level, Azure/Admin will still have microsoft.network/networkwatchers/delete because it is allowed for Azure/NetworkWatcher/Admin

Custom Levels

Custom Levels provide another mechanism to provide flexibility in managing Azure permissions. Whereas Modifiers 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, and I would like to grant permissions with them from Turbot
  • I want to manage access to my subscription with custom roles that I define, but make them grantable to my users in Turbot.

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

Custom levels can be specified via the Azure > Turbot > Permissions > Custom Levels policy.

- "My Custom Role"
- "My Other Custom Role"

Alternatively, you can set the policy with Terraform:

resource "turbot_policy_setting" "azure_permissions_custom_levels" {
resource = "id of subscription or parent folder or smart folder" //highlight-line
type = "tmod:@turbot/azure-iam#/policy/types/permissionsCustomLevelsSubscription"
value = jsonencode([
"My Custom Role",
"My Other Custom Role"
])
}