An update has been applied to Stax Workloads to improve performance and reliability:

• Fixed an issue where the Workloads API would accept invalid characters for the Workload name. Workload names will now be correctly validated against the pattern ^[a-zA-Z][-a-zA-Z0-9]*$. If the Workload name is invalid, the API will return a 400 "Bad Request" response, along with an error payload detailing the schema error.
• Fixed an issue where the Workloads API would accept invalid parameter formats. If an invalid parameter format is provided, the API will now return a 400 "Bad Request" response, along with an error payload detailing the schema error.

These changes have been applied automatically by Stax. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.

The Permission Sets page now allows for deletion of Permission Sets.

When no longer required, Permission Sets can be deleted from the Stax Console. Permission Sets can only be deleted when all Permission Set Assignments have been deleted.

For more information, see Permission Sets in the docs.

Customers subscribed only to the Stax Cost & Compliance module can now set notification preferences when inviting new users. Admins can customize the user's default notifications to align with their needs.

After joining Stax, users can manage their notifications and make changes to their preferences.

The Workloads page now shows deployed workloads in a list.

This improves usability and functionality, while allowing up to 100 deployed Workloads to be displayed at a time. Additionally, you can now click on the View AWS CloudFormation Stack button beside each Workload to log into the Workload's AWS account and view the associated CloudFormation stack.

Permission Sets allows for fine-grained control of permissions when users log in to Stax-managed AWS accounts.

This new feature allows for users in Stax groups to be assigned AWS IAM Policies defining their level of access to accounts in Stax Account Types. Each Permission Set consists of a policy document and a number of (zero or more) assignments. The policy document defines what someone utilizing the Permission Set can do, and the assignment defines who can utilize the Permission Set and where.

To get started, see Permission Sets in the docs.

Version 1.3.1 of stax2aws has been released. This update fixes a bug where stax2aws would report that no roles were available in certain circumstances.

You should upgrade stax2aws to version 1.3.1 or later if you experience this bug.

The Stax Accounts service has been uplifted to improve core operating processes.

This change decreases the time taken to provision new Stax-managed AWS accounts, and improves the reliability of this process. Additionally, the Security Foundation Account now manages Amazon GuardDuty members via AWS Organizations, instead of individually by invitation. This change to the Amazon GuardDuty configuration is in alignment with the latest AWS offerings and recommended best practices.

You don't need to do anything to take advantage of these improvements. Next time you create a new AWS account using the Stax Console, API, or SDK, the upgraded Accounts service will be utilized.

(https://support.stax.io/hc/en-us/articles/4453778959503-About-Accounts)

An update has been applied to the Stax Identity Service to improve performance and reliability.

This system update lays the foundation for upcoming feature releases.

These changes have been applied automatically by Stax. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.

An update has been applied to the Stax Identity Service to improve performance and reliability.

This system update lays the foundation for upcoming feature releases.

These changes have been applied automatically by Stax during the advertised maintenance window. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.

Stax has released an update to the definition of the Rule CIS 2.1.2 - Ensure S3 Bucket Policy allows HTTPS requests. This update better aligns Stax's implementation of the Rule to the definition from Version 1.3.0 of the CIS AWS Foundations Benchmark.

The CIS Benchmark dictates that policies should require HTTPS access specifically for the s3:GetObject action. Previously, Stax's implementation would check for the _, or "wildcard", action. This required that the policy enforce HTTPS for all actions, rather than just _s3:GetObject as specified in the CIS Benchmark. With the updated Rule definition, a bucket with the appropriate policy (as per the CIS benchmark document) on specific action s3:GetObject that would have previously deemed as non-compliant* will now correctly be considered compliant.

To ensure continuity for Rule compliance timelines, Stax has populated the history for this Rule using the updated definition.

If you observe buckets that were previously non-compliant now showing as compliant, it is likely that they were previously marked as non-compliant due to the stricter definition implemented by Stax.

For any questions around this change, or if you need assistance understand how the change applies to your buckets, please raise a support case.