Changed
View All Tags
Permission Sets allows for fine-grained control of permissions when users log in to Stax-managed AWS accounts. The feature has been accessible in Preview Mode for some time, but is now generally available.
See Permission Sets to get started.
Limited access to the Management account is now available for Stax-managed AWS Organizations using an account ownership model in which the management account is owned by a reseller. The account is available and can be logged into from the list of Stax-managed AWS accounts in the Stax Console.
This change allows for configuration and visibility of services that are only available in the Management account of AWS Organizations.
For information on the Management account, see Foundation Accounts.
To enable users to access the Management account, grant access by assigning one or more of the three built-in roles to a group of users. See Manage Groups for specific guidance. At this time, the Permission Sets feature is not supported for the Management account.
Stax has updated the SNS topics are not exposed Rule to allow SNS topics shared with a specific AWS Organization or AWS Account to pass the Rule. This means that the Rule will only fail for SNS topics that are shared with no limitations.
The Rule now checks for the existance of a condition checking for a condition restricting access to a specific aws:PrincipalOrgId or aws:PrincipalAccount.
When creating networks using Stax Networks, several CloudFormation stacks are created for provisioning these resources. To allow for easier downstream consumption of resources created as part of these deployments, Stax has added additional outputs to the CloudFormation stacks.
The following fields have been added to both VPC and Transit VPC stacks:
IGWId (Internet Gateway ID)
The following fields have been added to Transit VPC stack only:
NATGatewayOne
NATGatewayTwo
NATGatewayThree
These outputs are created under certain conditions:
The IGWId output is only created if Internet Gateway is enabled
NATGatewayOne is only created if NAT Gateway is enabled
NATGatewayTwo and NATGatewayThree are only created if redundant NAT is enabled
From 1 November 2021, some Australian organizations with an account ownership model whereby a reseller owns either the management account, or all accounts, will notice changes to cost data in Stax. This change is the first of many planned to make it easier for organizations utilizing a resell agreement to effectively manage and consolidate their Stax and AWS bills.
After this date, tax charges that appear as Tax or Tax Refund line items will no longer be available in Financial Mode on the Stax Cost and Data pages. Impacted customers will be able to view all tax charges on their AWS consumption bill from Stax or their reseller.
This change does not apply to organizations where all AWS accounts are customer-owned.
Version 1.4.0 of stax2aws has been released. This update contains the following changes:
Increased the number of roles a user can be assigned to. In previous versions of stax2aws users may have encounterd an error too many roles - SAML assertion is greater than 100kb. Upgrading to version 1.4.0 or greater of stax2aws resolves this error.
Account names (as configured in Stax) are now displayed alongside the account info. Previously the AWS IAM Account Alias was displayed, however relying on this information restricted the number of roles a user could have access to (See above). It also inhibited the user experience when accounts did not have an IAM Alias set. Stax2aws now integrates closely with Stax and will display the Stax account name for all roles.
Default session duration changed to 1 hour (3600 seconds). In line with best practice the default session duration has been adjusted to be 1 hour. This can be increased at log in time by passing the session's desired duration (in seconds) with the new --session-duration parameter. This value can be up to the max-session-duration of the IAM Role being assumed. Providing a value for the --profile parameter will save the provided session duration for future executions.
Apple Silicon and M1 support. stax2aws is now available natively for M1 Mac users.
Stax's user and group APIs have been updated to enable more comprehensive management and recreation of deleted resources.
Previously when a user was deleted from Stax, the email address was unable to be reused to invite a new user and a suport case was required. Users can now be invited with the same email address as a previously deleted user.
Additionally, once a user is deactivated in Stax, they can now be deleted from the Stax console. Previously, deletion was only supported in the API and SDK. This option is available by clicking the vertical ellipsis (⋮) next to the deactivated user's details.
Previously when a group was deleted from Stax, the group name was unable to be reused to create a new group with the same name. Any groups deleted from 13 October 2021 onwards can have their name reused for creation of new groups. For any groups deleted prior to this date, raise a support case to have the change applied to it retroactively.
An update has been applied to the Stax Identity Service to improve performance and reliability.
The update implements security and stability updates to the underlying software as well as laying the foundation for upcoming feature releases. No functional changes have been introduced.
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.
To ensure you receive notice of upcoming changes to Stax, make sure you're subscribed to the status page.
When the UserCreateEvent, UserUpdateEvent, and UserDeleteEvent events occur, Stax Events now includes the user's status in the userStatus property.
See the Security Events Schema documentation for this property's expected values.
An update has been applied to Stax Workloads to improve performance and reliability:
Fixed an issue where the Workloads API would accept a Catalog Item Version from a different Catalog Item resulting in the Workload being created/updated with a Version from an incorrect Catalog. If an invalid Catalog Item Version is used, the API will now return a 400 "Bad Request" response, along with an error payload detailing the 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.