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.
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.
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.
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.
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 account tags are now applied to cost and compliance data in Stax. This enriched data allows you to organize, view, and group your resources using account tags to better meet your business needs.
As a result of Stax's improvement to propagate account tags to AWS accounts, these tags are now available in Stax's cost and compliance data. This means they can be used with Views on the Dashboard, Cost, Data and Rules pages of Stax. Within 24 hours of adding or modifying an account tag, the tag will be applied to all of that account's resources represented in Stax's cost and compliance data. Tags added via Stax take the format of stax:user:<tag_key>.
If you're subscribed only to the Stax Cost & Compliance module, you can make use of this feature by tagging AWS account resources directly. Tags will propagate to all resources in cost and compliance data in the same <tag_key> format as they appear in AWS.
While changes made to account tags directly within AWS will be represented in cost and compliance data, it is recommended that changes are made to Stax-managed account tags from within Stax using the console, API, or SDK.
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 asnon-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.