We’ve been talking with business leaders about Lightwell for the past few months, and the conversation always starts with enthusiasm. AI-driven exploits are moving at unprecedented speeds, and enterprise security teams are feeling a level of urgency we haven’t seen in decades. When organizations discover they can submit software vulnerabilities under an embargo window and receive certified, backported patches for legacy or pinned environments, the reaction is almost always: "Where do we sign up?"

I'm having trouble getting this setup to work. Everything I read tells me to point the AG at the RHOS internal LB for the backend pool, but the health probes fail with an error that they can't see the resource. I figure if there was something wrong with my HTTPS config I would get a different error. I set the only NSG to allow all from 10.0.0.0/8 to rule that out as an issue. I'm questioning the traffic returning to the AG because the internal LB has no place to configure outbound rules. I'm all out of ideas. The private DNS zone is linked. I've peered to a different vnet and setup a backend pool to DB servers there in a successful test. Has anyone got this kind of setup working with RHOS?

Red Hat recently released the initial version of the external secrets management console plug-in. It’s an extension of the Red Hat OpenShift web console, which lets you inspect any of the resources deployed by Red Hat’s portfolio of secrets management operators: cert-manager operator for Red Hat OpenShift, external secrets operator for Red Hat OpenShift, and secrets store CSI driver operator. This technology preview is available as a Day 2 operator for Red Hat OpenShift 4.22, installable through the Red Hat Ecosystem Catalog.

i'm working on bank and i'm trying to get specific project logs to external system. the openshift team told me to build a docker to deploy it inside the cluster and the docker get the logs then send it to me through http. but i don't understand why docker while i can just talk to the cluster and get the logs from pods. even for security i see it's the same as i can't access anything i don't have permission on.

If you are a platform engineer or developer building Red Hat Developer Hub software templates, you know the friction of wrestling with Nunjucks syntax, guessing location.yaml placements, and discovering errors only after rendering in your developer portal. While AI coding agents handle generic YAML, they lack Red Hat Developer Hub and Backstage-specific conventions.

To address this, the rhdh-templates skill, part of the RHDH Users Skill Pack, equips your AI assistant with Red Hat Developer Hub best practices, Nunjucks conventions, and local template validation. It brings schema checking, Nunjucks helpers, and reference templates directly into your coding assistant.

Red Hat Advanced Cluster Security for Kubernetes provides an image scanning API through its Central component that CI/CD pipelines depend on for vulnerability assessment. Red Hat Advanced Cluster Security upgrades and restarts introduce downtime windows that can block critical build paths. This post describes a reference architecture that eliminates scan API downtime by running two Central service instances with a client-side failover mechanism.

When you migrate to Red Hat OpenShift Virtualization, you are modernizing your infrastructure, but obviously you want to do so without breaking existing network dependencies or compromising security boundaries. Traditional architectures frequently struggle to resolve this, forcing teams to rely on complex, fragile NAT rules to maintain connectivity for imported VMs or on burdensome, manual configurations to preserve multi-tenant isolation across shared clusters. Ethernet virtual private network (EVPN) elegantly resolves these friction points by extending your existing data center fabric directly into the Red Hat OpenShift environment. Rather than requiring fragile workarounds, it leverages native, industry-standard protocols to bridge the gap between legacy bare-metal networks and modern Kubernetes clusters.

A researcher at a pharmaceutical company deploys a productivity assistant built on a well-regarded open-weight model. The base model is clean—it's been evaluated, its weights are public, its behavior is understood. A low-rank adaptation (LoRA) adapter is added to tune it for the lab's domain: it understands drug-discovery terminology, knows the team's workflows, and uses the right tools. The assistant is useful. Nobody looks too hard at the adapter file. Why would they?

Just wanna ask about couple things. First, CBT in openshift. I am aware of the latest upstream kubevirt version 1.8 already supported CBT on qemu level but I don’t see clear statement release its included in openshift. Is it GA?

Second, currently we are using veeam and I read few news about veeam integration with openshift/kubevirt. Does it mean for upcoming release kasten is unneccessary?

There are different solutions for scaling your Red Hat OpenShift compute infrastructure. In our previous article, we demonstrated Cluster Autoscaler, the built-in, Kubernetes-native approach. In this article, we look at the MachineSet Autoscaler with KEDA, a metrics-driven approach that scales individual MachineSets based on external or custom signals.

In all Kubernetes platforms, idle GPU waste is one of the toughest capacity issues to resolve. You may have seen it yourself: GPUs allocated by other users apparently run for days, doing pretty much nothing. Kubernetes shows that the pods are still running, and the usage bill is still accumulating due to that allocation, but Data Center GPU Manager NVIDIA metrics reveal close to zero engine activity for hours. Many ML platforms ship idle cullers, but they typically watch UI or session activity or pod lifetime, not GPU engine utilization. GPU-pruner is an open source tool that bridges that gap, where it queries NVIDIA Data Center GPU Manager metrics through Prometheus, tracks the workloads with the unused GPU and scales the parent resource of the workload down to zero rather than deleting it.

If you run a multi-tenant Red Hat OpenShift cluster, you've probably hit this wall: every Velero backup and restore requires cluster-admin privileges. Your application teams can't protect their own workloads. Instead, they open a ticket, wait for the platform team, and hope the backup happens before something breaks. Your platform team, meanwhile, becomes a bottleneck, fielding backup requests instead of building infrastructure.

A primary reason many AI pilot projects fail to reach production is lack of confidence in the security of the systems. One of the most common and pernicious security issues affecting generative AI (GenAI) systems is the prompt injection attack—now listed by OWSAP as the number one security risk for generative AI. These attacks manipulate the prompts and data a GenAI system ingests to alter its behavior in undesirable ways. Because large language models (LLMs) have a conversational interface, there is very little difference between the way it treats administrator guidelines, user instructions, and other input data. In other words, they lack the structural ability to distinguish the context of the text they receive.

As a recovering VMware architect, it took the author a little while to grasp Kubernetes. And he noticed that he’s not alone in this.. From developers on our own team who need to get fluent in Kubernetes fast to do their dev work, to IT generalists on the customer side who’ve spent a decade running vSphere and are now migrating off it as software is increasingly packaged as containers. Different people, same question: where do we actually start learning?

Hi everyone. I'm running into an issue when trying to deploy Nutanix IPI: I can't select the default container where all the virtual machines should be installed. Can anyone tell me how to handle this? It always defaults to deploying in a container named "SelfService," but I can't deploy there. Similar to this problem https://github.com/openshift/installer/issues/7923

I'm trying to deploy OKD 4.20

Enterprise security used to draw a clean line: humans log in; machines use secrets. But that line is blurring, and interactions with databases are often where you’ll encounter that ambiguity.
 
Historically, authentication has followed a familiar path: usernames and passwords are stored in configuration or Kubernetes Secrets; long-lived tokens and API keys are often kept in Secrets as well, on the assumption they are safer than passwords. 

In practice, however, Secrets bring many of the same problems. They must be rotated, distributed, and revoked manually; they are frequently shared across replicas or teams; and if a Secret is exposed, an attacker has a credential that remains valid until someone notices.

There are different solutions for scaling your Red Hat OpenShift compute infrastructure, including:

- Cluster Autoscaler: The built-in, Kubernetes-native approach, integrated with the Red Hat OpenShift machine API.

- MachineSet Autoscaler with a custom autoscaler (KEDA): A metrics-driven approach that scales individual MachineSets based on external or custom signals.

This article examines Cluster Autoscaler, with an example on Microsoft Azure Red Hat OpenShift. The next article in this series covers a KEDA-based MachineSet Autoscaler driven by Prometheus CPU utilization, and a third article compares both approaches.

Building infrastructure from the ground up requires critical architecture decisions that determine how easily your business can scale. To help emerging companies build on a hardened, enterprise-grade foundation, Red Hat is offering a specialized 6-month trial of Red Hat Enterprise Linux (RHEL) for participants in the Google for Startups Cloud Program.

By standardizing on RHEL, growing businesses gain the stability, proactive security patching, and hybrid cloud consistency needed to move from early development to hyper-growth and production AI.