Terence Eden’s Blog

2026-05-05 11:34:12

RSS Feeds Send Me More Traffic Than Google

shkspr.mobi/blog/2026/05/rss-f…
Yeah yeah, I know, data-point of 1.

I recently read Susam's blog post where they said that "most of the traffic to my personal website still comes from web feeds" - I wondered if that was true for my site.

I've been writing this blog for a while. I've never much bothered with "aggressive" SEO - I have a fairly semantic layout, all my reviews have metadata, and stuff like that - but I'm not cramming in keywords, using AMP, or whatever other chickens Google requires to be sacrificed for a higher ranking. Nevertheless, I do OK.

Last year, I added a bit of local-only, lightweight statistics-gathering to my blog. I can see which sites people click on to reach mine. Google is right up the top, DuckDuckGo is surprisingly high, Bing is lucky to crack the top 20 on any day. Similarly, I can see how much traffic I get from the Fediverse and BlueSky (Twitter has all but vanished).

A few weeks ago I added RSS and Newsletter tracking. These data are very lossy. If someone is subscribed to my RSS feed and opens a post and their client downloads a lazy-loaded image at the end of the post, I get a hit. For email it's broadly the same. If an email is opened and the tracker image is loaded, I get a hit (although Gmail does obfuscate that somewhat).

I'm not looking for super-accurate numbers (although I do block as many AI crawlers and bots as possible). I'm not creepily following people around the web nor am I trying to sell them anything. I just want a rough idea of where people find me.

Here are my blog's views for the last 28 days.

Some months I get a surge of hits from link aggregators like HN or Reddit. Sometimes I'm linked to from a popular site or cited in academic work. But most of the time I bumble along getting hits from here, there, and everywhere. Nevertheless, it's lovely to see so many people choosing to subscribe⁰ (for free!) and astonishing that they provide more traffic than a major search engine.

Obviously, these are two very different types of traffic. People who are searching for a specific thing and stumble upon my blog are different from those who decide to like and subscribe.

But, yeah, about 25% of my traffic comes from people who have chosen to subscribe.

I'm just delighted that so many people read my random thoughts.

---

1. For historic reasons, I have separate Atom and RSS feeds. Perhaps I should consider merging them? But it doesn't take much effort to publish in two subtly different formats. ↩︎

#blog #blogging #meta #statistics

Citations

Sometimes people are kind enough to cite my works in their books, research papers, and reports. Here is an incomplete list: Table of Contents20092010201120122013201420152016201720182019202020212022202320242026Official PublicationsAcknowledgmentsTwee…

^{@edent (Terence Eden’s Blog)}

(in)sicurezza digitale

2026-05-05 08:44:50

La Corea del Nord ha rubato il 76% di tutte le criptovalute hackerate nel 2026: due attacchi, $577 milioni, e una macchina da guerra finanziata dal cyber

Si parla di:
Toggle

Con solo due attacchi portati a termine nel corso di quattro mesi, gli hacker nordcoreani hanno sottratto il 76% di tutti i fondi rubati in operazioni di hacking crypto nel 2026. Un dato che non è semplice statistica: è la prova di come la Corea del Nord abbia trasformato il furto di criptovalute in una macchina di finanziamento statale su scala industriale.

Il dato che cambia tutto: $577 milioni in due colpi

Secondo il report aggiornato di TRM Labs, nei primi quattro mesi del 2026 gli attori nordcoreani hanno sottratto $577 milioni in criptovalute attraverso appena due operazioni distinte: il colpo da $285 milioni contro Drift Protocol e quello da $292 milioni contro KelpDAO/LayerZero. La somma rappresenta il 76% di tutti i fondi rubati a livello globale nel settore crypto nello stesso periodo, e porta il totale attribuibile alla Corea del Nord dal 2017 a oltre $6 miliardi.

Questi numeri, da soli, raccontano una storia che va ben al di là del crimine informatico tradizionale. Il regime di Pyongyang ha costruito nel tempo un’infrastruttura offensiva sofisticatissima, capace di eseguire operazioni di ingegneria sociale protratte per mesi, sfruttare vulnerabilità architetturali in protocolli DeFi e riciclare rapidamente fondi attraverso mixer e bridge cross-chain.

L’operazione Drift: pazienza come arma principale

Il caso Drift Protocol è quello che meglio illustra l’evoluzione tattica dei gruppi nordcoreani. L’analisi on-chain effettuata dai ricercatori ha ricostruito che lo staging dell’attacco era iniziato l’11 marzo 2026 — settimane prima dell’esecuzione finale. Ma la parte più inquietante riguarda il vettore umano: secondo la ricostruzione, operatori nordcoreani si sono infiltrati nell’ecosistema Drift attraverso incontri di persona con dipendenti dell’exchange, costruendo relazioni di fiducia nel corso di mesi.

Il metodo ricorda l’attacco Bybit del 2025, quando il gruppo Lazarus riuscì ad accedere ai sistemi tramite un contractor di fiducia. La differenza è che nel caso Drift il social engineering si è spinto fino al contatto fisico diretto, segnalando una capacità operativa di intelligence umana (HUMINT) che va ben oltre il phishing tradizionale. Gli analisti hanno ipotizzato che gli operatori nordcoreani stiano ora integrando strumenti di intelligenza artificiale nei flussi di ricognizione e ingegneria sociale.

L’operazione KelpDAO: vulnerabilità architetturali nei bridge cross-chain

Il secondo attacco, da $292 milioni contro KelpDAO tramite un bridge LayerZero, segue una logica completamente diversa ma altrettanto raffinata. Gli attaccanti hanno identificato e sfruttato un design flaw nel modello a singolo verificatore del bridge cross-chain, che permetteva la manipolazione dei messaggi tra chain Ethereum e Arbitrum. Dopo aver drenato i fondi, il gruppo ha tentato di riciclare i proventi attraverso THORChain, sebbene circa $75 milioni siano stati congelati su Arbitrum grazie all’intervento tempestivo di Uniswap e altri protocolli.

L’attribuzione di questo secondo attacco è stata attribuita a un gruppo distinto dal Lazarus Group classico — indicando che la Corea del Nord mantiene più unità cyber parallele specializzate in diversi vettori di attacco, con una struttura organizzativa comparabile a quella di un’agenzia di intelligence statale.

Il quadro strategico: il crypto come motore del programma nucleare

Per comprendere la portata di queste operazioni è necessario inquadrarle nel contesto geopolitico. Le Nazioni Unite e diversi governi occidentali hanno più volte documentato come i fondi rubati dalla Corea del Nord finanzino direttamente il programma missilistico e nucleare del regime. Con il sistema bancario nordcoreano quasi completamente escluso dal sistema finanziario internazionale a causa delle sanzioni, il crimine crypto è diventato una delle principali fonti di valuta estera.

Il modello operativo si è raffinato nel tempo: nelle prime operazioni del Lazarus Group (2016-2019) si ricorreva principalmente a spear phishing contro exchange centralizzati. Dal 2020 in poi l’attenzione si è spostata progressivamente verso i protocolli DeFi — più difficili da congelare, con meno meccanismi di KYC/AML, e spesso caratterizzati da vulnerabilità architetturali nei contratti smart o nei bridge.

Tattiche, tecniche e indicatori di compromissione (TTPs)

I pattern ricorrenti nelle operazioni nordcoreane contro il settore crypto includono:

• Social engineering prolungato: infiltrazione nelle community, creazione di identità false su LinkedIn e GitHub, costruzione di relazioni di fiducia per mesi prima dell’attacco.
• Targeting dei bridge cross-chain: sfruttamento di vulnerabilità nei protocolli di interoperabilità, spesso caratterizzati da minore maturità di sicurezza rispetto ai layer base.
• Riciclaggio tramite THORChain e mixer: uso di protocolli decentralizzati per frammentare e offuscare il trail on-chain dei fondi rubati.
• Insider threat via contractor: inserimento di operatori nordcoreani travestiti da sviluppatori o consulenti all’interno di team crypto legittimi.

Due parole per i difensori

Per i protocolli DeFi e gli exchange crypto, la minaccia nordcoreana richiede una risposta che vada oltre i controlli tecnici tradizionali. Il vettore umano è oggi il punto di ingresso primario: ogni processo di hiring di sviluppatori e contractor dovrebbe includere verifiche rafforzate dell’identità, con particolare attenzione ai profili che non possono essere verificati fisicamente o che mostrano pattern comportamentali anomali (riluttanza ai video call, timezone inconsistenti con la localizzazione dichiarata).

Sul fronte tecnico, la priorità dovrebbe essere la revisione dei modelli di fiducia nei bridge cross-chain: la dipendenza da un singolo verificatore o da un set ristretto di validatori crea un single point of failure che gli attaccanti sanno come sfruttare. I programmi di bug bounty con scope allargato ai bridge e ai contratti di interoperabilità sono diventati una necessità, non un’opzione.

Infine, la coordinazione con le agenzie di intelligence e i partner di blockchain analytics (TRM Labs, Chainalysis, Elliptic) al momento della scoperta di un’anomalia può fare la differenza tra il recupero parziale dei fondi e la perdita totale — come dimostra il congelamento di $75 milioni su Arbitrum nel caso KelpDAO.

Spcnet.it

2026-05-05 08:46:50

Jenkins Secret Guard Plugin: blocca i segreti hardcoded nelle pipeline CI/CD

I segreti hardcoded nelle pipeline Jenkins sono uno dei problemi di sicurezza più sottovalutati nell’ecosistema CI/CD. Token API incollati direttamente in un campo di configurazione durante un test rapido, URL di webhook con query parameter segreti rimasti nel config.xml, header di autorizzazione in Jenkinsfile scritti una volta e mai più rivisti: situazioni ordinarie che, però, aprono falle di sicurezza concrete e difficili da intercettare manualmente.

Il nuovo Secret Guard Plugin per Jenkins è stato creato esattamente per risolvere questo problema: un plugin focalizzato, deterministico e pronto per ambienti di produzione che analizza le configurazioni Jenkins e le Pipeline alla ricerca di pattern ad alto rischio di esposizione di segreti.

Cosa analizza Secret Guard

Il plugin esamina le posizioni più comuni dove i segreti finiscono per errore:

• File config.xml dei job
• Script Pipeline inline
• Jenkinsfile recuperati da SCM (quando è disponibile l’accesso SCM leggero)
• Valori di default dei parametri
• Definizioni di variabili d’ambiente
• Contenuto di comandi come sh, bat, powershell e chiamate HTTP

L’approccio è intenzionalmente stretto nel perimetro: Secret Guard non cerca di essere uno strumento di governance generalista né un analizzatore di qualità del codice. Si concentra su pattern ad alta confidenza e ben documentati, riducendo il rumore prodotto da euristiche troppo aggressive.

Un esempio pratico

Il caso più frequente è una Pipeline che incorpora un token direttamente in una variabile d’ambiente o in un header HTTP. Ecco un Jenkinsfile problematico:

pipeline {
    agent any
    environment {
        API_TOKEN = 'ghp_012345678901234567890123456789012345'
    }
    stages {
        stage('Call API') {
            steps {
                sh "curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.abc123456789' https://api.example.com"
            }
        }
    }
}

Una volta che questo segreto è memorizzato nella configurazione del job, diventa difficile da ruotare e facile da esporre tramite export, backup, log o screenshot. Secret Guard rileva questi pattern prima che diventino un problema.

Il pattern corretto prevede di archiviare il segreto nelle Jenkins Credentials e iniettarlo solo a runtime:

pipeline {
    agent any
    stages {
        stage('Call API') {
            steps {
                withCredentials([string(credentialsId: 'api-token', variable: 'API_TOKEN')]) {
                    sh 'curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com'
                }
            }
        }
    }
}

Con questo approccio, il valore del token non compare mai nel codice sorgente né nella configurazione del job: viene risolto da Jenkins solo al momento dell’esecuzione e mascherato automaticamente nei log.

Modalità di utilizzo

Secret Guard può essere usato in diversi contesti pratici:

• Enforcement al salvataggio: blocca o segnala configurazioni di job che introducono segreti hardcoded nel momento in cui vengono salvate
• Scansione a runtime: analizza la Pipeline durante l’esecuzione del build
• Scan a livello di job: tramite l’azione “Scan Now” disponibile sulla pagina del job
• Scan globale: la pagina amministrativa “Secret Guard” permette di analizzare tutti i job con un solo click

I risultati vengono archiviati in forma mascherata: gli amministratori possono esaminare i findings senza che i valori raw vengano persistiti nei report del plugin.

Tre livelli di enforcement

Per consentire un’adozione graduale, il plugin supporta tre modalità configurabili:

• AUDIT: registra i findings senza bloccare nulla, ideale come punto di partenza per capire la situazione attuale
• WARN: l’operazione viene completata ma il rischio viene segnalato esplicitamente
• BLOCK: impedisce il salvataggio o l’esecuzione quando vengono trovati findings non esentati al di sopra della soglia configurata

Questa progressione permette di partire con la visibilità (AUDIT) e spostarsi verso un enforcement più rigoroso man mano che i team sanano i problemi esistenti.

Installazione

Il plugin è disponibile nel Jenkins Plugin Manager con il nome secret-guard. L’installazione è standard: Manage Jenkins → Plugins → Available plugins → cerca “Secret Guard”. Dopo il riavvio, la pagina “Secret Guard” apparirà nel menu di amministrazione globale.

Conclusione

Secret Guard colma un gap reale nelle pipeline Jenkins: la mancanza di uno strumento specifico, leggero e a basso rumore per intercettare i segreti hardcoded prima che finiscano in backup, log o nelle mani sbagliate. L’approccio deterministico — in contrapposizione all’inferenza AI o alle euristiche generiche — lo rende particolarmente adatto agli ambienti di produzione dove la prevedibilità del comportamento è critica.

Per team che già usano Jenkins in modo intensivo, introdurlo in modalità AUDIT per qualche settimana prima di passare a WARN o BLOCK è la strategia più sicura per ottenere subito visibilità senza interrompere i workflow esistenti.

Fonte: Introducing the Secret Guard Plugin – Jenkins Blog

Introducing the Secret Guard Plugin

A Jenkins plugin that checks Jenkins job configuration and Pipeline definitions for hardcoded secret leakage risks.

^{Introducing the Secret Guard Plugin}

Spcnet.it

2026-05-05 08:48:09

Gemma 4 con Ollama e .NET Aspire: LLM in locale con il visualizzatore GenAI completo

Se hai già usato l’integrazione Azure Foundry o Azure OpenAI in .NET Aspire, conosci già quella funzionalità: il visualizzatore GenAI che mostra le conversazioni con il modello all’interno del dashboard di tracing. Fai clic su una traccia, scorri fino alla chiamata LLM, e appare una piccola icona “sparkles”. Cliccandola, si apre un pannello con il log completo: system prompt, messaggio utente, risposta del modello, tool call, conteggio token e finish reason.

A prima vista sembra una funzionalità esclusiva di Azure Foundry. Non lo è. Il dashboard Aspire non controlla se gen_ai.system == "openai" né fa chiamate ad Azure. Si basa sulle OpenTelemetry GenAI semantic conventions: qualsiasi backend che emette span gen_ai.* con la forma corretta ottiene lo stesso trattamento. Ollama, LM Studio, llama.cpp — se espone un’API compatibile con OpenAI Chat Completions, può illuminare lo stesso popup.

Questo articolo mostra come configurare Ollama con il modello Gemma 4 in locale e ottenere il visualizzatore GenAI completo nel dashboard Aspire, senza Azure e senza costi cloud.

Perché eseguire LLM in locale?

I motivi sono diversi a seconda del contesto:

• Compliance e data privacy: i dati non escono dall’infrastruttura aziendale.
• Costi prevedibili: niente fatture cloud che raddoppiano durante i picchi di sviluppo AI.
• Sviluppo offline: il modello funziona anche senza connessione Internet.
• Iterazione rapida: nessun rate limit durante i test intensivi.

Il meccanismo: OpenTelemetry GenAI conventions

Il dashboard Aspire renderizza il visualizzatore GenAI quando trova span con questi attributi OpenTelemetry:

• gen_ai.operation.name (es. chat, embedding)
• gen_ai.request.model — il modello richiesto
• gen_ai.response.model — il modello che ha risposto
• gen_ai.input.messages — il prompt, serializzato in JSON
• gen_ai.output.messages — la risposta, serializzata in JSON
• gen_ai.usage.input_tokens / gen_ai.usage.output_tokens
• gen_ai.response.finish_reasons

Quando uno span con questi attributi appare nella vista traces sull’activity source Experimental.Microsoft.Extensions.AI, il dashboard aggiunge l’icona sparkles e mostra il popup.

IChatClient è l’astrazione di Microsoft.Extensions.AI per qualsiasi cosa a cui si possano inviare messaggi chat. Azure OpenAI, Ollama e i modelli locali la implementano direttamente o si adattano ad essa. Il wrapper OpenTelemetry che ci interessa sa solo come tracciare oggetti con la forma di IChatClient.

Le quattro cose da configurare

Per ottenere il visualizzatore GenAI con un modello locale servono esattamente quattro elementi:

1. Un’integrazione di hosting che esegue il backend del modello come risorsa Aspire e produce una connection string.
2. Un IChatClient nel servizio consumer, decorato con UseOpenTelemetry() e content capture abilitato.
3. La registrazione della sorgente di tracing in ServiceDefaults per far fluire gli span GenAI nel tracer provider.
4. Il toggle di content capture, tramite variabile d’ambiente o via UseOpenTelemetry. Senza di esso il popup appare ma i messaggi sono vuoti.

Mancarne anche solo uno produce output silenziosamente degradato: senza il punto 3 gli span non escono dal processo; senza il punto 4 il popup è vuoto; senza il punto 2 si ottengono solo span HTTP generici.

1. Integrazione hosting: Ollama come risorsa Aspire

Aspire non include un’integrazione Ollama out of the box. Il Community Toolkit ne ha una, ma costruirla da zero mostra il pattern applicabile a qualsiasi backend OpenAI-compatible.

In una nuova class library referenziata dall’AppHost (con il package Aspire.Hosting):

public sealed class OllamaResource(string name)
    : ContainerResource(name), IResourceWithConnectionString
{
    internal const string PrimaryEndpointName = "http";
    private EndpointReference? _primaryEndpoint;

    public EndpointReference PrimaryEndpoint =>
        _primaryEndpoint ??= new EndpointReference(this, PrimaryEndpointName);

    public ReferenceExpression ConnectionStringExpression =>
        ReferenceExpression.Create(
            $"Endpoint={PrimaryEndpoint.Property(EndpointProperty.Url)}");
}

public static class OllamaResourceBuilderExtensions
{
    public static IResourceBuilder<OllamaResource> AddOllama(
        this IDistributedApplicationBuilder builder,
        string name,
        int? port = null)
    {
        var resource = new OllamaResource(name);
        return builder.AddResource(resource)
            .WithImage("ollama/ollama", "latest")
            .WithHttpEndpoint(port: port ?? 11434, targetPort: 11434, 
                             name: OllamaResource.PrimaryEndpointName)
            .WithVolume("ollama-data", "/root/.ollama");
    }
}

Nell’AppHost si aggiunge la risorsa Ollama e si collega al servizio che la usa:

var ollama = builder.AddOllama("ollama")
    .WithModel("gemma4:e2b");

var api = builder.AddProject<Projects.ScrumSummary_Api>("api")
    .WithReference(ollama)
    .WaitFor(ollama);

2. IChatClient con OpenTelemetry nel servizio consumer

Nel servizio che usa il modello, si registra il client con la catena di decoratori corretta:

builder.Services.AddSingleton(sp =>
{
    var connectionString = builder.Configuration.GetConnectionString("ollama")!;
    var endpoint = new Uri(connectionString.Replace("Endpoint=", ""));

    return new OllamaApiClient(endpoint)
        .AsChatClient("gemma4:e2b")
        .AsBuilder()
        .UseOpenTelemetry(configure: options =>
        {
            // Abilita la cattura del contenuto dei messaggi
            options.EnableSensitiveData = true;
        })
        .Build();
});

Il flag EnableSensitiveData = true è il toggle critico. Senza di esso, il popup nel dashboard compare ma non mostra i messaggi (per motivi di privacy è disabilitato di default).

3. Registrazione della sorgente di tracing in ServiceDefaults

Nel progetto ServiceDefaults, aggiungere la sorgente activity di Microsoft.Extensions.AI:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            // Questa è la riga chiave
            .AddSource("Experimental.Microsoft.Extensions.AI");
    });

Senza questa riga gli span GenAI vengono emessi ma non raggiungono l’exporter e non appaiono nel dashboard.

4. Alternative al flag EnableSensitiveData

In ambienti dove non si vuole abilitare il flag nel codice (ad esempio per motivi di compliance), si può usare la variabile d’ambiente:

DOTNET_EXTENSIONS_AI_TELEMETRY_ENABLE_SENSITIVE_DATA=true

Oppure impostarla nell’AppHost solo per i progetti in development:

var api = builder.AddProject<Projects.ScrumSummary_Api>("api")
    .WithReference(ollama)
    .WithEnvironment("DOTNET_EXTENSIONS_AI_TELEMETRY_ENABLE_SENSITIVE_DATA", "true");

Il risultato nel dashboard

Una volta configurati tutti e quattro gli elementi, ogni chiamata al modello Ollama locale appare nelle traces di Aspire come span GenAI. Cliccando sull’icona sparkles si apre il pannello con il log completo della conversazione: system prompt, messaggi utente, risposta del modello con i token usati e il finish reason — esattamente come con Azure OpenAI o Azure Foundry, ma con il modello che gira sulla propria macchina.

Generalizzare ad altri backend

Il pattern si applica a qualsiasi backend compatibile con l’API OpenAI Chat Completions: LM Studio, llama.cpp con server HTTP, vLLM. L’unico requisito è che il client implementi o si adatti a IChatClient e che il wrapper UseOpenTelemetry() venga applicato. Il resto — la registrazione del tracing, il flag di content capture — rimane identico.

Conclusione

Il visualizzatore GenAI di .NET Aspire non è un’esclusiva di Azure. È un’interfaccia costruita sopra gli standard OpenTelemetry, accessibile a chiunque emetta gli span corretti. Quattro configurazioni, nessun servizio cloud obbligatorio, e si ottiene la stessa esperienza di debugging degli LLM che si avrebbe con Azure Foundry — con Gemma 4, Ollama e tutto in locale.

Fonte: Run Gemma 4 with Ollama locally, and keep the Aspire LLM Insights (sparkles and all) — Erik Lieben

Run Gemma 4 with Ollama locally, and keep the Aspire LLM Insights (sparkles and all)

Can't use Microsoft Foundry because of compliance or an Azure bill that doubles during an AI development spike, but still want the best AI debugging experience in Aspire? Here's how to keep the full GenAI chat-log sparkles while Ollama and Gemma 4 ru…

^{Erik Lieben}

Spcnet.it

2026-05-05 08:48:42

Fine del supporto NGINX Ingress su AKS: guida alla migrazione verso Gateway API

Se gestisci workload su Azure Kubernetes Service (AKS), nelle ultime settimane potresti aver ricevuto un’email da Microsoft che annuncia la fine del supporto per NGINX Ingress su AKS entro novembre 2026. Non si tratta di una comunicazione da ignorare: la migrazione è inevitabile e conviene pianificarla per tempo. In questo articolo vediamo cosa sta succedendo, perché è successo e cosa fare concretamente.

Il contesto: perché Ingress è diventato obsoleto

La risorsa Ingress di Kubernetes nasce con una specifica intenzionalmente minimale: regole di host e path, niente di più. Ma i load balancer cloud (AWS, Azure, GCP e altri) sono in grado di fare molto di più — timeout configurabili, retry policy, routing per header, circuit breaker — e gli utenti hanno cercato di esprimere queste funzionalità tramite annotation proprietarie sulle risorse Ingress. Il risultato è stato un’esplosione di annotation non standardizzate, specifiche per ogni controller, che rendono ogni configurazione di Ingress portabile solo sulla carta.

Gateway API è la risposta della community a questo problema. Sostituisce Ingress con risorse strutturate e tipizzate — HTTPRoute, Gateway, GatewayClass — capaci di esprimere comportamenti di routing avanzati in modo nativo e standardizzato, con una separazione netta tra il ruolo del platform team (che gestisce i Gateway) e il ruolo del team applicativo (che gestisce le HTTPRoute). Gateway API è stabile dalla versione 1.28 di Kubernetes ed è la direzione verso cui si sta muovendo l’intero ecosistema.

La fine di ingress-nginx e le conseguenze su AKS

Il progetto upstream ingress-nginx — il controller Ingress più diffuso nell’ecosistema Kubernetes — è stato formalmente ritirato a marzo 2026. Il progetto era mantenuto da un esiguo gruppo di volontari, aveva accumulato debito tecnico significativo e presentava vulnerabilità di sicurezza note rimaste senza patch. Con il ritiro, qualsiasi nuova vulnerabilità scoperta rimarrà indefinitamente senza correzione.

Microsoft ha fissato la propria data di fine supporto al novembre 2026, concedendo agli utenti AKS un margine aggiuntivo. Fino ad allora, le vulnerabilità critiche continueranno a essere corrette, ma non ci sarà sviluppo di nuove funzionalità.

Chi è impattato e con quale urgenza

Installazione self-managed via Helm

Se hai installato ingress-nginx manualmente tramite Helm, sei esposto direttamente al ritiro upstream avvenuto a marzo 2026. Da quel momento, qualsiasi vulnerabilità nel controller resta senza patch: mantenerlo in produzione è un rischio di sicurezza crescente nel tempo.

AKS Application Routing add-on

Se usi l’add-on gestito di AKS abilitato con --enable-app-routing, hai tempo fino a novembre 2026. Microsoft garantisce patch per le vulnerabilità critiche fino a quella data. È un margine utile, ma non è una soluzione permanente.

Altro controller Ingress (Traefik, Istio, HAProxy…)

Se non usi NGINX Ingress, questo annuncio non ti impatta direttamente. Vale però la pena iniziare a familiarizzare con Gateway API, che è la direzione dell’intero ecosistema Kubernetes.

Gateway API: il nuovo modello di risorse

La migrazione da Ingress a Gateway API cambia il modello di risorse con cui si lavora. Ecco un confronto diretto tra i due approcci.

Una configurazione Ingress tipica con annotation NGINX:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-api
            port:
              number: 80

La configurazione equivalente con Gateway API:

# Definito dal platform team (una volta sola)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: gateway-system
spec:
  gatewayClassName: azure-application-lb
  listeners:
  - name: http
    port: 80
    protocol: HTTP
---
# Definito dal team applicativo
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: gateway-system
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-api
      port: 80

Il vantaggio principale non è solo sintattico: la separazione tra Gateway e HTTPRoute permette al platform team di gestire centralmente le policy di sicurezza, TLS e throttling, mentre i team applicativi possono modificare le route senza toccare l’infrastruttura condivisa.

Piano di migrazione consigliato

Microsoft sta investendo nel supporto nativo di Gateway API nell’add-on Application Routing di AKS, con Azure Application Gateway for Containers (AGC) come backend raccomandato. I passi pratici per avviare la migrazione sono:

1. Inventario: esegui kubectl get ingress -A -o yaml per elencare tutte le risorse Ingress e mappare le annotation nginx in uso nel cluster.
2. Assessment delle annotation: identifica quali annotation hanno un equivalente nativo in Gateway API (la maggior parte) e quali richiedono configurazioni alternative (timeout avanzati, snippet custom).
3. Ambiente di test: crea un cluster AKS di test con Gateway API abilitato e migra prima i workload meno critici per acquisire familiarità con il nuovo modello.
4. Migrazione progressiva: usa la funzionalità di traffic splitting di HTTPRoute per spostare gradualmente il traffico dai vecchi Ingress alle nuove route, validando il comportamento prima di dismettere il vecchio controller.
5. Cleanup: rimuovi le risorse Ingress e disabilita o disinstalla ingress-nginx una volta completata la validazione su tutti gli ambienti.

Conclusione

La fine di NGINX Ingress su AKS era prevedibile da quando il progetto upstream ha iniziato a mostrare segni di abbandono. La buona notizia è che Gateway API è tecnicamente superiore: più espressiva, più portabile, con una governance delle responsabilità più chiara tra platform team e team applicativi. Chi pianifica la migrazione adesso, con il margine di tempo concesso da Microsoft fino a novembre 2026, può affrontarla con calma. Chi aspetta l’ultimo momento si troverà a gestire una migrazione d’emergenza in un contesto di sicurezza degradante.

La documentazione ufficiale di Gateway API è disponibile su gateway-api.sigs.k8s.io. La roadmap di AKS per Gateway API è tracciabile nelle release note del servizio Azure.

Fonte: The End of NGINX Ingress on AKS: What You Need to Know – Trailhead Technology

The End of NGINX Ingress on AKS: What You Need to Know - Trailhead Technology Partners

Learn about the retiring of NGINX Ingress support coming to AKS in November 2026, what triggered it, and what your migration path looks like.

^{Piotr Kolodziej (Trailhead Technology Partners)}