Amazon EKS now supports multiple external OIDC identity providers per cluster

Amazon Elastic Kubernetes Service (Amazon EKS) now supports multiple external OpenID Connect (OIDC) identity providers per cluster. You can associate up to 10 OIDC identity providers with a single cluster, giving you more flexibility in how you authenticate users and workloads to your Kubernetes clusters. Many organizations use different identity providers for different user populations, such as employees, contractors, and CI/CD systems. You can now associate each of these providers directly with your cluster, without consolidating users into a single provider or running an intermediary identity broker. Each provider is configured and managed independently, so each population authenticates through its own provider and identity mapping. Your existing IAM authentication continues to work alongside every configured provider. You add each provider the same way as before, using the AWS Management Console or the AssociateIdentityProviderConfig API through the AWS CLI and AWS SDKs. This capability is available at no additional cost in all AWS Regions where Amazon EKS is available. To learn more, see Grant users access to Kubernetes with an external OIDC provider in the Amazon EKS User Guide.
Quelle: aws.amazon.com

Amazon ECS now automatically detects and repairs container instances with impaired agent connectivity

Amazon Elastic Container Service (Amazon ECS) now automatically detects and repairs container instances, enabling customers to reduce undetected workload failures and improve application availability without manual intervention.
With this launch, Amazon ECS continuously monitors agent connectivity across container instances. Infrastructure events such as EBS volume degradation, host thermal events, or network connectivity failures can sever the ECS agent’s connection to the ECS control plane. Amazon ECS now surfaces a new type of container instance health change event (AGENT_CONNECTIVITY) for all compute options: AWS Fargate, Amazon ECS Managed Instances, and Amazon ECS on EC2. For ECS Managed Instances and AWS Fargate, ECS automatically performs recovery – automatically draining running tasks and launching replacement capacity while deregistering impaired instances. Customers running workloads on Amazon ECS on EC2, can use this health change event to drive instance replacement workflows.
This capability is available at no additional cost in all AWS Commercial and AWS GovCloud (US) Regions. To learn more, see Monitor Amazon ECS Container Instance Health.
Quelle: aws.amazon.com

MinIO End of Life: How to Stay Patched and Audit-Ready with Docker ELS

MinIO reached end of life in February 2026. Docker Extended Lifecycle Support (ELS) keeps end-of-life software like it patched, compliant, and audit-ready for up to five years, covering versions upstream no longer supports all the way up to entire projects.

On February 13, 2026, the MinIO open-source project was archived upstream. A project with more than a billion Docker pulls stopped shipping releases, bug fixes, and security patches overnight. From that day forward, every environment running MinIO is exposed. New CVEs in MinIO and its Go dependency tree now arrive with no upstream patch behind them, and an audit reads that as unsupported software in production.

And MinIO is only the newest instance of a wider problem. Black Duck’s 2026 Open Source Security and Risk Analysis report found that 93% of commercial codebases carry components with no development activity in at least two years. The same pattern runs across the stack. Node 18, Python 3.8, and older Airflow releases still run in production long after upstream support ended, and frameworks like FedRAMP, DORA, and the Cyber Resilience Act treat unpatched end-of-life software as an audit finding. The migration deadline ends up set by the audit calendar instead of the roadmap.

Docker Hardened Images Extended Lifecycle Support exists to hand that schedule back to you. The model is simple. Request an ELS image, and Docker builds and maintains it for up to five years past upstream end of life. The maintained MinIO image is the newest proof of that model.

MinIO lives on as the newest ELS update

The archive lands on the storage layer, where migrations are measured in petabytes. Moving a production object store to a different system is slow, expensive work, and the CVE exposure keeps growing while that work runs.

Teams running MinIO have three options

Move to a commercial replacement and take on new licensing and lock-in.

Carry the patches yourself, which means staffing sustained Go security engineering for a project that no longer ships fixes.

Keep what you run and put a vendor on the hook for it. 

Doing nothing is not a fourth option. 

Docker identified the archive as a live exposure across its customers’ software supply chains and built the answer into the catalog, where MinIO lives on as a maintained, hardened image. Docker tracks new CVEs across MinIO and its full Go dependency graph, transitive dependencies included at no extra cost, then backports the fixes, rebuilds, and ships. Your object store stays supported and your audits stay clean.

Extended Lifecycle Support for your whole fleet

What ELS does for MinIO, it does for any end-of-life component you need to keep. An EOL finding forces a choice between two bad projects. Rush the migration and risk breaking production, or file the exception and watch the list grow every quarter. ELS removes that deadline. Patches and audit evidence keep flowing on the images already in production while the migration happens on the roadmap’s schedule.

The entitlement is built for how end of life actually arrives, on staggered dates across a fleet. Applied to a repository, it covers every available ELS version there. When one migration completes, you re-point it at the next repository, and the coverage moves with the risk.

Coverage is not limited to a fixed list either. Docker watches the end-of-life calendar and builds ahead of it, and anything you don’t see in the catalog, you can request. The span runs from end-of-life versions of supported software all the way up to entire archived projects. Nginx, Node, and Python ELS images are already there.

ELS is a paid add-on to a Docker Hardened Images subscription, and it runs on the same rails as the rest of DHI:

Name it, get it. Tell Docker the end-of-life line your production depends on. Docker builds it hardened and maintains it at the line’s newest patch version.

Adopt without a migration. ELS-tagged images appear in the standard DHI catalog alongside LTS tags. Same registry, same workflow, a FROM-line change.

Stay patched for years. Critical and high-severity CVEs are patched on a 14-day SLA, for up to five years past end of life.

Evidence included. Every ELS image holds the same standard as the rest of the catalog. Built from source and signed, with SBOMs, VEX statements, and SLSA Build Level 3 provenance maintained for the life of the image.

Those attestations are the difference between extended support and an extended liability. A legacy app with a giant SBOM and no exploitability data just lights up your scanners. ELS ships the evidence with the image, so auditors see signed proof of what’s patched and what’s not exploitable.

If there’s a version in your fleet you can’t migrate off and can’t leave unpatched, that’s an ELS conversation. Browse the DHI catalog to see what’s already covered, and talk to us about the versions you need to keep alive. 

Quelle: https://blog.docker.com/feed/

AWS ParallelCluster 3.16 adds an on-node diagnostics tool

AWS ParallelCluster 3.16 is now generally available with a new on-node diagnostics tool, cluster stability improvements, and an updated HPC and AI/ML software stack.
pcluster-diag is a diagnostics tool built into the ParallelCluster AMIs that lets you run diagnostic checks on any cluster node with a single command, and get a structured report that makes it easier to identify issues. This release also hardens the cluster lifecycle with more resilient cluster creation, updates, and image builds. The software stack is refreshed, with updated NVIDIA driver, CUDA, EFA installer, and Slurm versions. To get started with pcluster-diag, see Troubleshooting with pcluster-diag. For more details, review the AWS ParallelCluster 3.16.0 release notes.
AWS ParallelCluster is an open-source cluster management tool that makes it possible for R&D customers and IT administrators to operate high-performance computing (HPC) clusters on AWS. ParallelCluster is designed to automatically and securely provision cloud resources into elastically-scaling HPC clusters capable of running scientific and engineering workloads at scale on AWS. ParallelCluster is available at no additional charge in the AWS Regions listed here, and you pay only for the AWS resources needed to run your applications. To learn more about launching HPC clusters on AWS, visit the ParallelCluster User Guide. To start using ParallelCluster, see the installation instructions for ParallelCluster UI and CLI.
Quelle: aws.amazon.com

Amazon Connect Customer now supports information extraction for agent voice and chat conversations

Amazon Connect Customer now supports information extraction, which automatically captures key data from voice and chat interactions, reducing manual data capture and improving agent and supervisor productivity. Information extraction captures verbatim values like account numbers, reservation IDs, and product names, as well as derived insights inferred from the conversation such as reason for contact, resolution provided, and next steps promised.
You define conversational analytics rules for what to extract and when. Extraction operates on raw contact content before redaction, so you can capture specific data points while still redacting sensitive values from recordings and transcripts. Agents see extracted values during After Contact Work, supervisors use them to search and review contacts, and developers access them programmatically through APIs, Kinesis Data Streams, and S3 output files. You can also feed extracted values directly into rule actions like email notifications, task creation, and case creation, turning unstructured conversations into automated experiences. For example, a travel company can automatically extract “Hotel Name,” “Reservation ID,” and “Reason for call” from interactions, then populate outbound emails and create follow-up tasks, eliminating manual data entry and reducing handle time. To learn more, see Information extraction in the Amazon Connect Customer Administrator Guide, or visit the Amazon Connect Customer website. For a complete list of conversational analytics capabilities available by AWS Region, refer to Availability of Connect Customer features by Region. 
Quelle: aws.amazon.com