ministackorg/ministack v1.3.61

on GitHub

What's Changed

New Contributors

• @lucas-giaco made their first contribution in #875

[1.3.61] — 2026-06-10

Added

• AmazonMQ (mq) — new service emulator for AWS MQ, covering both RabbitMQ and ActiveMQ engines. Broker control plane: CreateBroker, ListBrokers, DescribeBroker, UpdateBroker, DeleteBroker, RebootBroker, plus DescribeBrokerEngineTypes and DescribeBrokerInstanceOptions (engine / version / instance / storage matrix sourced from real aws mq describe-broker-instance-options output). ActiveMQ user management (CreateUser, DescribeUser, UpdateUser, DeleteUser, ListUsers) and broker tagging (CreateTags, ListTags, DeleteTags). Brokers come up RUNNING immediately (metadata only, no container); CreateBroker validates engine type, version, deployment mode, host instance type, and storage type against the supported matrix. State is account-scoped and persisted. Contributed by @lucas-giaco.
• IAM — GetAccountSummary, GetAccountPasswordPolicy, UpdateAccountPasswordPolicy, DeleteAccountPasswordPolicy, ListAccountAliases, CreateAccountAlias, DeleteAccountAlias — account-level posture reads. GetAccountSummary returns computed counts (Users, Groups, Roles, Policies, MFADevices, MFADevicesInUse, AccountMFAEnabled) plus static quotas. GetAccountPasswordPolicy returns NoSuchEntity (404) before any policy is set, matching real AWS. Account aliases stored per-account (replace-on-create semantics). Contributed by @lahmish.
• IAM — GenerateCredentialReport, GetCredentialReport — generates and returns the account credential report as a CSV (exact AWS column header). One row per user including password_enabled (from login profiles), mfa_active (from MFA device assignments), and access_key_1/2_active (from access-key status). Root account synthetic row included. GetCredentialReport returns ReportNotPresent (410) when no report has been generated. Content is base64-encoded per the AWS blob encoding contract. Contributed by @lahmish.

Fixed

• S3 — event notifications now fire for non-default accounts — PutObject / object-removed notifications are delivered from a background thread that did not inherit the request's account context, so the worker ran under the default account (000000000000): the account-scoped bucket-notification config resolved empty and the event was silently dropped for any non-default account, while SQS / SNS / Lambda / EventBridge targets resolved under the wrong account. The thread now copies the request context (account + region); the s3:TestEvent path had the same gap and is fixed too. Reported by @rsking.