Turbot Identity and Access Management Overview


Turbot includes a robust Guardrails Policy Engine that can apply 300+ options across 65+ AWS Services, Networking, OS, and DB tiers. These Options within Turbot are where Turbot/Admins (and higher permissions) can set policies to be applied across Turbot’s Resource Hierarchy. Options can be defined as a MUST or SHOULD policy allowing flexibility for Turbot/Admins at the different hierarchies to enforce or recommend policies

Policy engine

Key Features of the Policy Engine

  • Real-time continuous controls.
    • Preventive controls block unwanted configurations (e.g. IAM Whitelisting to disable AWS Services from being used, prevent unapproved AMI provisioning, prevent unapproved RDS Engine provisioning, etc.).
    • Detective controls correct unwanted configurations back (e.g. repair cross-account Lambda access policies, repair anonymous access to S3 Buckets, etc.).
  • Transparency unleashed across tiers.
    • All activity audit logged across Turbot, AWS, OS, & DB, aggregated to regional S3 logging buckets per account.
    • Monitor & audit configuration changes in real-time. All raw logs are stored in S3, easy to visualize Logs are visible in the Turbot Console.
  • 300+ policies across AWS, OS, DB, & Networking.
    • Point and click policies, configurations, and controls.
    • Set skip, check, enforce on all policies.
  • Hierarchical policy settings down to the resource.
    • Set policies across one or many accounts & resources per Turbot’s Resource Hierarchy
  • Enforced & Recommend settings for accounts.
    • Set SHOULD policies as default recommendations which are inherited lower in the Resource Hierarchy. SHOULD policies that are inherited can be altered by Turbot/Admins within their respective access hierarchy (e.g. a Cluster Level Turbot/Admin can set the option “AWS > S3 > Enabled” to “Disabled” by default (SHOULD policy). An Account Level Turbot/Admin can change the value to Enable if appropriate.
    • Set MUST policies as enforced settings which are inherited lower in the Resource Hierarchy. MUST policies that are inherited CANNOT be altered by Turbot/Admins within their respective access hierarchy. (e.g. a Cluster Level Turbot/Admin can set the option “S3 Encryption in Transit” to “Enabled” by Policy (MUST policy). An Account Level Turbot/Admin CANNOT change the value to Disabled. Only a higher level Turbot/Admin can alter this by an exception policy.
  • Control policy exceptions.
    • Flexible policy management per account & resources to define exceptions per resource. (e.g. a Cluster wide MUST policy is enforced to ensure S3 Encryption In Transit across all accounts within a Turbot Cluster. If there were applicable accounts without the need for this policy, a Cluster Level Turbot/Admin can make an exception in the applicable accounts.

Common Option Settings Approaches in Turbot

Customers typically approach Turbot Options as a global framework to be applied across all accounts and resources, and only mark exceptions based on workload, compliance, and environment types. Global configurations are often based on least privilege, and ‘fit for use’ as a common theme. Few examples:

  • A customer may align their Turbot Options at the Implementation or Cluster tier in adherence with their internal policies that cover 80% of their workloads. But will have a different set of policies for a highly restricted workload (e.g. HIPPA), where they maybe forcing dedicated tenancy, encryption at rest and in transit, etc.

  • Often customers will disable all AWS Services by default (SHOULD policy) at the Turbot Implementation or Cluster Level. This disables all services in each account, but the Turbot/Admin at the account level can enable services the account needs. This allows only applicable services to be used in each account where the Account team can manage their services as needed.

  • Customers may disable specific AWS Services by Policy (MUST policy) if it competes with an on-premise service, it is not approved by Security or Compliance yet, etc. Any disabled services can always be enabled by exception where applicable, but this provides a protective barrier if a service is not appropriate (e.g. Route53 may not be appropriate for use as you use an internal DNS service, therefore can be disabled across all accounts by policy).

  • Customers may choose to set Options to a detect mode when migrating new accounts into Turbot – this will allow Turbot to notify of any issues that arise without taking immediate action to repair a configuration.

  • MUST and SHOULD policies provide a balance for the Cloud Team to enforce required policies vs recommending defaults which delegates the decision downstream for others to define the value that is applicable. Regardless of how you balance MUST and SHOULD policies, having a request process to make exceptions to MUST policies should be considered when setting up operational processes. (e.g. when an Account Team needs to request an exception to a MUST policy inherited from the Cluster, how do they request an exception? Who handles the exception? etc.)

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