Stax Changelog logo

Changelog

Back to Homepage Subscribe to Updates

Labels

  • All Posts
  • Fix
  • changed
  • added
  • deprecated
  • removed
  • security
  • notice

Jump to Month

  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
changed
2 years ago

Stax Workloads Update

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.

changed
2 years ago

Deleting Permission Sets

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.

added
2 years ago

Set Default Notifications for New Stax Cost & Compliance Users

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.

changed
2 years ago

Improved Workloads Page

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.

added
2 years ago

Permission Sets Released

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.

changed
2 years ago

stax2aws v1.3.1 released

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.

changed
2 years ago

Improvements to Stax Accounts

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)

changed
2 years ago

Identity Service Updates

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.

changed
2 years ago

Identity Service Updates

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.

Fix
2 years ago

Update to Rule - Ensure S3 Bucket Policy allows HTTPS requests

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.