Why Nyx

Understanding Nyx A plain-language guide

For anyone whose starting point is “our applications run on Kubernetes.” No Kubernetes expertise assumed.

The situation nobody chose

If your organisation runs applications on Kubernetes — and most now do — those applications live together on shared infrastructure: dozens or hundreds of services, running side by side on the same fleet of Linux and Windows servers.

Here is the part that surprises people outside the platform team: in many Kubernetes environments, unless additional controls are deliberately configured, workloads can initiate connections broadly — to other applications, to internal services, and to external destinations. The public-facing website may be able to open a connection directly to the payments database. A reporting job may be able to send data to any address on the internet. Nothing blocks it, nothing records it as unusual, and nothing alerts anyone.

Nobody decided this. It is simply what remains when no other decision is made — and because broad connectivity doesn't cause an error, it can stay unnoticed until someone deliberately maps it: during a security review, a segmentation project, or an incident.

Why attackers care about this more than you do

Modern attacks on this kind of infrastructure follow a well-worn sequence:

  1. Get in anywhere. A vulnerable library, a leaked credential, a compromised third-party component. Over a long enough time, some application will be compromised — security teams plan on this assumption (“assume breach”).
  2. Move sideways. From that first foothold, reach the things that matter: databases, credential stores, other applications. This is lateral movement, and in an unrestricted environment, one compromised application can reach nearly everything.
  3. Take something out. Send data to an outside server the attacker controls. This is exfiltration, and it needs an outbound connection that nobody is watching.

The initial break-in is very hard to prevent entirely. Steps 2 and 3 are different: they depend completely on the network allowing connections that were never needed in the first place. That is the gap.

Two things have made this urgent rather than theoretical. Attacks have become fast — AI-assisted tooling chains these steps in minutes or hours, not weeks, so “we'll catch it during the investigation” no longer holds. And the fallback response — shutting systems down until the danger passes — means halting the business itself.

The fix: only allow what actually needs to talk

The discipline that closes the gap is called network microsegmentation — least privilege, applied to how applications communicate. The shift is in the question you start with. Instead of asking “what should we block?”, you ask:

What does this application actually need to communicate with?
Kubernetes traffic without segmentation versus with least-privilege segmentationLeft: a compromised pod reaches the API, database, credential store, other workloads and an attacker-controlled destination. Right: the same compromised pod keeps only the paths it was always meant to have — the API, its database and the payment provider; the paths to the credential store, other workloads and the attacker-controlled destination are cut. API DB Workloads Creds Attacker- controlled pod API DB Payment provider Creds Workloads Attacker- controlled pod segmentation Without With least-privilege segmentation
Left: nothing was configured, so the compromised pod reaches the database, the credential store, other workloads — and out to an attacker-controlled destination. Right: the same break-in, against least-privilege segmentation. The pod keeps only the paths it was always meant to have — the API, its database, and the payment provider as the one allowed outbound destination. Everything else is cut.

The website may need to reach the product API. The API may need its database. The payment service may need the payment provider. Those connections are allowed — and connections that were never required are not.

Under this model, a compromised application can reach only the handful of things it was always meant to reach. Lateral movement hits a wall. Exfiltration to an attacker's server is blocked because that destination was never on the list. The break-in still happened — but it is contained, and contained incidents are the difference between a bad day and a shutdown.

This is not a new or exotic idea; it is least-privilege applied to the network, and auditors increasingly expect it. The reason most organisations still don't have it is practical: with traditional tooling it is genuinely hard to see what the traffic map even looks like, hard to write the rules without breaking things, and hard to prove afterwards that the rules are working. Tools have been bought for this and never fully rolled out — not because the idea failed, but because operating them was too hard.

Writing policy is relatively easy. Knowing what the policy should be is harder — and so is living with it afterwards. That is the gap Nyx is built for.

What Nyx is

Nyx makes microsegmentation something a team can actually see, apply, and live with. It is a security and observability layer for Kubernetes that works in three connected ways:

It sees everything.

Nyx watches network traffic at the deepest level of the operating system — the kernel — on every server in the cluster. Crucially, it does this on both Linux and Windows servers with equal capability, which matters because many enterprises run substantial Windows workloads and almost no security tooling treats them as first-class. Nothing needs to be added to or changed in the applications themselves. The result is a live map: what is talking to what, right now, including which outside services each application contacts — by name, not just by network address.

It enforces the rules.

From the observed traffic, Nyx pre-fills the allow-rules each application needs — the team reviews and applies them rather than writing them from scratch. Once applied, anything outside the rules is blocked at the kernel, on Linux and Windows alike. Outbound control works by destination name (for example, “this service may reach the payment provider's API and nothing else”), which holds even when the addresses behind those names change.

It flags and explains the unusual.

Nyx learns each part of the environment's normal rhythm and raises an alert when behaviour deviates — including the classic warning sign of an application contacting an outside destination it has never talked to before. Detection is statistical; alongside each alert, AI generates a plain-language explanation of what happened and where to look, and anyone can ask questions of the live environment in plain English (“is anything reaching the internet that shouldn't be?”) and get an answer in seconds.

What this means in practice

  • A breach in one application stays in one application. The blast radius of an incident becomes a design choice rather than an accident.
  • Data can't quietly leave. Outbound connections are controlled by destination name and watched for anything new.
  • The environment becomes explainable. For an auditor, a security review, or a 2am incident, “what can reach what, and what actually happened” has a fast, evidence-backed answer.
  • The Windows estate is covered too — with the same rules and the same visibility as Linux, not an asterisk.
  • Humans stay in control. Nyx observes, recommends, and explains; what gets enforced is always an explicit, reviewable team decision.
  • Adopting it doesn't mean re-engineering anything. Nyx installs alongside the platform's existing networking in one step, and applications are untouched.

Seeing is faster than reading.

Nyx has a live demo environment — a real cluster with real traffic, open to anyone, nothing to install and no signup: orbit.tracenyx.ai

It includes short guided walkthroughs: investigating an application that contacted an unknown destination, diagnosing a failure whose error logs pointed at the wrong cause, and asking the environment questions in plain English.

Try the live demo Talk to us