Turbot Concepts

Turbot Concepts

Turbot provides enterprise guardrails for Amazon Web Services.

This document outlines the beliefs, models and assumptions Turbot has defined to create those guardrails - providing organizations with a working balance between agility and compliance. Please see other help sections for implementation specifics and how to guides.

Design Beliefs

Balancing agility with controls requires a clear and simple set of beliefs guiding our designs and trade-off decisions. This section outlines how Turbot thinks about Enterprise Controls for Cloud Infrastructure.

Cloud Infrastructure is managed dynamically by Applications & DevOps Teams.

Cloud Infrastructure is designed to be changed in real time, providing scalability and reliability in Production and flexibility in Development. Enterprises moving to Cloud Infrastructure need to give control of Application Infrastructure to the Application and its DevOps Teams.

Enterprises run many different Applications.

Each Enterprise consists of many Applications, each with a specific purpose, requirements and controls. Applications may interact, or be dependent on each other, but are managed (e.g. access, change control) as separate systems.

Applications have multiple Environments.

Multiple copies and environments of each Application are required to support Development, Quality Assurance and Production activities. These Environments should be similar, but are separate systems that require different levels of access, reliability and control.

Each Application & Application Environment is managed differently.

Production needs more control than Development. Customer data and compliance records data needs more protection than basic organization information. Critical systems need close monitoring, while small applications can fail without impact. Each Application Environment needs to be managed according to its needs, providing agility and control in the right places.

Applications are Independent, but connected.

Although Applications function separately, they are often integrated and always have some level of shared citizenship in the Enterprise Network.

Enterprises require common Controls across Applications.

The Enterprise Network shares many Application Environments, so central rules and control are required to protect the whole. So, certain Enterprise policies and requirements apply to all applications and must be centrally managed. For example, data protection, access control and network firewalls.

Cluster of Accounts

Each Organization can run one or more Turbot Clusters. A Cluster defines Access, Controls and Configuration that apply to all Accounts across the Organization. It is typically managed by a central Cloud Infrastructure DevOps team.

Each Cluster manages one or more Accounts. Each Account consists of AWS infrastructure, Windows servers, Linux servers, Databases, etc. It is typically managed by an Application Team.

The Cluster provides guardrails and accelerated setup for Applications, including:

  • Enterprise policies (e.g. Server hardening, Service availability)
  • Best practice settings (e.g. Monitoring)
  • Integration points with Enterprise systems (e.g. LDAP, Helpdesk).
  • Central administration, access and reporting.

While Applications manage their own resources within the Cluster guardrails:

  • Servers
  • Databases
  • Access and Permissions
  • Self-service administration and reporting.

Authentication, Access & Permissions


Turbot supports multiple methods of authentication, including LDAP and Turbot local username/passwords. Ultimately, each method of authentication maps to a verified email address of the user.

Each Cluster may specify through options which Authentication methods it supports. For example, Cluster A may specify that authentication MUST be through LDAP, while Cluster B may allow authentication through Turbot managed users.


Permission Categories, Hierarchy & Inheritance

After a user has been Authenticated and granted Access to the Cluster, Turbot uses Permissions through Roles to determine what access they should be granted to which Accounts and Resources.

Permissions in Turbot are designed to be consistent, convenient, secure and flexible.

Each area of Turbot (e.g. Cluster, Account, AWS, S3) defines a (sub)set of permission levels that are consistently defined into specific categories:

IAM model

These definitions combine to produce simple, secure and flexible permission management. Some examples:

  • Alice is granted Owner in Cluster A. She can perform any Owner operation (e.g. Access, Metadata, …, Owner) on any area in Cluster A (e.g. Cluster A, Account A1, AWS A1, S3 A1, Account B1, etc).

  • Bob is granted Metadata in Account B1. He can perform any Metadata operation (e.g. Metadata, Access) in any area of Account B (e.g. Account B1, AWS B1, EC2 B1, etc).

  • Carol is granted ReadOnly in S3 A2. She can perform any ReadOnly operation (e.g. ReadOnly, Metadata, Access) in S3 A2, but has no access to S3 A1 or other areas.

Turbot Apps

Controls and policies are ultimately implemented as Turbot Applications. Examples include EC2, S3, Redshift, RDS, etc. Applications utilize the policy, IAM, and automation models defined by Turbot to make implementation simple and consistent.

An application includes the following elements:

  • Basic information including a name, description.
  • Option definitions, allowing application settings.
  • AWS permissions mapped to the Turbot IAM model.
  • Security group definitions specific to the application.
  • Tasks to be run automatically, providing detective controls & best practices.
  • Custom CloudFormation templates for specific control or resource requirements.
  • Monitoring alarm definitions and templates.


Turbot provides the following applications with controls and best practices:

  • Core
  • EC2
  • KMS
  • RDS
  • Redshift
  • S3


Extending Turbot’s controls and best practices with custom applications is a key item on our development roadmap, but not currently supported. We’d love to discuss any ideas or suggestions for application extensions, please contact support!



An Account manages infrastructure Resources (e.g. AWS services, servers, databases, etc), defining policies, automation and access that apply across the Resources.

Accounts are used to separate Application Environments, providing strict governance boundary between them.


A software application being used or developed in the environment. May be custom or packaged software.

Each Application (e.g. SAP) may have multiple Application Environments (e.g. Production, QA, Test, Development).

Application Environment

An Application Environment is a single tier of access and use of an Application. Each Application typically has multiple Application Environments. Examples may be: SAP Production, SAP QA, SAP Test, SAP Development.

Often, Application Environments are separated into different Accounts.

Application Team

The team working on a specific Application or Application Environment with the best working knowledge of the software and the infrastructure it requires.


A Cluster manages one or more Accounts, defining policies, automation and access that apply across the Accounts.

Each Turbot Cluster is independent of other Turbot Clusters, making the Cluster the highest level of control in Turbot.

Clusters are normally managed by a central support team, helping application teams to work in their Accounts.


The company or group running one or more Clusters.

Was this article helpful?
0 out of 0 found this helpful