41 posts tagged with "Fix"

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.

Stax has updated a series of rules detecting publicly open S3 buckets to improve the logic around checking for permissions.

Previously, the given rules would require explicit matches of a policy with either the action of s3:GetObject or s3:PutObject, meaning policies which allowed s3:*, or an array of actions, wouldn't be considered correctly for the purposes of compliance.

This potentially resulted in false negatives for the affected rules, whereby a bucket wouldn't be considered to be publicly open when it had a directly attached policy, and a previously-invalid policy. This does not affect reporting for buckets where public access block was enabled, or where global grants were given.

The list of affected rules is as follows:

• S3 allows action to any principal in Organization Rules

• S3 Buckets should not be Publicly Open for Writes in Organization Rules

• S3 Buckets should not be Publicly Open for Reads in Organization Rules

• S3 Buckets should not be Publicly Open for Writes in S3 Best Practices, versions 1.0 and 1.1

• S3 Buckets should not be Publicly Open for Reads in S3 Best Practices, versions 1.0 and 1.1

Below is an example policy that would previously incorrectly pass these rules, but now will fail appropriately:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccessToMyBucket",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::hello-world-this-is-a-bucket/*",
        }
    ]
}

If you see previously existing buckets now showing as noncompliant, it is possible that they were previously ignored by this edge case. For any questions around this change, or if you need assistance understand how the change applies to your buckets, please raise a support case.

An update has been applied to Stax's Events service to resolve a bug where AWS-generated events were not delivered as expected.

The Events documentation indicates that AWS-generated events raised in Stax-managed AWS accounts are centralized into the default AWS EventBridge Event Bus in your security account. The actual behaviour exhibited was that events were only emitted to the EventBridge Event Bus for events in the security and logging accounts.

The fix for this bug may result in a material increase to the volume of events received. If you have a downstream system (such as a SIEM) configured, you should consider any volume constraints that may be encountered by this increase in volume.

This fix is being rolled out to affected Stax tenancies over the coming days.

If you have any questions about this change, please contact your Customer Success Manager or raise a support case.

You can now find out who created/onboarded Stax-managed AWS accounts using the Stax API or SDK. This allows for enhanced visibility into your AWS accounts and where they originated.

For accounts created using Stax, the CreatedBy field will now return the UUID of the user that created the account. For accounts onboarded into Stax, the CreatedBy field will reflect the identity of the user who performed the onboarding action. You can retrieve this information using the Fetch Accounts API endpoint or ReadAccounts in the SDK. This can be further resolved to the user's details using the Fetch Stax Users, Federated Users and API Tokens API endpoint, or ReadUsers in the SDK.

Check out your installation's API documentation to find out more about how to use the Fetch Accounts endpoint:

• stax-au1

• stax-eu1

• stax-us1

Check out the SDK examples to find out more about how to use the ReadAccounts and ReadUsers methods.

Considerations​

• This update applies to all Stax-managed AWS accounts created or onboarded on or after 23 February 2021. Accounts created or onboarded prior to this date will not return any CreatedBy information.

AWS VPC Flow Logs must be directed to a CloudWatch Log group within the same AWS account, and same AWS region as the VPC.

A bug has been resolved where the CloudWatch Log group only existed in the Stax Tenancy's AWS region in the format vpcflowlogs-{AwsAccountId}. A change to Stax Networking will now create these CloudWatch Log groups on demand and per-region with the format vpcflowlogs-{AwsAccountId}-{Region}.

Existing Stax Networking VPCs will continue to log to the legacy destination but upon next update of the VPC, the VPC Flow Log destination will be updated to the new CloudWatch Log group. Log entries that have been created in the existing CloudWatch Log group will not be deleted.

If you have any questions about how this change may impact you, please raise a support case.

A bug has been resolved that prevented the deployment of Fargate containers into a private subnet within a Stax Networks VPC. When trying to deploy a container, you may have received an error message similar to the following:

CannotPullContainerError: failed to resolve ref "123456789012.dkr.ecr.ap-southeast-2.amazonaws.com/nginx:latest": failed to do request: Head https://123456789012.dkr.ecr.ap-southeast-2.amazonaws.com/v2/nginx/manifests/latest: dial tcp: lookup 751463547...

This error was caused by the absence of a specific DNS record for the ECR VPC Interface endpoint.

To resolve this issue, when the ECR Interface endpoint is enabled in a Networking Hub, a new Route 53 resource record will be created for *.dkr.ecr.<region>.amazonaws.com. This resource record will permit images to be pulled from ECR for use within Fargate.

If you have existing Networking Hubs in place, you must disable and enable the ECR Interface endpoint to create the new Route 53 resource record.

To improve the user experience when creating Stax Account Types, two improvements have been introduced.

• Added: Reuse of old Account Type names. Previously, Stax Account Type names could not be reused after an Account Type is deleted. This behavior has been changed to permit name reuse.

• Fixed: Improved error handling for Account Type creation. In the event that an attempt was made to create an Account Type with the same name as an existing Account Type, the operation would fail silently with no error. An error will now be displayed.

A bug has been resolved with the Workloads API's Update Workload method's schema implementation.

The Update Workload schema has been adjusted to remove the CatalogueVersionId as a mandatory property. It also adds CatalogueId and Parameters to the schema documentation to reflect the implementation.

• Changed: CatalogueVersionId is now optional

• Added: CatalogueId is now defined in the schema

• Added: Parameters are now defined in the schema

A bug has been resolved with the Workloads API's Update Workload method's documentation.

The Update Workload documentation has been clarified to properly reflect the capability to Protect Workloads using the Protection property, as well as mandating the CatalogueVersionId property to ensure the update process occurs correctly.

• Added: Protection property (boolean)

• Changed: CatalogueVersionId is now mandatory

• Changed: Tags now has a more defined object schema

• Removed: Name property as it was unused

There is no change to the underlying functionality of the API, this is strictly a documentation/definition update.

A number of bug fixes have been released for Stax Policies.

Reject duplicate Organization Policies​

Users will now receive an immediate failure response from the Stax API when trying to attach an Organization Policy that has already been attached to the organization. This is to prevent duplicate attachments from occurring.

Prevent duplicate Organization Policy entries​

The Stax platform will no longer allow duplicate Organization Policies to be attached to a customer's organization. This is to resolve a problem where detaching a policy from an Organization that had the policy attached more than once would result in a detachment failure.

Stax Policy error feedback​

Improvements have been made to correctly report failures when using Stax Policies. This fix will result in an accurate Failure status being returned for the relevant Task Id.