Changelog

Bug fixes

• Guardrails now records when an AWS EC2 volume was last attached or detached, so policies that depend on how recently a volume changed stay in step with what has actually happened to it. For example, set AWS > EC2 > Volume > Active > Last Modified to a Force active if last modified <= ... days value to keep a volume active while its attachment has changed within that window.

What's new?

• You can now see which AMIs an EC2 instance was built from, so you can tell an instance that came from an approved base image from one built from scratch. Add ImageAncestryEntries to AWS > EC2 > Instance > CMDB > Attributes and give the Guardrails role the ec2:GetImageAncestry permission. The chain works even when the AMI belongs to another account, and each entry gives you an AMI ID you can look up. The attribute is not enabled by default, so nothing is recorded until you add it.

What's new?

• You can now find an AMI by its AMI ID. AWS > EC2 > AMI resources now include the AMI ID, for example ami-0e8f3b9d098b2d7d4, as an AKA alongside the existing ARN, so the ID can be used anywhere an AKA is accepted, including search, policy settings, filters and the API. AMIs already in the CMDB pick up the new AKA the next time the AWS > EC2 > AMI > CMDB control runs.

What's new?

• The Usage controls and their Usage and Usage > Limit policies have been retired from the resource types in the mods listed below. The Approved > Usage policies are unaffected and remain available.

Released versions:

• aws-batch v5.10.0
• aws-cloudformation v5.15.0
• aws-kinesis v5.13.0
• aws-msk v5.9.0
• aws-sagemaker v5.16.0
• aws-sns v5.22.0

Control Types

Removed

• AWS > Batch > Compute Environment > Usage
• AWS > Batch > Job Definition > Usage
• AWS > Batch > Job Queue > Usage
• AWS > CloudFormation > Hook > Usage
• AWS > CloudFormation > Stack > Usage
• AWS > CloudFormation > StackSet > Usage
• AWS > Kinesis > Consumer > Usage
• AWS > Kinesis > Stream > Usage
• AWS > MSK > Cluster > Usage
• AWS > MSK > Serverless Cluster > Usage
• AWS > SageMaker > Notebook Instance > Usage
• AWS > SageMaker > Project > Usage
• AWS > SNS > Subscription > Usage
• AWS > SNS > Topic > Usage

Policy Types

Removed

• AWS > Batch > Compute Environment > Usage
• AWS > Batch > Compute Environment > Usage > Limit
• AWS > Batch > Job Definition > Usage
• AWS > Batch > Job Definition > Usage > Limit
• AWS > Batch > Job Queue > Usage
• AWS > Batch > Job Queue > Usage > Limit
• AWS > CloudFormation > Hook > Usage
• AWS > CloudFormation > Hook > Usage > Limit
• AWS > CloudFormation > Stack > Usage
• AWS > CloudFormation > Stack > Usage > Limit
• AWS > CloudFormation > StackSet > Usage
• AWS > CloudFormation > StackSet > Usage > Limit
• AWS > Kinesis > Consumer > Usage
• AWS > Kinesis > Consumer > Usage > Limit
• AWS > Kinesis > Stream > Usage
• AWS > Kinesis > Stream > Usage > Limit
• AWS > MSK > Cluster > Usage
• AWS > MSK > Cluster > Usage > Limit
• AWS > MSK > Serverless Cluster > Usage
• AWS > MSK > Serverless Cluster > Usage > Limit
• AWS > SageMaker > Notebook Instance > Usage
• AWS > SageMaker > Notebook Instance > Usage > Limit
• AWS > SageMaker > Project > Usage
• AWS > SageMaker > Project > Usage > Limit
• AWS > SNS > Subscription > Usage
• AWS > SNS > Subscription > Usage > Limit
• AWS > SNS > Topic > Usage
• AWS > SNS > Topic > Usage > Limit

What's new?

• You can now check foundation models against a list of allowed models. Set AWS > Bedrock > Foundation Model > Allowed > Custom to Check: Allowed, then define the list as a calculated policy on AWS > Bedrock > Foundation Model > Allowed > Custom > Rules. Rules match on provider, model ID and exact model version, so you can allow a whole provider, a single model version, or every version of a model family. Both policies default to Skip, so nothing is raised until you set them.

Control Types

Added

• AWS > Bedrock > Foundation Model > Allowed
• AWS > Bedrock > Foundation Model > Allowed > Custom

Policy Types

Added

• AWS > Bedrock > Foundation Model > Allowed
• AWS > Bedrock > Foundation Model > Allowed > Custom
• AWS > Bedrock > Foundation Model > Allowed > Custom > Rules

What's new?

• Added the Azure > AI Foundry > RAI Policy > Content Filters control and policies to check or enforce the content filters on an RAI policy, with a sub-policy per filter on the input and output sides (Disabled, Enabled, Enabled and blocking), a Severity Threshold for each harm category, and a Mode. Each filter sub-policy defaults to Skip, so only the filters you set are checked and Enforce: Configured corrects only those.

Control Types

Added

• Azure > AI Foundry > RAI Policy > Content Filters

Policy Types

Added

• Azure > AI Foundry > RAI Policy > Content Filters
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Hate
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Hate > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Indirect Attack
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Indirect Attack Spotlighting
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Jailbreak
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Profanity
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Selfharm
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Selfharm > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Sexual
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Sexual > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Violence
• Azure > AI Foundry > RAI Policy > Content Filters > Input Filter > Violence > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Mode
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Hate
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Hate > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Profanity
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Protected Material Code
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Protected Material Text
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Selfharm
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Selfharm > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Sexual
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Sexual > Severity Threshold
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Ungrounded Material
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Violence
• Azure > AI Foundry > RAI Policy > Content Filters > Output Filter > Violence > Severity Threshold

Action Types

Added

• Azure > AI Foundry > RAI Policy > Set Content Filters

What's new?

• The Usage controls and their Usage and Usage > Limit policies have been retired from the resource types in the mods listed below. The Approved > Usage policies are unaffected and remain available.

Released versions:

• aws-backup v5.16.0
• aws-efs v5.13.0
• aws-eks v5.11.0
• aws-emr v5.12.0
• aws-route53 v6.12.0
• aws-s3 v5.35.0
• aws-secretsmanager v5.13.0
• aws-sqs v5.22.0

Control Types

Removed

• AWS > Backup > Backup Plan > Usage
• AWS > Backup > Backup Vault > Usage
• AWS > EFS > FileSystem > Usage
• AWS > EFS > Mount Target > Usage
• AWS > EKS > Cluster > Usage
• AWS > EKS > Node Group > Usage
• AWS > EMR > Cluster > Usage
• AWS > EMR > Security Configuration > Usage
• AWS > Route 53 > Hosted Zone > Usage
• AWS > S3 > Bucket > Usage
• AWS > Secrets Manager > Secret > Usage
• AWS > SQS > Queue > Usage

Policy Types

Removed

• AWS > Backup > Backup Plan > Usage
• AWS > Backup > Backup Plan > Usage > Limit
• AWS > Backup > Backup Vault > Usage
• AWS > Backup > Backup Vault > Usage > Limit
• AWS > EFS > FileSystem > Usage
• AWS > EFS > FileSystem > Usage > Limit
• AWS > EFS > Mount Target > Usage
• AWS > EFS > Mount Target > Usage > Limit
• AWS > EKS > Cluster > Usage
• AWS > EKS > Cluster > Usage > Limit
• AWS > EKS > Node Group > Usage
• AWS > EKS > Node Group > Usage > Limit
• AWS > EMR > Cluster > Usage
• AWS > EMR > Cluster > Usage > Limit
• AWS > EMR > Security Configuration > Usage
• AWS > EMR > Security Configuration > Usage > Limit
• AWS > Route 53 > Hosted Zone > Usage
• AWS > Route 53 > Hosted Zone > Usage > Limit
• AWS > S3 > Bucket > Usage
• AWS > S3 > Bucket > Usage > Limit
• AWS > Secrets Manager > Secret > Usage
• AWS > Secrets Manager > Secret > Usage > Limit
• AWS > SQS > Queue > Usage
• AWS > SQS > Queue > Usage > Limit

What's new?

• The AWS > Bedrock > Guardrail > Settings control now reports one row per setting, showing whether each is OK, in Alarm or skipped, with the guardrail's current value and the value your policy expects. Settings you have not configured are listed as skipped.

Bug fixes

• Enforce: Configured no longer clears parts of a guardrail's configuration that none of your sub-policies manage, such as the actions and enablement flags AWS keeps on content filters, denied topics and PII entities. Those are now left as they are, and the control no longer treats them as a mismatch, so a guardrail that already matches your policies stays OK instead of being re-enforced on every cycle.

Bug fixes

• Improved the internal GraphQL queries used by the EC2 controls and actions, for faster processing of real-time instance events.

Bug fixes

• Rules and targets created by the Event Handlers [Global] stack are now kept in the CMDB when AWS > Events > Rule > CMDB or AWS > Events > Target > CMDB is set to Enforce: Enabled for Guardrails infrastructure only. Previously they were removed when AWS > Turbot > Event Handlers [Global] > Events > Rules > Name Prefix was set to its own value. Other rules and targets are still removed, and accounts using the default Enforce: Enabled are unaffected.

Bug fixes

• The GCP > Compute Engine > Instance > Shielded Instance Configuration control no longer errors on every run when set to Enforce against a running instance. GCP only accepts Shielded VM configuration changes while an instance is stopped, so the control now applies the configuration once the instance is stopped. It also reports which of Secure Boot, vTPM and Integrity Monitoring does not match, and reports invalid when Integrity Monitoring is required without vTPM.
• The GCP > Compute Engine > Instance > CMDB control now also refreshes while an instance is starting or stopping, so its status settles to the instance's real state.

Bug fixes

• Improved real-time event handling on AWS for events created by automated workflows and cross-account API calls. Some of these events were being silently discarded, which could leave the resources they touch stale in Guardrails and evaluated by controls on out-of-date data. All customers with AWS workloads are recommended to move to this version.

Bug fixes

• The Allowed > Region > Regions policies on GCP > Vertex AI > Endpoint, Model, Notebook Runtime Template and Deployment Resource Pool no longer get stuck in an error state. They were failing because the service-level default they inherit from did not exist; the new GCP > Vertex AI > Allowed Regions [Default] policy fills that gap and inherits from GCP > Project > Allowed Regions [Default], so you can set the regions allowed for Vertex AI resources centrally from the project.

Policy Types

Added

• GCP > Vertex AI > Allowed Regions [Default]

Bug fixes

• The GCP > Notebooks > Instance > Allowed > Region > Regions policy no longer stays stuck in an error state. It inherited from a service-level default that did not exist; the new GCP > Notebooks > Allowed Regions [Default] policy supplies it, inheriting from GCP > Project > Allowed Regions [Default] so the regions allowed for Workbench instances resolve to the project's Regions list by default and can be tightened centrally.

Policy Types

Added

• GCP > Notebooks > Allowed Regions [Default]

Bug fixes

• The regions allowed for API Gateway gateways now follow your project's GCP > Project > Allowed Regions [Default] policy, the same project-level Allowed default every other GCP service uses.

What's new?

• Setting virtual machine schedules is now easier: the Azure > Compute > Virtual Machine > Schedule policy manages both fixed schedule windows and tag-based schedules from a single policy. Each schedule window is now available with Tag override, which enforces the window while letting individual virtual machines override it with a schedule of their own via their schedule tag, and the new Enforce: Per Schedule > Tag schedule option enforces only the schedule from the tag. The tag key is now configurable via the new Azure > Compute > Virtual Machine > Schedule > Tag policy (default turbot_custom_schedule).
• With scheduling consolidated into the Schedule policy, the separate Azure > Compute > Virtual Machine > Schedule Tag policy has been deprecated and now lives under Azure > Compute > Virtual Machine > Schedule in the policy hierarchy. Use the with Tag override or Enforce: Per Schedule > Tag schedule options instead - they provide the same functionality from a single policy. Existing Schedule Tag settings continue to be honored.
• The Schedule control now waits one hour after starting or stopping a virtual machine before acting again, so a manual action taken in the meantime is not immediately overridden.

Bug fixes

• Fixed the Azure > Compute > Virtual Machine > Schedule control remaining stuck in a TBD state with the reason Precheck policy not fully installed or has incorrect target when only the Schedule policy was set.

Policy Types

Added

• Azure > Compute > Virtual Machine > Schedule > Tag

Renamed

• Azure > Compute > Virtual Machine > Schedule Tag to Azure > Compute > Virtual Machine > Schedule > Schedule Tag [Deprecated]

What's new?

• The new GCP > Project > Allowed Regions [Default] policy lets you set the allowed regions for every GCP service from one place: each service's Allowed Regions [Default] policy, such as GCP > Composer > Allowed Regions [Default], now inherits from it. This also clears the error state those service-level policies were stuck in when the project-level default did not exist. They now resolve to the project's Regions list by default and can be tightened centrally.

Policy Types

Added

• GCP > Project > Allowed Regions [Default]

What's new?

• Setting WorkSpace schedules is now easier: the AWS > WorkSpaces > WorkSpace > Schedule policy manages both fixed schedule windows and tag-based schedules from a single policy. Each schedule window is now available with Tag override, which enforces the window while letting individual WorkSpaces override it with a schedule of their own via their schedule tag, and the new Enforce: Per Schedule > Tag schedule option enforces only the schedule from the tag. The tag key is now configurable via the new AWS > WorkSpaces > WorkSpace > Schedule > Tag policy (default turbot_custom_schedule).
• With scheduling consolidated into the Schedule policy, the separate AWS > WorkSpaces > WorkSpace > Schedule Tag policy has been deprecated and now lives under AWS > WorkSpaces > WorkSpace > Schedule in the policy hierarchy. Use the with Tag override or Enforce: Per Schedule > Tag schedule options instead - they provide the same functionality from a single policy. Existing Schedule Tag settings continue to be honored.
• The Schedule control now waits one hour after starting or stopping a WorkSpace before acting again, so a manual action taken in the meantime is not immediately overridden.

Bug fixes

• Fixed the AWS > WorkSpaces > WorkSpace > Schedule control remaining stuck in a TBD state with the reason Precheck policy not fully installed or has incorrect target when only the Schedule policy was set.

Policy Types

Added

• AWS > WorkSpaces > WorkSpace > Schedule > Tag

Renamed

• AWS > WorkSpaces > WorkSpace > Schedule Tag to AWS > WorkSpaces > WorkSpace > Schedule > Schedule Tag [Deprecated]

What's new?

• Setting cluster schedules is now easier: the AWS > Redshift > Cluster > Schedule policy manages both fixed schedule windows and tag-based schedules from a single policy. Each schedule window is now available with Tag override, which enforces the window while letting individual clusters override it with a schedule of their own via their schedule tag, and the new Enforce: Per Schedule > Tag schedule option enforces only the schedule from the tag. The tag key is now configurable via the new AWS > Redshift > Cluster > Schedule > Tag policy (default turbot_custom_schedule).
• With scheduling consolidated into the Schedule policy, the separate AWS > Redshift > Cluster > Schedule Tag policy has been deprecated and now lives under AWS > Redshift > Cluster > Schedule in the policy hierarchy. Use the with Tag override or Enforce: Per Schedule > Tag schedule options instead - they provide the same functionality from a single policy. Existing Schedule Tag settings continue to be honored.
• The Schedule control now waits one hour after starting or stopping a cluster before acting again, so a manual action taken in the meantime is not immediately overridden.

Bug fixes

• Fixed the AWS > Redshift > Cluster > Schedule control remaining stuck in a TBD state with the reason Precheck policy not fully installed or has incorrect target when only the Schedule policy was set.

Policy Types

Added

• AWS > Redshift > Cluster > Schedule > Tag

Renamed

• AWS > Redshift > Cluster > Schedule Tag to AWS > Redshift > Cluster > Schedule > Schedule Tag [Deprecated]

What's new?

• Setting DB instance and DB cluster schedules is now easier: the AWS > RDS > DB Instance > Schedule and AWS > RDS > DB Cluster > Schedule policies manage both fixed schedule windows and tag-based schedules from a single policy. Each schedule window is now available with Tag override, which enforces the window while letting individual DB instances or clusters override it with a schedule of their own via their schedule tag, and the new Enforce: Per Schedule > Tag schedule option enforces only the schedule from the tag. The tag key is configurable via the Schedule > Tag policy (formerly Schedule Tag > Name, default turbot_custom_schedule).
• With scheduling consolidated into the Schedule policies, the separate AWS > RDS > DB Instance > Schedule Tag and AWS > RDS > DB Cluster > Schedule Tag policies have been deprecated and now live under their respective Schedule policies in the policy hierarchy. Use the with Tag override or Enforce: Per Schedule > Tag schedule options instead - they provide the same functionality from a single policy. Existing Schedule Tag settings continue to be honored.
• The Schedule controls now wait one hour after starting or stopping a DB instance or cluster before acting again, so a manual action taken in the meantime is not immediately overridden.

Bug fixes

• Fixed the AWS > RDS > DB Instance > Schedule and AWS > RDS > DB Cluster > Schedule controls remaining stuck in a TBD state with the reason Precheck policy not fully installed or has incorrect target.

Policy Types

Renamed

• AWS > RDS > DB Cluster > Schedule Tag to AWS > RDS > DB Cluster > Schedule > Schedule Tag [Deprecated]
• AWS > RDS > DB Cluster > Schedule Tag > Name to AWS > RDS > DB Cluster > Schedule > Tag
• AWS > RDS > DB Instance > Schedule Tag to AWS > RDS > DB Instance > Schedule > Schedule Tag [Deprecated]
• AWS > RDS > DB Instance > Schedule Tag > Name to AWS > RDS > DB Instance > Schedule > Tag