Regions

Guardrails Regions and Discovery

A resource type such as an S3 bucket, EC2 instance, or VPC have three distinct regional attributes in Guardrails:

From a Guardrails perspective, a region can be configured in two ways:

  1. Administrators can decide to set a region as Enabled or Disabled. Setting a region to Disabled will not only stop all resource discovery and remediation, but will also prevent any user action via IAM policies.

  2. If a region is set to Enabled, administrators can set a global policy to Approve all regions, a set of regions, and even the approved services in a specific region.

Regional Availability

Regions are defined by the cloud provider:

Even though a said region might exist, certain services might not be available in a particular region. Before attempting to enable regions for a particular service, ensure that the cloud provider provides the required service in the desired region.

AWS regions can be enabled at the Turbot level via the policy AWS > Account > Regions [Default]. This policy accepts a YAML list of regions as well as the wildcard operator (*).

GCP regions can be enabled at the Turbot level via the policy GCP > Project > Regions [Default]. This policy accepts a YAML list of regions as well as the wildcard operator (*).

Guardrails does NOT have a region resource type for Azure, thus there is no region discovery. Resource discovery targets Resource Groups. The Resource Groups in Azure can be defined via the policy Azure > Account > Regions [Default], which is again a YAML list.

Discovery

Guardrails allows administrators to control which regions are discovered, as well as which regions any specific resource type can be discovered in. Enabling a region for discovery allows Guardrails to describe all resources in the region, and will populate CMDB with relevant metadata. Keep in mind that custom permissions on the Guardrails IAM role or various resources can impact resources discoverability. The resource will often show as existing, but Guardrails will contain no metadata about the resource.

IMPORTANT NOTE: Any region that is NOT discovered will NOT exist in the Guardrails CMDB, and as such Guardrails cannot manage resources in non-discoverable regions.
IMPORTANT NOTE: A region can be allowed for discovery while also being NOT approved for use. In this scenario, administrators can choose to discover all regions but only allow resources to exist in a subset of regions.

Discovering Regions

If a region and service is enabled in Guardrails, resources will automatically get discovered. Regions are added and removed from the CMDB via a discovery control that targets the account or project:

Region discovery is controlled by the top level Regions policy:

The default value for these policies contains a list of all regions that can be discovered. Remember that only regions that can be discovered by Guardrails can have remediation and preventative action taken.

Approved Regions

All regional resource types have an Approved > Regions policy that allows administrators to determine where resources of that type are allowed to exist.

All Approved Regions policies follow the same format:

Through the use of cascading default policies, Guardrails allows flexibility in setting Approved Regions policies at all levels - Turbot, folder, account, services, and resources.

  1. Each provider has a top level Approved Regions [Default] policy.
  1. Each regional service has its own Approved Regions [Default] policy.
  1. Each regional resource type has an Approved > Regions policy.

Due to the way that default policies cascade, it is possible to quickly set regional restrictions with only a few policies. For example:

Example AWS Scenarios

Run everything in all regions

Discover everywhere, only approve specific regions for use

Allow use in specific regions for everyone, including Guardrails

Discover all regions and approve all regions, but only allow EC2 in US East 1