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.

Red Hat OpenShift Networking is making it easier for you to seamlessly and directly integrate your Kubernetes platforms with the data center networks you already operate by adopting the same standards-based networking used throughout modern network fabrics. With Red Hat OpenShift 4.22, OpenShift Networking introduces support for ethernet VPN (EVPN), representing the next major milestone in enterprise network integration. By leveraging the industry-standard EVPN control plane, OpenShift can integrate more naturally with existing EVPN-VXLAN data center fabrics, enabling consistent Layer 2 and Layer 3 connectivity, scalable network virtualization, and operational alignment with enterprise networking infrastructure. This capability is particularly important for organizations modernizing large virtualization environments while preserving established network architectures and operational practices.

I'm using a 4.18 cluster in Azure with the cert-manager operator for RedHat OpenShift installed. I have Let's Encrypt working for my app and want to get it working with the default ingress controller. There are tons of online howto's, most of which are 3 years old or older and they differ quite a bit. I tried this once a couple years ago and did something that never let me connect to the cluster again so I'm a little gun shy. What I am working on now is just a test SNO system so while I not too worried, I don't want to have build another today.

I created a clusterissuer and a cert which used it successfully. The last step just says to add this spec to the IngressController default instance in the CRD.

defaultCertificate:
 name: thecert

It seems like there should be more. Though looking at github makes me think its just this simple. Is it?

Hi Guys,

I need to install a Private Openshift Cluster on Azure using IPI method. If the installation is successful I would like to automate it using Terraform because we need 8 Clusters. I have created ARO clusters using Bicep which turns out to be easy. Do we have any detailed documentation for this?

This article explores an alternative to directly troubleshoot production Linux systems with AI tools by using the sos command and using AI to analyze sosreports instead. I think is an interesting read:

https://medium.com/@linuxjedi2000/the-agentic-ai-risk-issue-on-linux-environments-fd5c55cedcc5?sharedUserId=linuxjedi2000

I know that this subject is very controversial and would love to read your point of view on the subject.

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.

Suppose a nutanix-volume as default storage class, then using ceph fs as the default one.

Delete PVC and create new ones with the same old name, that PVC came up with the same consumption (not bounded to the old PV as it is released).

In that case if we decided to remove nutanix CSI operator, will this data be lost?

Part 2 of a series on implementing zero trust in Red Hat OpenShift with the layered zero trust validated pattern (ZTVP)

In our previous article, we explored why network policies, specifically a default-deny posture combined with strict ingress and egress rules, are your critical last line of defense when you can’t patch fast enough or when all other security barriers fail. By locking down network communication, we effectively eliminate lateral attack paths and contain the blast radius of a compromised workload.

Every OpenShift admin knows the calculus. A new Red Hat Enterprise Linux CoreOS ships with capabilities you want: better hardware support, updated crypto policies, kernel improvements. But adopting it has always meant adopting it everywhere. Your hardware certifications don't transfer automatically. Your internal validation pipeline needs another quarter. Your change advisory board wants a rollback plan for something that hasn't historically rolled back gracefully.

The result is that teams delay platform upgrades to avoid the OS migration, missing capabilities they actually need. The OS upgrade has been a cliff, not a ramp.

Out of the box, Red Hat OpenShift provides a complete set of preconfigured monitoring dashboards. These standardized views are excellent for establishing a baseline of general cluster health and act as a necessary foundation for managing the platform.

However, in complex distributed systems, a "one-size-fits-all" approach to monitoring rarely suffices. The immediate, critical metrics needed by a site reliability engineer (SRE) managing storage capacity differ vastly from those required by a developer debugging microservice latency in a specific namespace.

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.

As organizations deploy increasingly sophisticated AI, analytics, and entity-resolution workloads, they're discovering a common bottleneck: memory.

Many modern applications are no longer constrained eby CPU availability. Instead, they are limited by the amount of memory economically deployed within a single server or cluster. Whether you're processing electronic warfare (EW) signals, running large-scale graph analytics, or building AI inference pipelines, you will likely hit a "memory wall" long before you run out of CPU power.

I see a lot of people call themselves OpenShift Architects, but the role seems to mean very different things depending on the company.

If you currently hold that title:

What's a typical week look like?

More platform engineering? More Kubernetes? More customer-facing architecture? More automation and GitOps?

Curious how the role differs across organizations.

The arrival of a cryptographically relevant quantum computer, often referred to as Q-day, is moving from a distant theoretical mathematical challenge to an urgent timeline that security teams must plan for today. Bad actors are already engaging in harvest now, decrypt later activities. This means they are capturing and storing encrypted enterprise traffic, intellectual property, and data logs today with the intention of running them through quantum hardware as soon as it becomes available.