Integration Patterns

This page shows how Kernloom fits into real environments. Each pattern combines one or more of its three mechanisms — progressive enforcement, graph-based path control, and anomaly detection — to solve a specific protection problem.

All patterns share one property: Kernloom runs on the Linux host that already handles the traffic. No new appliance, no sidecar, no separate control plane.

Configuration is driven by PDPConfig YAML files (--pdp-config), which ship under /opt/kernloom/attested/etc/pdp/. Each node type has a bootstrap variant (blocking disabled, wide thresholds) and a production variant (tighter, enforcement active).

Public-facing profiles (ziti-*, web-server, reverse-proxy) have graph learning disabled — graph learning is not useful when clients are unknown internet IPs. Internal profiles (idp, database, api-server, nas) have graph learning enabled.

Pattern 1 — OpenZiti Router and Controller (public-facing)

The problem: OpenZiti infrastructure is publicly reachable. Routers handle high-throughput tunnel traffic; the Controller exposes enrollment and management APIs. Both attract scans, SYN floods, and connection abuse from the internet.

              Internet
                 │
         ┌───────┴────────┐
         │                │
         ▼                ▼
  ┌─────────────┐  ┌─────────────┐
  │   Kernloom  │  │   Kernloom  │
  │ (Router     │  │ (Controller │
  │  host)      │  │  host)      │
  └──────┬──────┘  └──────┬──────┘
         │                │
  ┌──────┴──────┐  ┌──────┴──────┐
  │    Ziti     │  │    Ziti     │
  │   Router    │  │ Controller  │
  └─────────────┘  └─────────────┘

What Kernloom does:

• Router: ziti-router is tuned for sustained high-throughput tunnel traffic. Flood attacks are rate-limited without affecting legitimate overlay traffic.
• Controller: ziti-controller reacts faster to sustained connection patterns. The block gate protects against over-blocking legitimate clients behind NAT.

Graph learning is not used on these nodes — they face the open internet and the graph would never converge with constantly changing client IPs.

Lifecycle:

# On the Router host

# 1 — Bootstrap: dry-run for 7–14 days, autotune learns real traffic
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/ziti-router-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true

# 2 — Production: switch to production profile, enable enforcement
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/ziti-router.yaml \
  --dry-run=false


# On the Controller host

# 1 — Bootstrap
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/ziti-controller-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true

# 2 — Production
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/ziti-controller.yaml \
  --dry-run=false

Result: Internet background radiation, SYN floods, and connection abuse are absorbed at the kernel level before the Ziti processes see them.

Pattern 2 — NAS with known-access baseline

The problem: A NAS is accessed by a small, known set of clients: an admin through a jump host, and a group of users via SMB. Everything else should be impossible — no scanning, no unexpected access, no probing of management interfaces.

     Admin               Users (SMB)          Unknown
       │                     │                   │
┌──────┴──────┐       ┌──────┴──────┐            │
│  Jump Host  │       │  SMB Users  │            │
│  10.0.1.10  │       │  10.0.2.0/24│            │
└──────┬──────┘       └──────┬──────┘            │
       │ :443                │ :445              │
       │                     │                   ▼
       └──────────┬──────────┘              BLOCK (graph)
                  │                      
         ┌────────┴────────┐             
         │    Kernloom     │             
         │   (NAS host)    │             
         │                 │             
         │  frozen graph:  │             
         │  ✓ JumpHost:443 │             
         │  ✓ Users:445    │             
         │  ✗ all else     │             
         └────────┬────────┘             
                  │                      
             ┌────┴────┐                 
             │   NAS   │                 
             └─────────┘                 

What Kernloom does:

The Graph Learner observes the NAS for a week during normal operations — recording exactly which sources connect on which paths. After review and freeze: admin access to :443, SMB to :445. Any other source or port is immediately blocked. Known sources behaving anomalously (scanning other ports) are caught by progressive enforcement.

Lifecycle:

# 1 — Bootstrap: dry-run + graph learning for 7–14 days
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/nas-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true \
  --graph --graph-mode=learn

# 2 — Enable enforcement once dry-run output looks stable
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/nas-bootstrap.yaml \
  --dry-run=false --graph --graph-mode=learn

# 3 — Review and freeze graph after 7–14 days
kliq graph edges --sort=state     # overview by state
kliq graph baselines --sort=obs   # EWMA stats per edge
kliq graph freeze --dry-run       # check readiness without writing
kliq graph freeze

# 4 — Production: frozen enforcement
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/nas.yaml \
  --dry-run=false --graph --graph-mode=frozen-enforce

# 5 — Strongest posture: XDP allow-mode (only known tuples pass at kernel level)
klshield tuple-enforce allow

Result: The NAS is only reachable via the exact communication patterns it was designed for. Any deviation is blocked immediately.

Pattern 3 — Identity provider and authentication endpoint

The problem: Login endpoints, OAuth/OIDC token endpoints, and enrollment APIs attract credential stuffing, password spraying, and connection floods. These are particularly sensitive: a single successful bypass has outsized impact, and the endpoints are often underprovisioned.

          Internet                Internal services
              │                         │
   ┌──────────┴───────────┐             │
   │    Kernloom          │◄────────────┘
   │  (IdP host)          │
   │                      │  progressive enforcement (internet)
   │  frozen graph:       │  + graph-based path control
   │  ✓ api-server:8080   │    (internal services only)
   │  ✓ monitoring:443    │
   │  ✗ unexpected        │
   └──────────┬───────────┘
              │
   ┌──────────┴───────────┐
   │  IdP / Auth Server   │
   │  OIDC · SAML · OAuth │
   └──────────────────────┘

What Kernloom does:

The idp profile prioritises SYN sensitivity over raw PPS tolerance — authentication abuse looks like sustained low-rate connection pressure, not volumetric flood. Rate limits are tight.

The Graph Learner locks down which internal services are allowed to call the IdP at all. An unexpected internal service attempting token requests triggers an immediate signal. Internet-facing client IPs are too variable for graph learning — only internal service-to-service edges are graph-enforced.

Lifecycle:

# 1 — Bootstrap: dry-run + graph learning for internal edges (7–14 days)
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/idp-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true \
  --graph --graph-mode=learn

# 2 — Enable enforcement once dry-run looks stable
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/idp-bootstrap.yaml \
  --dry-run=false --graph --graph-mode=learn

# 3 — Freeze graph after 7–14 days
kliq graph freeze --dry-run
kliq graph freeze

# 4 — Production
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/idp.yaml \
  --dry-run=false --graph --graph-mode=frozen-enforce

Result: Credential stuffing campaigns are rate-limited after a few attempts. Unexpected internal services calling the IdP are caught immediately.

Pattern 4 — East-West lateral movement in a VLAN

The problem: Nodes inside a VLAN or internal network can reach each other freely. If one workload is compromised, it can scan and probe the rest of the segment — the network layer allows it.

                    VLAN 10 — internal segment
                                                      
  ┌──────────┐  :5432 ✓    ┌──────────┐              
  │  Web App │────────────►│    DB    │              
  │  Node A  │             │  Node B  │              
  └──────────┘             └──────────┘              
                                                      
  ┌──────────┐  scan/flood  ┌──────────┐              
  │Compromised│────────────►│ Node C   │  ← BLOCK    
  │  Node A  │  unknown     │ any host │    immediately
  └──────────┘  path        └──────────┘              

What Kernloom does:

Run Kernloom on each host that needs protecting. During a learning period, the Graph Learner records every observed source→destination flow. Once the baseline is frozen, any source attempting a path that was never observed — including port scans, connection attempts to new services, or traffic from unexpected sources — is blocked immediately, before a single packet reaches the application.

Progressive enforcement runs in parallel: even on known paths, anomalous behaviour (SYN floods, high PPS, port probing) is caught and rate-limited independently.

Lifecycle:

# 1 — Bootstrap: dry-run + graph learning (7–14 days)
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/api-server-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true \
  --graph --graph-mode=learn

# 2 — Enable enforcement once dry-run looks stable
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/api-server-bootstrap.yaml \
  --dry-run=false --graph --graph-mode=learn

# 3 — Freeze graph after 7–14 days
kliq graph freeze --dry-run
kliq graph freeze

# 4 — Production
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/api-server.yaml \
  --dry-run=false --graph --graph-mode=frozen-enforce

# 5 — Optional: XDP allow-mode for strictest posture
klshield tuple-enforce allow

Pick the PDPConfig that matches your node type: database-bootstrap.yaml for DB nodes, api-server-bootstrap.yaml for application servers.

Result: Lateral movement is stopped at the kernel level. A compromised node cannot scan the segment or connect to services it has never talked to before.

Pattern 5 — WAF shielded from DDoS overflow

The problem: A DDoS appliance in front of a WAF absorbs large-volume attacks, but reacts with latency. Targeted, lower-volume floods — persistent SYN pressure, connection exhaustion, slow HTTP floods — still reach the WAF and can overwhelm it before the appliance reclassifies the traffic.

          Internet
              │
    ┌─────────┴──────────┐
    │   DDoS Appliance   │  ← handles volumetric floods
    │  (slow reaction to │    but slow to react to
    │   targeted abuse)  │    targeted lower-volume attacks
    └─────────┬──────────┘
              │  ← some flood still passes through
    ┌─────────┴──────────┐
    │     Kernloom       │  ← catches what slips through:
    │    (WAF host)      │    per-source rate limits,
    │                    │    SYN pressure, connection abuse
    └─────────┬──────────┘
              │
    ┌─────────┴──────────┐
    │        WAF         │  ← protected from connection
    └────────────────────┘    exhaustion

What Kernloom does:

Kernloom runs on the Linux host that runs the WAF, acting before the WAF’s network stack. Sources sending excessive SYN packets, maintaining too many connections per second, or showing non-compliance behaviour are progressively rate-limited and eventually blocked — per source IP, not as a blanket drop.

Graph learning is not used here — the node faces internet clients with constantly changing IPs.

Lifecycle:

# 1 — Bootstrap: dry-run for 7–14 days
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/reverse-proxy-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true

# 2 — Production
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/reverse-proxy.yaml \
  --dry-run=false

Use web-server-bootstrap.yaml / web-server.yaml if Kernloom runs directly on the origin server rather than the WAF host.

Result: The WAF stays available under sustained targeted pressure. Per-source enforcement means a single abusive source is blocked without affecting others behind the same upstream.

Pattern 6 — SSH bastion hardening

The problem: An SSH bastion or jump host is exposed to the internet. It attracts constant brute-force attempts, credential stuffing, and port scanning. Every failed attempt consumes server resources and pollutes logs.

          Internet
              │
   ┌──────────┴───────────┐
   │    Kernloom          │  ← low PPS tolerance,
   │  (bastion host)      │    high SYN sensitivity,
   │                      │    fast escalation to BLOCK
   └──────────┬───────────┘
              │
   ┌──────────┴───────────┐
   │    SSH Bastion       │  ← only sees legitimate
   │    / Jump Host       │    connection attempts
   └──────────────────────┘

What Kernloom does:

The ssh-bastion profile is tuned for this scenario: low trigger thresholds, fast escalation, and a short block TTL. A source that makes a few failed attempts quickly accumulates strikes and is blocked before it can run a meaningful brute-force campaign.

There is no dedicated PDPConfig file for SSH bastions yet. Use --profile ssh-bastion (legacy shorthand) or start from web-server-bootstrap.yaml and tighten the thresholds manually.

Lifecycle:

# 1 — Bootstrap: dry-run, whitelist known-good sources (office NAT, monitoring)
sudo /opt/kernloom/attested/kliq \
  --profile ssh-bastion \
  --dry-run=true --whitelist-learn=true

# 2 — Production
sudo /opt/kernloom/attested/kliq \
  --profile ssh-bastion \
  --dry-run=false

Result: Brute-force attempts are stopped after a handful of connection attempts. SSH daemon logs are clean. Server resources are not consumed by scripted scanners.

Pattern 7 — Multi-tenant edge node with tenant isolation

The problem: A shared Linux host runs services for multiple tenants or environments. Tenant A’s traffic should not be able to reach Tenant B’s processes.

          Internet
              │
   ┌──────────┴───────────┐
   │    Kernloom          │
   │  (shared host)       │
   │                      │
   │  graph baseline:     │
   │  ✓ Tenant A → :8080  │
   │  ✓ Tenant B → :9090  │
   │  ✗ A→B, B→A, cross   │
   └──────────┬───────────┘
              │
   ┌──────┐   │   ┌──────┐
   │ App  │   │   │ App  │
   │  A   │   │   │  B   │
   │:8080 │   │   │:9090 │
   └──────┘   │   └──────┘

What Kernloom does:

The Graph Learner observes which sources reach which ports. Once the baseline is frozen, cross-tenant traffic — a source for Tenant A attempting to reach Tenant B’s port — triggers an immediate block. Progressive enforcement catches any tenant abusing shared host resources.

Lifecycle:

# 1 — Bootstrap: dry-run + graph learning (7–14 days)
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/api-server-bootstrap.yaml \
  --dry-run=true --whitelist-learn=true \
  --graph --graph-mode=learn

# 2 — Enable enforcement
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/api-server-bootstrap.yaml \
  --dry-run=false --graph --graph-mode=learn

# 3 — Freeze graph after 7–14 days
kliq graph freeze --dry-run
kliq graph freeze

# 4 — Production
sudo /opt/kernloom/attested/kliq \
  --pdp-config=/opt/kernloom/attested/etc/pdp/api-server.yaml \
  --dry-run=false --graph --graph-mode=frozen-enforce

# 5 — Optional: XDP allow-mode
klshield tuple-enforce allow

Result: Logical tenant isolation at the kernel level, without container orchestration or separate network namespaces.

Combining patterns

Most real deployments combine multiple patterns:

The general rule: start every node with the bootstrap PDPConfig and --dry-run=true. Enable enforcement when autotune has stabilised. Layer the Graph Learner on top for internal nodes once you have stable progressive enforcement baselines.

See also

Current limitation — multi-interface attach works, but kliq sees aggregated telemetry. klshield can now attach to multiple interfaces simultaneously. However, kliq reads telemetry from all attached interfaces combined — it has no way to tell which packet came from which interface. This means per-interface policy separation is not possible today: you cannot run graph learning only on eth1 (internal) while doing DoS-only enforcement on eth0 (public). Both interfaces feed into the same source counters and the same graph. Combined patterns that require different enforcement models per interface on the same host (e.g. Pattern 2 public DoS protection + Pattern 4 internal microsegmentation) are therefore not achievable on a single node today. The practical workaround: deploy Kernloom on the interface that matters most for the specific threat, or separate the roles across dedicated hosts.