Turbot FAQ



What is Turbot?

Turbot is a full-stack governance platform. Our software automates discovery and remediation of your organization’s compliance, security, and operational objectives.

Discover everything, remediate anything!

What public cloud providers does Turbot support?

Turbot has support for AWS, Azure, and Google Cloud, as well as Operating Systems (and Kubernetes coming soon!).

If Turbot does not currently support your platform, it can! Turbot's extensible platform allows you to build your own mods with the Turbot CLI!

How is Turbot deployed?

You can host Turbot as a single tenant platform within your own VPC or Turbot can host it for you (single tenant or multi-tenant) as a managed service.

Where can I find the latest information about mods?

Our Mods page has a full list of mods published by Turbot. Searching the list is as easy as typing in the service name and pressing enter! Clicking the mod will render the mod information page, which can include a README (some are self explanatory, i.e. AWS-Amplify), an inspect tab, dependencies, and a version history.

The inspect tab contains all of the defined resource types, policy types, and control types, as well as the schema definitions. Expanding any of the links provides more details.

The dependency tab shows which other mods must be installed, and their versions, prior to installing the selected mod.

The versions tab shows the change history for the selected mod.

While some mods are static, others can change with updates and features, so be sure to keep an eye out for new mod versions!

What are the benefits of upgrading workspace versions?

Benefits for the account owners:

  • Less turbot API calls in their account
  • subscribable notifications
  • Support for more AWS services
  • Searchable CMDB
  • See detailed configuration change over time

Benefits for the cloud team:

  • Lower cost to run turbot
  • Real-time dashboard
  • Modular (only install what you are using)
  • Extensible, via calculated policies/custom mods
  • Configuration as code... use terraform to configure Turbot
  • Easier API for reporting and data extraction
  • Change control: see who changed what in turbot without looking through audit logs

What is needed to configure Turbot Firehose?

Install firehose-aws-sns mod on your workspace and a service user for the email. Refer to the Turbot Firehose guide for more information.

Is there a way to create a Turbot File in the console?

Yes. Go to the folder where you want to create the file and click New. Select resource type as File, enter the details, and click Create. Head over to our Turbot Files guide for more information.

Can I use Active Directory or SAML groups to assign permissions rather than assigning permissions to individual users?

We do support the use of Active Directory and SAML groups to assign permissions. Keep in mind that SAML groups do not sync automatically - the groups are created when a user who is in said group logs in for the first time. Users in that group who log in after the initial group creation will be automatically assigned to that group. Check out our Directories guide for more information.

Does V5 allow the ability to monitor and alert on who is using AWS services?

Yes! This is a feature of the Turbot Firehose mod. Watches can be configured to notify based on defined criteria, such as admin and user activity. The inspect tab on the mod page has additional information, as does our Turbot Firehose guide page.

Does the Turbot/Operator role have Create, Read, Update and Delete permissions for Files?

The Turbot/Operator role has the ability to read Files, but can not create, update, or delete them. This is using the default turbot/operator permission.

How do I change a local directory user password?

  • Login as a Turbot/Owner.
  • Click on Permissions tab in the header.
  • Click on DIRECTORIES card.
  • Click on the local directory that contains the user and then the Users tab.
  • Click Reset Password option for the desired user, which is a key icon. A new password will be displayed that can be used immediately.

Check out our IAM guide for more information.

Is there a way to generate an API key for a different Turbot user profile other than my own?

This is not currently possible from the security point of view. Hence it is limited to the user profile itself only.

Based in cyber security best practices, this is not possible in Turbot. Users can only generate access keys for themselves. If a service user needs a new access key, an administrator must log into the Turbot console with the service role to delete the old key and create a new one.

How can I check control states for resources that have been deleted?

Using the Activity Ledger report in Apollo, you can check control states for resources that have been deleted. Click the Reports tab, then click Activity Ledger in the Activity section. Once the list loads, click the Type drop down menu on the right and select Control. This gives a history of all controls for existing and past resources. Using filters, users can curate the data for the desired information.

report

activities

Check out our Searching and Filtering guide for more helpful tips, tricks, and information.

Can I use cli/graphql command to get the list of current users and their associated grants?

  1. By using below GraphQL, you can get the list of users and their permissions. Change the resourceId in the below query according to the resource level where you want to see the list.
{
  listUsers: resources(filter: "resourceTypeId:tmod:@turbot/turbot-iam#/resource/types/profile limit:5000") {
    metadata {
      stats {
        total
      }
    }
  }
  activeGrantToUser: activeGrantList(filter: "resourceId:173249879813121 level:self,descendant permissionTypeLevel:self,descendant limit:5000") {
    metadata {
      stats {
        total
      }
    }
    items {
      grant {
        identity {
          profileId: get(path: "profileId")
        }
        type {
          uri
        }
        level {
          uri
        }
      }
    }
  }
}

Check out our 7-minutes-labs-GraphQL for more helpful tips and tricks.

  1. By using Turbot CLI, you can get the list of users and their permissions. You can save the above query as a .txt file in your local drive and pass the file path. Example to run Turbot CLI for the above query is: turbot graphql --query /Users/ABC/graphql/listuserwithgrant.txt. Please refer to Turbot CLI for installation and commands.

Can I generate AWS Access Keys programmatically?

Yes! This can be accomplished by a GraphQL query or Turbot CLI aws command.

GraphQL Query: Passing in consoleLoginUrl and AwsCredentials information, Turbot will respond with an access and secret access key. This can be done via a preferred scripting language - you can find additional scripting examples on our Turbot TDK.

Refer to AWS IAM documentation for instructions on using the temporary access keys.

# Console Login Example for Custom Role "example_role" to login to the "123456789012" AWS Account
{
  aws {
    consoleLoginUrl(account:"arn:aws:::123456789012", permissionType: "tmod:@turbot/aws#/permission/types/aws", permissionLevel: "tmod:@turbot/turbot-iam#/permission/levels/role", role: "example_role")
    credentials(account: "arn:aws:::123456789012", permissionType: "tmod:@turbot/aws#/permission/types/aws", permissionLevel: "tmod:@turbot/turbot-iam#/permission/levels/role", role: "example_role") {
      sessionToken
      expiration
      accessKeyId
      secretAccessKey
    }
  }
}

Turbot CLI: Start by ensuring the Turbot CLI is configured. Once that is done, we can run the aws command to generate temporary AWS credentials and save them to the AWS credentials file.

turbot aws credentials --account 123456789012 --level superuser

Note that in both of these cases we are generating credentials to assume into the account using the Superuser role. The permissionLevel attribute in the GraphQL command and level flag with the CLI are used to designate the permission level.

How does Turbot protect my AWS account from the confused Deputy problem?

By default, Turbot suggests an External ID to be used for your AWS Account import. The generated ID is in a protected format, turbot:{TurbotWorkspaceResourceId}{UserDefinedName}; e.g. turbot:123456789012345:foo. When using the protected format of turbot:{TurbotWorkspaceResourceId}:, Turbot will make sure the resource ID matches the Turbot Workspace the account is being imported with. If the turbot resource ID does not match, credentials will not be generated for the account to be associated to Turbot.

By default, Turbot IAM Role External ID Protection is set to Open where Turbot suggests a protected name, however the user can replace with their own external ID.

When set to Protected, the external ID must be in the protected format for credentials to be generated for the account to be associated to Turbot.

More information about the External ID Protection Policy. More information about the confused Deputy problem.

What is Turbot AWS IAM Role External ID Protection?

During an AWS Account Import, Turbot will suggest an auto-generated external ID that is unique to your Turbot Workspace (e.g. turbot:123456789012345:26c29c72-4406-44a6-ac53-bd8b6e4d1437). You can use the generated external ID for your IAM role to prevent the confused deputy problem.

The turbot:123456789012345: prefix is derived from your unique Turbot Workspace resource ID. When using this external ID format, if the IAM role is attempted to be imported to another Turbot Workspace, Turbot will validate the unique Workspace resource ID in the external ID and block the import to protect unauthorized use of the IAM Role outside of the intended Turbot Workspace.

The suffix 26c29c72-4406-44a6-ac53-bd8b6e4d1437 (This is just an example. Your real external ID will be a similar randomly generated string) is always optional in the protected format. Common use cases are to keep the generated suffix for a unique external ID per account, or a custom defined suffix for each account.

By default, the Turbot Workspace sets the following policy AWS > Account > Turbot IAM Role > External ID > Protection to Open. While the Turbot suggested external ID is generated for use, the entire value can be replaced with your own external ID instead (e.g. mySpecialExternalId123). Turbot recommends you use the generated format to protect against the confused deputy problem (see above). However, any valid formatted external ID is accepted for the import.

To enforce the use of the protected auto-generated format, the policy mentioned above can be set to Protected. Turbot will block any custom external ID values, only allowing a protected format for the prefix turbot:123456789012345:. The suffix will still be optional to use the generated value or a custom value.

Note that while AWS allows most traditional characters to be a part of the external ID, there are restrictions as to which external ID actually work for Turbot:

The external ID value that a third party uses to assume a role must have a minimum of 2 characters and a maximum of 1,224 characters. The value must be alphanumeric without white space. It can also include the following symbols: plus (+), equal (=), comma (,), period (.), at (@), colon (:), forward slash (/), and hyphen (-).

Refer to AWS documentation for more info.

What causes Turbot Event Handler policies to re-run?

Turbot event handler policies are initially calculated at the time of mod installation. However, some actions can trigger event handler policy re-calculation, and with a large amount of accounts imported and regions enabled, this can generate a significant amount of events.

Updates and actions that can cause event handler policy re-calculations:

  • Updating mods such as aws-events, aws-sns, aws-ec2, and aws-cloudwatch.
  • Updating Turbot Enterprise.
  • Modifications to AWS > Turbot > Event Handlers > Events > Rules > Event Sources > @mod-name policies.

It is recommended to wait at least 15-20 minutes in the case of a large event handler policy re-run. If errors are generated and do not clear on their own in up to 30 minutes, reach out to Turbot Support.