April 2026 briefing: Kubernetes 1.36 hardens the platform, open models get a real licence, and FHIR reaches prior authorisation

The month in one paragraph

Kubernetes v1.36 shipped on 22 April with 70 enhancements, 18 of them graduating to stable¹, and the headline graduations were security ones: user namespaces and fine-grained kubelet authorisation²³. Gateway API v1.5 moved six features to its stable channel⁴. Google released Gemma 4 under Apache 2.0⁵, Anthropic released Claude Opus 4.7⁶, MCP expanded its maintainer team⁷, OpenTelemetry formally deprecated OpenTracing compatibility⁸, and CMS proposed FHIR standards for prior authorisation¹⁰.

Kubernetes 1.36: the security defaults grew up

Two graduations stood out to me. The first is user namespaces. The post puts the problem plainly: a process running as root inside a container is seen by the kernel as root on the host, so a container escape lands an attacker as root². With hostUsers: false the container's root is mapped to an unprivileged range on the host, and capabilities such as CAP_NET_ADMIN become namespaced. The enabling work was in the kernel: ID-mapped mounts remove the expensive recursive chown that used to make this impractical for large volumes.

The second is fine-grained kubelet API authorisation. Before it, almost every kubelet API path mapped to nodes/proxy, the same permission that allows running commands in any container on the node³. The post also notes research from early 2026 showing that even nodes/proxy GET could be abused through WebSocket upgrades. In plain terms, many clusters have handed node-level superuser rights to their monitoring agents. That is now avoidable.

The release also permanently disabled the gitRepo volume driver and deprecated Service externalIPs, with removal planned for v1.43¹. Both are long-known security liabilities.

Gateway API v1.5: ingress for more than one team

Gateway API v1.5 promoted six features to its standard channel, including ListenerSet, TLSRoute, the HTTPRoute CORS filter and client certificate validation⁴. ListenerSet is the one I care about. Previously every listener lived on the Gateway object itself, so platform and application teams had to coordinate changes to the same resource. ListenerSet lets application teams attach their own listeners from their own namespaces.

The project also moved to a release-train model, where features that are ready (including their documentation) ship at feature freeze. With Ingress NGINX retired in March and no longer receiving security fixes¹, the migration path to Gateway API is now both available and urgent.

Models: an open licence that legal teams can sign

Google released Gemma 4, describing it as the first Gemma family under the OSI-approved Apache 2.0 licence⁵. For the work I do with regulated clients, the licence matters more than the benchmark tables. Custom model licences slow every procurement review. An Apache 2.0 model can go through the same process as any other open-source dependency, which makes private, self-hosted deployments far easier to approve. It is exactly the class of model I have been testing on my own hardware, which I wrote about in my notes on private LLMs.

At the hosted end, Anthropic released Claude Opus 4.7 on 16 April, positioned for complex reasoning, agentic coding and long-running tasks, with a new effort level and task budgets for controlling token use in agent loops⁶. Budget controls like that are the kind of feature that moves agents from demo to production, because cost per task becomes something you can cap rather than discover.

Agents and observability

MCP expanded its governance team, adding a new Lead Maintainer whose work centres on authorisation and security, and a new Core Maintainer from agent developer tooling⁷. Governance news rarely gets attention, but for a protocol that enterprises are wiring into production systems, who maintains the security model matters.

On the observability side, OpenTelemetry deprecated the OpenTracing compatibility requirements in its specification⁸. Existing shims keep working for now, but new work should target native OpenTelemetry APIs and OTLP. Separately, OpenTelemetry eBPF Instrumentation v0.7.0 added HTTP header enrichment, so spans can carry request context such as a tenant ID through a configuration change, without redeploying applications⁹. For multi-tenant platforms, "which customer is affected?" is usually the first question in an incident.

Healthcare: FHIR reaches prior authorisation

A CMS fact sheet dated 10 April describes a proposed rule in which HHS would adopt HL7 FHIR standards for prior authorisation transactions under HIPAA's administrative simplification provisions, and require payers to report their interoperability API endpoints¹⁰. It is a proposal, not a final rule, but the direction is consistent: FHIR is becoming the transaction layer across US healthcare, not only the patient-access layer.

My view, from working with OMOP and the OHDSI tools: FHIR for exchange and OMOP for analysis remain complementary. More FHIR transactions mean more structured data arriving, and you still need a standardised analytical model to do research and AI on it. I set out that architecture in FHIR to OMOP.

What I'd do with this

1. Audit who holds nodes/proxy. Once on v1.36, move monitoring and logging agents to the fine-grained permissions and remove the broad grant.
2. Pilot hostUsers: false on stateless workloads first, then on anything that handles untrusted input.
3. Plan the Ingress NGINX exit to Gateway API, using ListenerSet to give teams their own listeners.
4. Add an Apache-licensed model to your private AI shortlist, and test it against your own evaluation set rather than public leaderboards.
5. If you handle US payer data, start mapping prior authorisation flows to FHIR now rather than waiting for a final rule.

How I can help

I help teams turn months like this into a short list of decisions: platform hardening, private model strategy and healthcare data architecture. See my AI architecture and healthcare data work, or analyse your challenge and bring the result to a call.