ministackorg/ministack v1.3.17

on GitHub

What's Changed

New Contributors

• @hectormauer made their first contribution in #507

[1.3.17] — 2026-04-28

Added

• ministackorg/ministack:full Docker variant — Debian/glibc-based superset of the regular Alpine image, adding duckdb (Athena engine), psycopg2-binary (PostgreSQL driver), and pymysql (MySQL driver). DuckDB and psycopg2 ship manylinux wheels but no musllinux wheels, so on Alpine they either fall back to source-builds or silently disable themselves; the :full tag installs them cleanly. Published in lockstep with the regular image on every release: :full always points at the latest Debian build, alongside :{version}-full and :{major}.{minor}-full. The regular :latest / :{version} tags are unchanged. Full image reports edition: full on /_ministack/health; regular reports edition: light. Closes the long-standing Athena-on-Alpine gap raised by @arischow.
• STS GetWebIdentityToken action — implements AWS-spec validation: SigningAlgorithm is required and must be RS256 or ES384; Audience.member.N is required, 1–10 items × 1–1000 chars; DurationSeconds is bounded 60–3600 (default 300). Returns a parseable JWT for OIDC dev flows. Signature is HS256 (not the publicly-verifiable RS256/ES384 real STS publishes via JWKS) — sufficient for emulator workloads that inspect claims, not for clients that verify against AWS JWKS. Requested by @anghel93.

Fixed

• Step Functions child execution integrations now return child execution metadata — arn:aws:states:::states:startExecution starts the nested execution and returns ExecutionArn / StartDate instead of echoing the request payload. arn:aws:states:::aws-sdk:sfn:startExecution now accepts AWS Step Functions' PascalCase integration parameters (StateMachineArn, Input, Name) by translating them to MiniStack's lower-camel Step Functions API shape. Existing .sync and .waitForTaskToken paths preserved. Contributed by @jayjanssen.
• STS GetCallerIdentity returned arn:aws:iam::{account}:root regardless of credentials — tests obtaining temporary credentials via AssumeRole and then verifying the assumed-role identity could never confirm the role. Handler now extracts the AccessKeyId from the SigV4 Authorization header and looks it up in a session map populated by AssumeRole / AssumeRoleWithWebIdentity, returning the matching arn:aws:sts::{account}:assumed-role/{role}/{session} ARN and {role-id}:{session} UserId. Falls back to root for non-session credentials. Contributed by @hectormauer.
• S3 virtual-hosted-style routing broke on non-localhost endpoints — _S3_VHOST_RE was anchored to _MINISTACK_HOST (default localhost), so requests with Host: bucket.ministack:4566 (Docker Compose service name) or any custom hostname fell through to S3 path-style with the wrong bucket — silently breaking AWS SDK for JavaScript v3 setups. Replaced with _extract_s3_vhost_bucket(host) which validates against AWS bucket-naming rules (3–63 chars, lowercase + digits + dots + hyphens, alphanum start/end, no .., not IPv4) and accepts any tail — vhost works against localhost, ministack, custom DNS, or s3.amazonaws.com without configuration. Verified against 40 host-header cases. The dead vhost branch in s3.py:_parse_bucket_key is removed since the rewrite happens at the routing layer. Reported by @mgius-ae.
• Lambda routing missed every API path that wasn't /2015-03-31/functions — the path-based service detector only matched the original Lambda API version date, so unsigned requests to /2019-09-25/functions/.../event-invoke-config (PutFunctionEventInvokeConfig), /2019-09-30/functions/.../provisioned-concurrency, /2021-10-31/functions/.../url, /2018-10-31/layers, /2015-03-31/event-source-mappings, /2015-03-31/tags, /2016-08-19/account-settings, /2018-06-01/runtime/..., and /2020-04-22/code-signing-configs/... all fell through to S3. boto3 always signs (so it routed via SigV4 credential scope), but raw HTTP / curl / the Lambda Runtime API itself missed. Detector now matches ^/{date}/{lambda-resource}/... for every documented resource.
• CloudFormation AWS::Lambda::Function never fetched S3 code — _lambda_create stored Code.S3Bucket / Code.S3Key as metadata but never resolved them against the in-memory S3 service, so every CFN-deployed S3-backed Lambda had code_zip = None and failed to invoke. Inline ZipFile was unaffected; everything else broken. Provisioner now fetches the bytes via the standard Lambda S3 helper. Contributed by @hiddengearz.
• Lambda warm-worker execution path was missing standard runtime env vars — lambda_runtime.py's warm-worker path didn't inject AWS_REGION, AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_LAMBDA_FUNCTION_VERSION, or AWS_LAMBDA_LOG_STREAM_NAME, while the Docker execution path already did. Functions calling boto3.client(...), X-Ray tracers, CloudWatch metric emitters, and any code branching on $LATEST vs published versions ran with an inconsistent environment compared to AWS. Warm-worker now injects the full set, matching Docker mode and AWS spec. Contributed by @hiddengearz.
• 4 AWS wire-format compliance bugs. STS AssumeRole / AssumeRoleWithWebIdentity returned arn:aws:iam::...:assumed-role/... for the assumed-role principal — real AWS uses arn:aws:sts::...:assumed-role/{role}/{session} (any IAM-policy Condition: aws:PrincipalArn checking against the sts shape would mismatch). API Gateway v1 PutIntegration returned HTTP 200 instead of 201. EventBridge StartReplay started in RUNNING state instead of STARTING (background thread still transitions RUNNING → COMPLETED). SNS Subscribe returned PendingConfirmation as SubscriptionArn for HTTP/email pending subscriptions — real AWS returns lowercase pending confirmation (with the space).