kubectl works against the EKS cluster

September 15, 2026 · v1.5.12

v1.5.12 is an EKS release. aws eks update-kubeconfig now produces a kubeconfig that works: k3s authenticates the IAM exec token aws eks get-token mints, through a TokenReview webhook MiniStack answers itself, so there is no longer any need to copy the admin kubeconfig out of the container. The five general-purpose access policies grant their published Kubernetes permissions, and Pod Identity associations arrive for the controllers that read them. Alongside that, an ECS task reports every lifecycle state AWS documents, a resource-scoped IAM policy matches instead of denying, and AWS::IAM::Policy is provisioned inline the way CloudFormation does it.

New

• EKS — aws eks update-kubeconfig works against MiniStack. k3s could not authenticate the IAM exec token aws eks get-token produces, so the only way in was to copy the admin kubeconfig out of the container. MiniStack now answers a TokenReview webhook: AUTH=false accepts local bearer tokens, AUTH=true verifies the presigned token and then requires a creator or Access Entry grant. The five general-purpose access policies grant their published Kubernetes permissions at cluster or namespace scope. Contributed by @jgrumboe. Reported by @StraggleCraft.
• EKS — Pod Identity associations. The five operations did not exist, so a controller that reads pod identity to find its role, the AWS Load Balancer Controller among them, could not run against MiniStack. Create, Describe, List, Update and Delete serve the records, one per namespace and service account. Deleting a cluster removes them with it. Reported by @josephaw1022.

Fixes

• ECS — a task walks the whole lifecycle. A Docker-backed task went straight from PENDING to RUNNING to STOPPED, so a consumer waiting on any other state waited forever. It now reports the states AWS documents, in order: PROVISIONING, PENDING, ACTIVATING, then DEACTIVATING, STOPPING, DEPROVISIONING and STOPPED. Reported by @iot-rocket.
• ECS — the task record matches a real one. The version counter was minted at 1 and never moved, so a consumer could not tell a stale DescribeTasks copy from the current one; it now counts the way a real Fargate task does. Only an awsvpc task reports an elastic network interface, attachmentsStatus is gone from the task shape because AWS has it on Cluster only, and the metadata endpoint reports the status the task is actually in rather than a literal RUNNING. Contributed by @iot-rocket.
• IAM — a resource-scoped policy matches, instead of denying. Under AUTH=true the resource ARN resolved to * for whole families of request, so only Resource: "*" matched and everything narrower was denied. IoT jobs, provisioning templates, both IoT data planes, multi-level MQTT topics and API Gateway invokes now resolve to their real ARNs. Contributed by @iot-rocket.
• CloudFormation — AWS::IAM::Policy is provisioned inline, not as a managed policy. The document was stored as an account-global managed policy and attached, where CloudFormation embeds it on each Role, User and Group it names. CDK derives PolicyName from the construct path, so stacks sharing a path collapsed onto one record and each deploy took the grants from the ones before it. Contributed by @iot-rocket.
• Lambda — SQS event source batches are dispatched concurrently. One thread polled every mapping and waited for each invoke, so a slow handler held messages on unrelated queues, and ScalingConfig.MaximumConcurrency was stored but ignored. A FIFO event source is held to one batch at a time so message groups keep their order. Contributed by @ThailerL.
• Cognito — a hosted-UI request that invokes a Lambda trigger no longer deadlocks. /saml2/idpresponse, /oauth2/idpresponse and /oauth2/token ran on the event loop, so a trigger calling back into MiniStack queued behind its own request and timed out as a 400. Contributed by @kjdev.
• SQS — every batch action validates the request before its entries. The ten-entry limit reached SendMessageBatch only. DeleteMessageBatch and ChangeMessageVisibilityBatch now refuse an empty batch, more than ten entries, repeated ids and malformed ids, failing the whole request rather than landing in Failed. Contributed by @CaptainAni187. Reported by @jespinoza-shippo.
• S3 — a notification configuration whose destination does not exist is refused. The configuration was stored and the failed test delivery swallowed, so a queue or topic that was not there looked like a successful setup and no event ever arrived. Reported by @ortizgui.
• Persistence — every service module declares the same state contract. A module could expose get_state, a restore_state, both or neither, so persistence was wired per service and nothing could be derived from it. Every module now exposes the same get_state / load_persisted_state / reset trio, and the save map and reset set are derived from SERVICE_REGISTRY instead of a hand-maintained dict beside it — which is how cloudcontrol, config, cur and organizations came to be dropped on every warm boot. A test now refuses any service that would be saved with no way to restore it. Contributed by @jgrumboe.
• SES — one v2 implementation, returning the v1 MessageId shape. An unreachable copy of the v2 endpoints had drifted from the live one; removing it surfaced a divergence it hid, where SendEmail answered an id prefixed ministack- instead of the shared <uuid>@email.amazonses.com. Contributed by @jgrumboe.

Upgrade

docker pull ministackorg/ministack:1.5.12
docker run -d -p 4566:4566 ministackorg/ministack:1.5.12

Or pin in compose.yaml:

services:
  ministack:
    image: ministackorg/ministack:1.5.12
    ports:
      - "4566:4566"