Managing AWS Permissions

Turbot provides a rich set of capabilities for managing authentication of users, as well as authorization to AWS services and resources. Turbot integrates with AWS IAM Identity and Access Management to provide a simple but flexible model for managing access to your AWS accounts using native AWS 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 AWS permissions

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

To set this policy via Terraform:

resource "turbot_policy_setting" "aws_permissions" {
  resource        = "id of account or parent folder or smart folder"  type            = "tmod:@turbot/aws-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 AWS Permissions can be turned off. This allows you to use the other Turbot controls but manage AWS Authentication and Authorization entirely on your own. Note that if you set permissions mode to None, no lockdown or boundary policies will be created.
  • Policy-Only Mode: Policy-Only mode allows you to build your own roles but leverage Turbot policies in them. This is mostly an un-managed permissions mode - Theres is no ability to assign permissions in the Turbot UI at all. Policy-Only mode is the minimum required mode to use lockdown policies.
  • Role Mode: Role Mode provides a full set of AWS permissions management capabilities using IAM roles. Turbot will create roles and policie in each account to manage permissions. You can assign permissions to Turbot users, and Turbot will issue login credentials to the user to log in to AWS using the role(s) assigned to them.

Permission Mode Summary

Mode Permissions UI AWS Login through Turbot Managed Roles Managed Policies
None
Policy-Only x
Role Mode x x x x

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 AWS/User, so I don't want it to appear in the UI
  • My Organization only assigns access using the AWS/* permissions, and I dont want the overhead of creating and managing all of the service-specific options (AWS/S3/, AWS/RDS/, etc)

Standard permission levels are:

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

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

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

  • AWS > S3 > Permissions > Levels
  • AWS > EC2 > Permissions > Levels

You can use the AWS > 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 permissions levels a specific API path is assigned
  • Remove access at a given 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 S3 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 EC2 Operators that Turbot normally reserves for Admins
  • Turbot assigns an AWS permission to to EC2/Operator that I consider privileged - I want to reassign that permission to EC2 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 AWS 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 AWS levels and per-service levels

  • Modifier policies at the provider level (AWS/Admin, etc) apply ONLY at the AWS level
  • Modifier policies at the service level will “roll up” to the provider level too -- for example if you add glacier:CreateVault to S3/Operator, it will be assigned to AWS/Operator as well

    • 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 S3:CreateBucket is assigned to S3/Operator, and also ElasticBeanstalk/User, then it will be assigned to AWS/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 AWS level. For example, if S3:CreateBucket is assigned to None in the ElasticBeanstalk/Admin level, AWS/Admin will still have S3:CreateBucket because it is allowed for S3/Admin

To set an account-level Modifier, edit the AWS > Turbot > Permissions > Levels > Modifiers policy.

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

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

- "ec2:DescribeInstance": "admin"
- "s3:PutObject": "admin"

Alternatively, you can set the policy with Terraform:

resource "turbot_policy_setting" "aws_permissions_modifiers" {
  resource        = "id of account or parent folder or smart folder"  type            = "tmod:@turbot/aws-iam#/policy/types/permissionsLevelsModifiers"
  value           =  jsonencode([
                        {"s3:PutObject": "admin"},
                        {"ec2:DescribeInstance": "admin"}
                  ])
}
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 ec2:DescribeInstance is assigned to AWS/EC2/Operator and also EAWS/EC2/User then it will be assigned to AWS/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 AWS level.

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 AWS 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

    • AWS > S3 > Permissions > Levels > ACL Administration
    • AWS > S3 > Permissions > Levels > Access Logging Administration

Custom Levels

Custom Levels provide another mechanism to provide flexibility in managing AWS 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 account at the sub-account level with custom roles
  • I don’t want to use Turbot for authorization at all; I will manage AWS/Azure/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 AWS. The custom roles will appear in the UI in the account as “grantable” to a user. They are named {Provider}/Role/{RoleName}, for example AWS/Role/MyCustomRole

Custom levels can be specified via the AWS > Turbot > Permissions > Custom Levels [Account] policies.

Lockdown and Boundary Policies

Turbot uses IAM policies to enforce restrictions on Turbot-managed users and roles (AWS/Admin, AWS/Owner, AWS/EC2/Admin, etc.) as well as customer-managed users and roles (the users and roles you create outside of Turbot).

Lockdown and boundary policies are commonly used to implement Turbot polices for enabling/disabling services, regions, instance types, etc., as well as to protect Turbot resources from modification outside of Turbot.

For lockdown and boundary policies to be in effect:

  • You must have the aws-iam mod installed
  • You must enable the IAM service (AWS > IAM > Enabled)
  • You must enable AWS permissions in policy-only mode, role mode or user mode.

Key Differences

Turbot allows you to enforce a hard boundary to enable and disable services and regions.

  • Turbot creates and applies an AWS Boundary Policy to enforce hard boundaries.
  • Hard boundaries include only service-level API whitelist and region whitelist policies.
  • Boundary policies are always applied to Turbot-managed roles and users created in the permissions stack - you cannot disable them.
  • The hard boundary is set to skip by default for customer-managed users and roles (Note that this behavior was changed in aws-iam 5.4.1 - prior versions enforced the boundary by default). To enforce the Turbot boundary policy for users and roles that are not created by Turbot, you must explicitly enforce the AWS > IAM > Role > Boundary and AWS > IAM > User > Boundary policies.
  • Hard boundaries can apply to ALL users and roles - customer-managed and Turbot-managed, including SuperUser and the Turbot Service Role
  • If a region or service is not enabled in the boundary, there will be no access at all, even for Turbot or Superuser.

    • You may want to set AWS > IAM > Role > Boundary to Skip for the service account that Turbot uses to connect to your account.
    • If you do not want to apply the boundary to Superusers, you can set the AWS > Turbot > Permissions > Superuser Boundary policy to No boundary.
  • Services disabled in the hard boundary are disabled entirely - there are no exceptions for specific APIs within the service.

Turbot also defines soft restrictions on services and regions, as well as specific instance types and API operations.

  • Turbot creates and applies Lockdown Policies to implement these soft restrictions. Lockdown policies are implemented as IAM Managed Policies that contain "deny" statements.
  • Turbot can attach lockdown policies on all users and roles except the Turbot service role and Superuser.
  • In addition to Enabled and Disabled, services may be enabled for Metadata only in the lockdown policies.
  • Lockdown policies are more granular than boundary policies, and are used to implement additional Turbot features, such as budget or instance type restrictions.
  • By default, lockdown policies are applied to Turbot-managed users and roles, but not customer-managed users and roles. To enforce lockdown policies on customer-managed users and roles:

    • Set AWS > IAM > Role > Policy Attachments > Required and AWS > IAM > User > Policy Attachments > Required to Enforce
    • Set AWS > IAM > Role > Policy Attachments > Required > Turbot Lockdown and AWS > IAM > User > Policy Attachments > Required > Turbot Lockdown to Enabled

Turbot Polices for Configuring Boundary and Lockdown Policies

Purpose Hard Boundary Policies Soft Lockdown Policies
Enable/Disable Regions AWS > Turbot > Permissions > Lockdown > Region Boundary AWS > Turbot > Permissions > Lockdown > Regions
Enable/Disable Services AWS > {service} > API Enabled AWS > {service} > Enabled
Enforce Attaching Policy AWS > IAM > Role > Boundary
AWS > IAM > Role > Boundary > Policy
AWS > IAM > User > Boundary
AWS > IAM > User > Boundary > Policy
AWS > IAM > Role > Policy Attachments > Required
AWS > IAM > Role > Policy Attachments > Required > Turbot Lockdown
AWS > IAM > User > Policy Attachments > Required
AWS > IAM > User > Policy Attachments > Required > Turbot Lockdown

Scenarios

The following scenarios assume that you have installed the aws-iam mod, enabled the iam service, and enforced AWS > Turbot > Permissions in policy-only mode or higher, and have enforced the Boundary and Lockdown policies as explained above.

I want to allow permissions for a service that Turbot does not support, or for which I have not installed a Turbot mod
  • Add the APIs to the AWS > Turbot > Permissions > Lockdown > API Boundary policy. This will allow the API in both the boundary and lockdown policies.
I want to only enable specific regions. I do not want anyone, including Turbot to be able to use them.
  • Edit the AWS > Turbot > Permissions > Lockdown > Region Boundary policy to only include the regions you would like enabled.
I want to only enable specific regions, but allow Turbot and AWS/SuperUser to be able to access ALL regions
  • Leave the AWS > Turbot > Permissions > Lockdown > Region Boundary policy at the default ([*])
  • Edit the AWS > Turbot > Permissions > Lockdown > Regions policy to only include the regions you would like enabled.
I don't want the boundary policy to apply to the Turbot role - Turbot should be able to access all the regions and APIs.
  • Set the AWS > IAM > Role > Boundary policy on the Turbot service account role to Enforce: No Boundary
I want disable a service. I do not want anyone, including Turbot or Superuser to be able to use it.
  • Set AWS > {service} > Enabled to Disabled
  • Leave AWS > {service} > API Enabled at the default setting: Enabled if AWS > {service} > Enabled OR
  • Set AWS > {service} > API Enabled to Disabled
I want disable a service for users, but allow Turbot and Superuser to be able to use it.
  • Set AWS > {service} > Enabled to Disabled
  • Set AWS > {service} > API Enabled to Enabled
I want to enforce the lockdown policies on ALL roles
  • Set AWS > IAM > Role > Policy Attachments > Required to Enforce: Required > Items
  • Set AWS > IAM > Role > Policy Attachments > Required > Turbot Lockdown to Enabled
  • Set AWS > IAM > User > Policy Attachments > Required to Enforce: Required > Items
  • Set AWS > IAM > User > Policy Attachments > Required > Turbot Lockdown to Enabled
I want to set an exception to the boundary policy for a user so it is not applied
  • Set the AWS > IAM > User > Boundary policy on the user to Enforce: No Boundary
I want to set an exception to the lockdown policy for a user so it is not applied
  • Set AWS > IAM > User > Policy Attachments > Required > Turbot Lockdown to Disabled for the user
I want to use my own boundary policy
  • Set the AWS > IAM > User > Boundary > Policy and AWS > IAM > Role > Boundary > Policy policies to the name of your boundary policy.

    • Note that the Turbot Region Boundary and API Enabled policies will have a no effect if you do not apply Turbot's boundary policy
    • Your policy must exist - it will be be created by this policy. You can use the AWS > Account > Stack to manage this policy if you desire.