u/Rhopegorn

Paying a cloud API per million tokens is straightforward until the invoice arrives. But when you move to self-hosted large language models (LLMs), the economics flip upside down: you pay for raw compute regardless of whether your GPUs are processing requests or idling.

For platform engineers and machine learning operations (MLOps) leads, tokenomics, the economics of how tokens are produced and what they effectively cost, requires looking at both what you spend and how much you serve.

YAML has been the standard way to write Kubernetes manifests for years. Every example, tutorial, and configuration file you come across is written in it. The problem isn't that YAML is a bad format. It's that YAML gives you a lot of choices, and not all of them are equally good for writing Kubernetes manifests. Some features make files harder to read, some are easy to misuse and others can lead to surprising behavior.

The interesting part is that Kubernetes doesn't actually need most of those features. It only relies on a small subset of YAML. This led to a simple question: if Kubernetes only needs a small part of YAML, why not standardize on that part and avoid the rest? Instead of introducing a new configuration language, SIG CLIintroduced KYAML, a stricter, more consistent way to write YAML.

TL;DR
- KEP 5295
- 4.22=1.35 (beta; feature enabled by default, still requires -o kyaml CLI param)
- 4.21=1.34 (alpha, opt-in) export KUBECTL_KYAML=true

When people talk about cloud sovereignty, the conversation often starts with regions: where a workload runs and where its data is stored. But choosing a region is only part of the story. The architecture of the platform matters just as much, particularly how it separates control, runtime, build, and observability responsibilities across clusters.

With the release of the developer preview of the Krkn Operator in Red Hat Advanced Cluster Management for Kubernetes, platform teams can now run Kubernetes-native chaos engineering directly from their management hub. The operator integrates Krkn, an open source Cloud Native Computing Foundation (CNCF) project, to bring multicluster chaos testing and resilience validation directly to Red Hat Advanced Cluster Management.

Prominent attacks on software development pipelines have resulted in significant financial impact for companies and brought their build processes under scrutiny. While the attack vectors on pipelines are virtually limitless, this article focuses on securing components, processes, and tools involved in building and deploying containerized software through signing, attesting, and verifying a build image. I chose to implement a do-it-yourself (DIY) approach to help understand these concepts. I also compared my approach to Red Hat Advanced Developer Suite, which includes Red Hat Trusted Artifact Signer and Red Hat Trusted Profile Analyzer, and addresses the complexity involved in implementation.

Containers on Red Hat OpenShift can get automatic cryptographic identities through zero trust workload identity manager, but workloads running inside a virtual machine (VM) cannot. In this tutorial, I demonstrate how I bridged that gap using a virtual socket (VSOCK) and a dedicated in-VM SPIRE agent to give every workload — whether it's running as a container or as an application inside a VM — a short-lived, automatically rotating SPIFFE identity.

Centralized secrets management platforms, like HashiCorp Vault, enable organizations to protect some of their most sensitive values (think passwords, tokens, or any type of content that may be deemed protected). Red Hat Ansible Automation Platform includes integrations for several popular secrets management platforms, including HashiCorp Vault, to enable accessing secure values during automation execution. However, regardless of how secure a secrets management system is along with how it protects the content it stores, one of the biggest challenges that organizations need to contend with is handling how consumers access the secrets management platform—also known as the "secret zero problem". A breach of a long-lived credential that's used to read a range of content from the secrets management system has a potential blast radius to negatively impact the security posture of an organization.

When an AI agent introduces itself to another agent, it hands over a digital identity document called an agent card. Our previous post, “Who’s really calling? Securing agent-to-agent communication,” discussed whether that card is authentic at runtime. This post asks, “was the card built by someone you trust in the first place?”

The gap between what an agent claims and what the platform can verify is a real attack surface, and it grows with every new agent you onboard. As agents increasingly discover and call each other at runtime, protocols like Agent2Agent (A2A) have introduced a useful building block for addressing this: the Agent Card. In the same way a model card gives us useful information about a large language model, so does the agent card for an agent. Among that useful metadata are the skills of the agent (what’s it meant to do), its capabilities (e.g., processing an image file), and, finally, a specification for a cryptographic signature.

TL;DR — During performance validation of Red Hat Enterprise Linux 10.2, we identified a kernel scheduler regression that reduced system throughput by up to 93% on multi-NUMA instance types. The regression is bimodal: Workloads either run at full speed or experience severe CPU work starvation. Eliminate this throughput collapse at runtime without rebooting by disabling the NI_RANDOM scheduler feature:

echo NO_NI_RANDOM > /sys/kernel/debug/sched/features
Copy snippet

Issued 2026-07-29

Red Hat Quay release 3.18 is now available with Clair 4.9. The bug fixes that are included in the update are listed in the RHSA-2026:48085 advisory. For the most recent compatibility matrix, see Quay Enterprise 3.x Tested Integrations. For information on the release cadence of Red Hat Quay, see the Red Hat Quay Life Cycle Policy.

As Kubernetes adoption scales, platform teams often hit a painful wall: The exploding cost and complexity of telemetry. When trying to provide isolated service mesh observability for multiple development teams, the default reflex is often "hard tenancy". This provides strict, robust isolation to ensure that a malicious, compromised, or resource-heavy tenant cannot impact others. This means spinning up duplicated, entirely separate instances of Prometheus, Jaeger, and Grafana for every single tenant.

Build a LAMP stack application on Red Hat Enterprise Linux 10 using hardened images and bootc to turn containers into a bootable, verified virtual machine.

Red Hat Enterprise Linux (RHEL) comes with powerful monitoring tools, including:

- Performance Co-Pilot (PCP): The toolbox for collecting data from various systems, storing the data for later evaluation and more
- Grafana: For visualizing data collected with PCP
- Valkey/Redis: For caching

In a simple setup, PCP is installed on a single system, and gathers performance data that gets archived into local files. This provides an invaluable tool for debugging to answer questions like "Why was the load high on the system yesterday at 2am?" With this setup, we can also get graphs of metrics like the traffic running over network interfaces.
RHEL 10.2 adds the PUSH model to Performance Co-Pilot, further simplifying data collection.

Developed with leading global financial institutions and backed by a growing partner ecosystem, the new Lightwell offerings help enterprises reduce open source risk without disruptive upgrades 

Developing applications on Kubernetes
Kubernetes is the foundation of cloud software architectures like microservices and serverless. For developers, Kubernetes brings new processes for continuous integration and continuous deployment; helps you merge code; and automate deployment, operation and scaling across containers in any environment.

If you run kube-linter on your Kubernetes manifests, you probably feel pretty good about your role-based access control (RBAC) setup. It catches wildcard verbs, cluster-admin bindings, and excessive Secret access. But there is a class of vulnerabilities it fundamentally cannot detect: indirect privilege escalation through binding chains.

This post walks through the problem, shows how an attacker exploits it, and introduces kube-chainsaw, a tool that catches what per-object linters miss by building permission graphs from static manifests.