Can I block a specific permission on the AWS/Admin role?

Yes! Turbot allows administrators to modify, add, or remove permissions from pre-defined Turbot roles.

For example, let's assume that we want to configure the permissions S3:PutObject and S3:CreateBucket to be assigned only to AWS/Admin, rather than the default of AWS/Operator.

Set the policy AWS > Turbot > Permissions > Levels > Modifiers at the account level with the following value:

- "s3:PutObject": Admin
- "S3:CreateBucket": Admin

Once the policy has been created, Turbot will automatically update both the AWS/Admin and AWS/Operator role!

Head over to the AWS Permissions page for more information regarding Turbot and AWS permissions.

Does Turbot support automated scheduling (start/stop) for RDS DB instances?

Yes, Turbot provides a simple and flexible mechanism for starting and stopping DB instances on a pre-defined schedule. Please refer to the Schedule Guardrail for more information.

How do I remove an event / service from AWS > Turbot > Event Handlers?

Event handlers are configured per region. What we're going to walk through is removing the EC2 event from the Turbot event handlers in a single region of an account. However, like any policy setting, you could chose to set this higher in the hierarchy depending on your use case (i.e. to disable event handling for EC2 in ap-south-1 for all Turbot managed accounts, this would be set at the Turbot level or folder level that contains all managed accounts).

First, let's find the control AWS > Turbot > Event Handlers:

  1. Log into the Turbot console and navigate to the level at which we want to set the policy. In this example, we will set this policy at the ap-south-1 region level in the account aab. The header should show Turbot > example-folder > aab > ap-south-1 at the top of the window when the resource is selected.
  2. Select the controls tab then search for Event Handlers. Select the control in the list titled AWS > Turbot > Event Handlers.

We have now navigated to the control that creates and monitors the event handlers for the ap-south-1 region. Now, let's see the source that determines what the event handlers are comprised of:

  1. Select the Policies tab, then select the Event Handlers > Source option. This policy is a list of all cloudwatch event rules created to monitor services.
  2. Click the Value button. This navigates directly to the AWS > Turbot > Event Handlers > Source policy.

This is the compiled source that tells Turbot how to build the event handlers via Terraform. Now let's find our what is used to compile the source:

  1. Again, click on the Depends On tab.
  2. Find the policy on the right side titled AWS > Turbot > Event Handlers > Events > Rules > Event Sources. Clicking that will bring up said policy's value. Notice that we are viewing a policy value set at the ap-south-1 region in the account aab.

Note: Depending on the mod, the events might be under Custom Event Patterns and from there another dependent policy for that service / mod.

The Event Sources policy is a compiled list of all services defined in the specific mod. In this example, we want to remove aws.ec2 from generating events. This means we need to modify the Event Sources policy relating to the @turbot/aws-ec2 mod.

  1. When viewing the AWS > Turbot > Event Handlers > Events > Rules > Event Sources policy at the region level, click on the Depends On tab. This will show a list of policies on the right with mod names. Find the policy for the @turbot/aws-ec2 mod, AWS > Turbot > Event Handlers > Events > Rules > Event Sources > @turbot/aws-ec2, and select it.
  2. Click the Create Setting button to bring up the Create Policy Setting screen.
  3. Copy the default value on the right side. This is a YAML array.
  4. Paste the array into the Setting text field. Remove the - aws.ec2 line.
  5. Click Create.

You can then verify that the EC2 event handlers were removed by checking the AWS > Turbot > Event Handlers > Events > Rules > Event Sources policy at the region level within the account aab. aws.ec2 should no longer be in the list, and the CloudWatch rule feeding Turbot EC2 notifications will be deleted.

Can I enable access logging on Turbot logging buckets?

Administrators can set AWS > S3 > Bucket > Access Logging policies to enforce access logging on S3 buckets, but Turbot created logging buckets are exempt from this policy. Turbot logging bucket access logging is configured via the policy AWS > Turbot > Logging > Bucket > Access Logging.

Information regarding Access Logging in AWS can be found on their documentation page.

Configure Turbot Bucket Access Logging Policies

  1. First, the AWS account must have an available access logging bucket in the same region as the Turbot logging bucket. Configure the policy AWS > Turbot > Logging > Bucket > Access Logging > Bucket to have the target bucket's name. For example, if I wanted to use turbot-access-logging-1234 as my logging bucket, I would simply enter that name as the policy value. It is generally advised to set this policy at the AWS account level.
  2. We now want to configure the logging prefix using the policy AWS > Turbot > Logging > Bucket > Access Logging > Bucket. The prefix makes it simpler for you to locate the log objects. For example, if you specify the prefix value logs/, each log object that Amazon S3 creates begins with the logs/ prefix in its key. While not specific to Turbot logging buckets, this guide has more information about how to use logging prefixes.
  3. So far we have defined a bucket that will retain access logs and set a prefix for the logs themselves. Lastly, we will need to turn on Access Logging for Turbot Logging buckets. This can be accomplished using the policy AWS > Turbot > Logging > Bucket > Access Logging. Simply set this to Enforce, create the policy, and Turbot Logging Buckets will have access logging configured in no time!

How can I find an AWS account in Turbot?

This method can also be used to find any cloud resource under Turbot management.

  1. After logging into the console, click on the Search tab at the top right. This is indicated with a magnifying glass icon.
  2. Type or paste the account, project, or subscription id into the search box and hit enter.

This will return the account along with associated resources, policy settings, and controls. Using filters, you can be specific in the request for one specific account:

resourceType:account resourceId:arn:aws:::688720832111

and you can include multiple of the same resource type in a single search:

resourceType:account resourceId:arn:aws:::688720832111,arn:aws:::181849339111

Selecting the account resource will take you to the Detail page. From here, you can find information on policy settings, control states, explore child resources, or view the developer tools.

Determine which IAM policies are blocking actions

IAM policies and permissions are often spread out and not obvious. With the prevalence of NotDeny Action, Deny Not Action, and boundary policies in AWS, it is becoming increasingly difficult to pinpoint exactly what is blocking the permission invocation.

This brings us to the AWS IAM Policy Simulator. This is an invaluable tool when investigating permission issues.

Refer to this AWS document outlining how to test IAM policies using the IAM policy simulator.

This leads to an interesting caveat. If you have configured the environment to restrict permissions outside of specific regions, one of those regions MUST BE DEFINED UNDER THE GLOBAL SETTINGS! Failure to do so can and will provide inaccurate information. For example, if the environment is configured to restrict all actions outside of US East 1, failing to input us-east-1 into the Global Settings can cause the simulator to falsely direct the root of the problem to lockdown policies. However, after inputting the correct region, the simulator correctly points to the boundary policies.

Help! Turbot is blocking AWS service usage!

Many AWS services leverage other services, and as such when doing resource creation or modification, actions can be blocked. This is common with services that must create, say, and S3 bucket for logging.

Use the AWS IAM Policy Simulator to determine the action that is being denied. Most often, the denial will be implicit, where the action is denied due to not being specified in any policy. Sometimes the permission will be explicitly denied. If that is the case, reach out to your Turbot administrator as explicit denials are often intentional.

Turbot leverages both lockdown policies (AWS IAM policy resource) and permission boundaries. Luckily, with Turbot we can enable or disable entire sets of service permissions with just a few clicks.

Assuming the denial is implicit, we simply need to verify that Turbot has policies set correctly to add the service permission set.

  • To enable/ disable services via AWS Boundary Policies, check AWS > {service} > API Enabled
  • To enable/ disable services via Turbot Lockdown Policies, check AWS > {service} > Enabled

More information regarding Turbot lockdown and boundary policies can be found on our AWS Permissions page.

What does the AWS > EC2 > Load Balancer Listener policy relate to?

Turbot has two sets of EC2 Load Balancer Listener policies:

The first, AWS > EC2 > Classic Load Balancer Listener, relates to Classic Load Balancers (no surprise there!). The second policy set, AWS > EC2 > Load Balancer Listener, targets both Application Load Balancers and Network Load Balancers. There also exists a Gateway Load Balancer. However, due to restrictions with respect to modifying its attributes, Turbot has policy sets to approve the listener itself, but cannot take action with respect to the Gateway Load Balancer Listener.

Find more information about all the above policies on the aws-ec2 mods page.